W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 14 Nov 2016 23:08:32 +0100
To: Ken Murchison <murch@andrew.cmu.edu>, HTTP Working Group <ietf-http-wg@w3.org>, WebDAV <w3c-dist-auth@w3.org>
Message-ID: <ce932309-f738-cfb0-36ce-ad73f68f4704@gmx.de>
On 2016-11-14 18:42, Ken Murchison wrote:
>
>
> On 11/14/2016 09:41 AM, Julian Reschke wrote:
>> On 2016-11-14 14:42, Ken Murchison wrote:
>>> ...
>>>>    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
>> <https://greenbytes.de/tech/webdav/rfc3253.html#REPORT_expand-property>,
>> 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?

One example should be enough.

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

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

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

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

Best regards, Julian
Received on Monday, 14 November 2016 22:09:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 14 November 2016 22:09:22 UTC