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

[Ken Murchison <[e-mail]>]

Hi Julian,

Thanks for the review.  Comments/questions inline.


On 11/14/2016 12:23 AM, Julian Reschke wrote:
> 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.

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.


>    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.

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.



> 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/

Both Fixed.



> 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?

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?


> 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.

Just remove the references altogether, or place them elsewhere?


>    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.

What do you suggest instead?  MAY?


> 4.  The "depth-noroot" Processing Preference
>
> 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".


> 5.  Implementation Status
>
> Nit: -> appendix

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


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

In what fashion?


> 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.

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

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University