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

Julian Reschke <> Mon, 14 November 2016 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8CAE129569 for <>; Mon, 14 Nov 2016 06:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hZPhIfWobO3Y for <>; Mon, 14 Nov 2016 06:46:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AD0712957B for <>; Mon, 14 Nov 2016 06:46:15 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c6IT3-0007zM-P6 for; Mon, 14 Nov 2016 14:42:41 +0000
Resent-Date: Mon, 14 Nov 2016 14:42:41 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c6ISs-0007xo-Ke; Mon, 14 Nov 2016 14:42:30 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c6ISm-0005Eu-6d; Mon, 14 Nov 2016 14:42:25 +0000
Received: from [] ([]) by (mrgmx001 []) with ESMTPSA (Nemesis) id 0LzblK-1ct5kU3Shm-014kp8; Mon, 14 Nov 2016 15:41:49 +0100
To: Ken Murchison <>, HTTP Working Group <>, WebDAV <>
References: <> <> <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Mon, 14 Nov 2016 15:41:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:n+miRgdwTX/m39pYfgE/tGSPS9zwIGT8l4wMM46p/OTrTkFOldi ZgONzD39gyJOsUi8IpQnL0jKeI5gTqHrDloIslvjvUGvZaFanMEM3NWPTxnUaeVgkAZseg1 AcDSnMuw0rYY1NzlQNme5E6fib/aWLsfBqCZ96JxHOOE2fui7/bHRixmQuDb3vN9PRsAGf5 HcDsZsqmV1s4cGOr0rosA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:IQ+vnYMDDx0=:U2w20aE3sIMz36SXhlCTfs IyVfnDqBCoxlD+BBb2puVT5p97DxhfwjLxUaPs5mkD7gifk2HX7FspoYyJ0IqOVT1OwF4w3of dzaDjrd+qelUT9oi0X43AbRJxKaADGRiJP0HnGRcrPxiw6szMPCeqpREtSNFjpkcfI2641urO XKC1JcN4c3y7xvzLRNd6sn6qzhf/QR4kkCwtzz+nc/n5hr44PMpfFSnDS6l7Vrlc1wGR2ecLZ iUr8X6cAMEZ3a3iO8ciJxVPOEglfQYbjEweaUGL4Z0ZVh8CguSSyFdJWJoiUTOV3qJn644g6s U9gTZcmi67vlKa8kfKDwaeD7kEX+prow+7H/+DKEi/m5noFh7ekmqkG18sP0hmgB62yElzHJg s7IY2RlixQyZX/KilwAKVK5poEDPluftNgYqhfPXx9GuhzBepUzTieRGV6wqmIEvS7f9f9E1X Xfb2b9mDkx/85L1jXnmBYxZGvjewMJTBwOKAPd0NfvpaWFuomjnUG1OjahR3ScbwuR1yWgzm/ BrIrGP3IX1wHHyjPRk/0PQiUMuQOXyuAXxRDJmggIz0I3FEIaoG5xIADh1NfTFigixXNXVobc YnAOxAnhOVM6jSXxKmAWT/KGnCrWUpovtpOOIw3kDkSOdaNq0WY3yrrhsmRmJAoDgRsL9ZVkw noAEgtwCjE4++91hwibMabCST74xjIK7CJSsfDbvGqqc8OI+UIg+EYID+ESbvTKAd5jMaSnZG Qg+wlg1rMxLYytzbKgOSWxUqOIIZBo17qQuhPIBvCeUqvvAwwtU+t4ZL5AvyS0NdiqkiqHDG8 ZE2ZvnwKIlS5QZlePEVDvaBQOKx6v/H+Yu7fg2HdbvKU0MsMTE=
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=-0.130, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c6ISm-0005Eu-6d e8e02fa1b22f2722ffc25c4bffae46dc
Subject: Re: feedback on draft-murchison-webdav-prefer-09
Archived-At: <>
X-Mailing-List: <> archive/latest/32895
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2016-11-14 14:42, Ken Murchison wrote:
> ...
>> 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
> 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.

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.

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

Actually, I was thinking of 
which "SHOULD" be supported by any server implementing REPORT.

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

Remove sounds good to me.

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

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

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

Ack, good to know.

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

I was thinking that the preferences that we extend here should also have 
updated entries in 

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

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

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

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

Best regards, Julian