Subject: feedback on draft-murchison-webdav-prefer-09

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Nov 2016 06:23:49 +0100

On 2016-10-17 08:14, Julian Reschke wrote:
> ...

See below some quick (for some value of "quick"...) feedback:

Open Issues

    o  Does this draft also update the RFCs for CalDAV, CardDAV, and
       those documenting the effected HTTP methods?

I believe so.

    o  Should we explitcly mention that this draft applies to any/all
       *DAV protocols (e.g.  CalDAV and CardDAV)?  Would a title change
       be in order?

I don't believe that's needed.

    o  Should we use a non-protocol-specific REPORT example such as
       DAV:sync-collection rather than using CalDAV:calendar-multiget?

Yes, optimally one defined in the base specs.

Nits:

1.  Introduction

    [RFC7240] also defines the "return=representaion" preference which

s/representaion/representation/

    Finally, Section 4 of this specifcation defines the "depth-noroot"

s/specifcation/specification/

2.2.  Minimal REPORT Response

    When a REPORT [RFC3253] request, whose report type results in a 207
    (Multi-Status) response, contains a Prefer header field with a
    preference of "return=minimal", the server SHOULD omit all
    DAV:propstat XML elements containing a DAV:status XML element of
    value 404 (Not Found) [RFC7231] from the 207 (Multi-Status) response.
    If the omission of such a DAV:propstat element would result in a
    DAV:response XML element containing zero DAV:propstat elements, the
    server MUST substitute one of the following in its place:

    o  a DAV:propstat element consisting of an empty DAV:prop element and
       a DAV:status element of value 200 (OK) [RFC7231]

    o  a DAV:status element of value 200 (OK)

    See Appendix B.2 for examples.

That's identical as for PROPFIND right? Maybe we could save some spec 
text here?

3.  Reducing WebDAV Round-Trips with "return=representation"

    The PUT, COPY, MOVE, [RFC4918] PATCH, [RFC5789] and POST [RFC5995]

Nit: reference looks a bit weird in between. Also, PUT is defined RFC 
723x, which brings us to the question whether this spec needs to update 
RFC 723x.

    methods can be used to create or update a resource.  In some
    instances, such as with CalDAV Scheduling [RFC6638], the created or
    updated resource representation may differ from the representation
    sent in the body of the request or referenced by the effective
    request URI.  In cases where the client would normally issue a
    subsequent GET request to retrieve the current representation of the
    resource, the client SHOULD instead include a Prefer header field

I don't think we need a SHOULD here for the client.

4.  The "depth-noroot" Processing Preference

Still not clear whether this is needed.

5.  Implementation Status

Nit: -> appendix

7.  IANA Considerations

I think we need to update the existing IANA registrations as well.

Appendix A.  The Brief and Extended Depth Request Header Fields

    ...

    Client and server implementations that already support the Brief
    header field can add support for the "return=minimal" preference with
    nominal effort.

    If a server supporting the Prefer header field receives both the
    Brief and Prefer header fields in a request, it MUST ignore the Brief
    header field and only use the Prefer header field preferences.

I don't think we can have a MUST here on something that actually is 
undefined, as far as IETF specs go.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Nov 2016 08:42:56 -0500

Hi Julian,

Thanks for the review.  Comments/questions inline.

>       those documenting the effected HTTP methods?

So, I've added the following to the list of RFCs updated:

3253: REPORT
4918: PROPFIND, PROPPATCH, MKCOL
4971: CalDAV, MKCALENDAR
5689: Ext MKCOL
5789: PATCH
5995: POST (add-member)
6252: CardDAV

As you mention below, do you think I need to add 7231 (PUT) to that 
list?  7240 doesn't list any RFCs that it updates, particularly 7231.

> Yes, optimally one defined in the base specs.

I think the most widely used REPORT that is closest to being part of the 
base specs would be DAV:sync-collection.  Unless you think I should use 
DAV:version-tree from 3253 or one of the WebDAV ACL REPORTs.

> s/specifcation/specification/

Both Fixed.

> That's identical as for PROPFIND right? Maybe we could save some spec 

So, perhaps one combined section entitled "Minimal PROPFIND and REPORT 
Responses" with an opening sentence "When a PROPFIND request, or a 
REPORT request whose report type results in a 207 (Multi-Status) 
response, contains a Prefer ...".

Is that what you had in mind?

> 723x, which brings us to the question whether this spec needs to 
> update RFC 723x.

Just remove the references altogether, or place them elsewhere?

> I don't think we need a SHOULD here for the client.

What do you suggest instead?  MAY?

> Still not clear whether this is needed.

The folks at Apple requested this preference and are keen to see it stay 
in the spec.  This actually mimics what Microsoft has done with their 
proprietary Depth header field values "1,noroot", and "infinity,noroot".

> Nit: -> appendix

RFC 7942 states that this section (which will be removed by the RFC 
editor anyways) should appear just before Security Considerations.

> I think we need to update the existing IANA registrations as well.

In what fashion?

> undefined, as far as IETF specs go.

Use SHOULD instead of MUST, or simply remove the suggestion entirely?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Nov 2016 09:23:57 -0500

> What do you suggest instead?  MAY?

Or RECOMMENDED?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Nov 2016 15:41:46 +0100

> list?  7240 doesn't list any RFCs that it updates, particularly 7231.

Tricky question.

For RFC 7240 I *believe* the reason is that even if a preference is 
applied, the response is still compliant with the base spec. Whereas 
this is not the case for most behaviors describes in this spec.

Thus, an implementer should be able to locate this spec by looking at 
the IANA method registry. That registry can either list this spec as 
modifying the method definition, or this spec would need to state that 
it "updates" the definition referenced in the IANA registry.

Right now I'm not sure which of the two alternatives is best.

> DAV:version-tree from 3253 or one of the WebDAV ACL REPORTs.

Actually, I was thinking of 
<https://greenbytes.de/tech/webdav/rfc3253.html#REPORT_expand-property>, 
which "SHOULD" be supported by any server implementing REPORT.

> Is that what you had in mind?

Yep.

> Just remove the references altogether, or place them elsewhere?

Remove sounds good to me.

> What do you suggest instead?  MAY?

"can".

> proprietary Depth header field values "1,noroot", and "infinity,noroot".

I remain unconvinced that the saving justifies the additional complexity :-)

> editor anyways) should appear just before Security Considerations.

Ack, good to know.

>> I think we need to update the existing IANA registrations as well.

I was thinking that the preferences that we extend here should also have 
updated entries in 
<http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#preferences>.

Now, this question is related to the method registry (using the 
"updates" category in the boilerplate vs modifying the registry). 
Alexey, any guidance?

> Use SHOULD instead of MUST, or simply remove the suggestion entirely?

If it supports this spec, it *will* ignore the Brief by definition, right.

So maybe just state that? "it will ignore..."?

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Nov 2016 11:26:48 -0500

> So maybe just state that? "it will ignore..."?

Actually, my implementation supports Prefer but also doesn't ignore 
Brief.  It treats Brief:true as if Prefer:return=representation was sent 
in the request, regardless of whether Prefer was sent or not. I don't 
know if this is more appropriate than ignoring Brief, but we probably 
need a definitive statement on how a server should behave if both 
headers appear in a request.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Nov 2016 12:42:59 -0500

> which "SHOULD" be supported by any server implementing REPORT.

OK, I will generate an example using expand-property.  Do you feel I 
should remove the CALDAV:calendar-multiget example?

I was thinking of adding a non-exhaustive list of current REPORTs that 
return=minimal would apply to.  Thoughts?

> Remove sounds good to me.

Actually, I just realized the I had commas in a stupid place.  I fixed 
it so it now looks like this:

"The PUT, COPY, MOVE [RFC4918], PATCH [RFC5789], and POST [RFC5995] 
methods ..."

Does this look better to you?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Nov 2016 23:08:32 +0100

> should remove the CALDAV:calendar-multiget example?

One example should be enough.

> return=minimal would apply to.  Thoughts?

Can we clarify this based on the report's response format?

> Does this look better to you?

A bit, but it's still misleading for PUT, right?

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Nov 2016 17:29:49 -0500

> One example should be enough.

Fair enough.

> Can we clarify this based on the report's response format?

Not sure what you mean.  It only applies to reports which use the 
multi-status response.  Is this not clear from the prose?  If not, I 
will attempt to clarify.

> A bit, but it's still misleading for PUT, right?

Perhaps, but PUT is discussed in 4918.  I can add a reference to 7231 if 
you prefer.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 14 Nov 2016 11:59:15 -0500

It seems to me that if both appear ignore brief.

The sender knows about Prefer and is only sending Brief in case the 
server doesn't support Prefer.

On 11/14/16 11:26, Ken Murchison wrote:
> Brief.  It treats Brief:true as if Prefer:return=representation was 
> sent in the request, regardless of whether Prefer was sent or not. I 
> don't know if this is more appropriate than ignoring Brief, but we 
> probably need a definitive statement on how a server should behave if 
> both headers appear in a request.
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2016 21:39:47 +0100

> Right now I'm not sure which of the two alternatives is best.

I talked to Alexey, and I believe we agreed that updating the IANA 
method registry (*adding* references to this spec) would be sufficient.

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Nov 2016 15:56:38 -0500

> method registry (*adding* references to this spec) would be sufficient.

OK.  Is this in lieu of listing updated RFCs in the boilerplate or in 
addition?

Is there a template for updating the registry with references?  Or is 
some simple text asking for the references to be added sufficient?

Just to clarify, which methods do you think need to have additional 
references?  PROPFIND, REPORT, and PROPPATCH because we alter the 
responses for return=minimal?  Also keep in mind the the server is 
always free to ignore the preference if it so chooses.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2016 21:59:20 +0100

> OK.  Is this in lieu of listing updated RFCs in the boilerplate or in

Instead of.

> some simple text asking for the references to be added sufficient?

The latter should be sufficient.

> always free to ignore the preference if it so chooses.

Those, plus MKCOL, right?

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Nov 2016 16:07:14 -0500

> Those, plus MKCOL, right?

Hmm.  I'm not sure we alter anything specified by 4918 or 5689 for 
MKCOL.  Maybe there is an argument that we alter the MKCALENDAR response.

I do wonder why 5689 isn't listed as a reference for MKCOL since it adds 
a request body.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2016 22:21:20 +0100

> MKCOL.  Maybe there is an argument that we alter the MKCALENDAR response.

Aren't we altering the response for extended MKCOL?

> I do wonder why 5689 isn't listed as a reference for MKCOL since it adds

Oversight, I would say.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 16 Nov 2016 11:40:12 -0500

Julian,

I just posted version -10 which I think addresses all of your comments.  
I did add a few new open issues.  Feel free to start another thread with 
any new comments.  If you're in Seoul, maybe you can catch Alexey again 
regarding which updated RFCs should be listed in the title page header.