feedback on draft-murchison-webdav-prefer-09

Julian Reschke <> Mon, 14 November 2016 05:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39C001295C4 for <>; Sun, 13 Nov 2016 21:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-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 LoHnibssSgKA for <>; Sun, 13 Nov 2016 21:28:14 -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 0D607129626 for <>; Sun, 13 Nov 2016 21:28:09 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c69kw-00050n-Jx for; Mon, 14 Nov 2016 05:24:34 +0000
Resent-Date: Mon, 14 Nov 2016 05:24:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c69kp-0004ve-VM; Mon, 14 Nov 2016 05:24:27 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c69kj-0002VD-V8; Mon, 14 Nov 2016 05:24:22 +0000
Received: from [] ([]) by (mrgmx103 []) with ESMTPSA (Nemesis) id 0LbdiB-1cUnBF3zWF-00lBte; Mon, 14 Nov 2016 06:23:54 +0100
To: HTTP Working Group <>, WebDAV <>
References: <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Mon, 14 Nov 2016 06:23:49 +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:MClUQf0a6EaiTvp/4+7t7nYSR+iGxYU3NCLRdOa/+WanJpcMGIB AymD9LgeZmzzyLUzK6Sbd2PUI5mcy7Gi8ol9m/eV2Ru0FoBtfZ+IpZSS5Oqkti3XMzt1S0f eMdNM9rerCbUXKI/aoSvohUTeFsO5DYovec1XnxbLarKirJo5u3EcNljoSTYbn9krL1649x ZOIp4dSzXwoasr83yzpjw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:XQBg1n7qeao=:wrzazRH8e9TpDjt0GKYzih zjPRgyYkl8Vp2NC+y1pufpTHiPcn2FLyRn1V1kZ45YrXdRS1NHxw56Ymot0aAlFSjG4oHE/PW B5R8TRkxQ8/MLZQFhShLBkRn+K7x+LnOcIevZ96NZvS2ZivSR/WrOOuA4p63gSW6pwzJlJuIf 6fdBf7VNHUxeKMUIJWIkHJ8LfVt14Eyw6/AB0qkDS31Tu20A4KJ3n5hal7slM3nCv7I6trZ0m ZBx6VRbZOssdesLxEbVjWQqSpdCTCMpzUGdbSaDJbCxbSBWx4Eq/9qVAZYq5tRgtRHgn93UNI sBWhgbUAGON2qtOKR+o5RllI58Z0NjnnCmpXI89dC7YaKt2QK3GspL0XQm6J3PSPYTRfaec2G tLtgVKNJsyeedgr8zz46nV/WJcdN0OsOlCOh0ZNBbaU8K/fSyCDwq+PWC2LhE9Efc8MlrUm0r E+uQnDVr+7V9+D/O/TGQ6f0NWMYLwBpieaMfQIEX2Vb5e3sj5DCa3/PXCoYvw/MS3tVIn++Dn 33+1qUPF8w7rmjztFiKlLqmWKgViDLibob4pwDBWg9Tv8jlADkkxe1ySdfPs4GwbevNKWfMRr Kh1j8uM8PDXTxvCeBuEJS/g2KQLodzj4vAUPLrAOasyU0iiYgnyfub2sz6GjoljtO6IaMBgLM 8qYDWWcwSnijWq4/+z2G76zm46DneMFhtk6QH4bNe3ayRZmSnxIBq3qQnnDVCYPM6PwUBeX97 gWLmzowsU1DTTqJNDSAYCQtZCC5Ebc1bvBYF8bNndNDZTf8J83Qq+dM50NGuCRPKnR5X18ImE NjuGUai
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.228, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.797, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c69kj-0002VD-V8 67e4af8b486cd87b82de9acfbb029a9b
Subject: feedback on draft-murchison-webdav-prefer-09
Archived-At: <>
X-Mailing-List: <> archive/latest/32884
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.


1.  Introduction

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


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


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.