Re: Fwd: I-D Action: draft-murchison-webdav-prefer-05.txt

On 09/19/2013 09:37 AM, Julian Reschke wrote:
> On 2013-09-19 15:25, Ken Murchison wrote:
>> ...
>>>
>>> 2.1
>>>
>>> "If the omission of such a DAV:propstat element would result in a
>>> DAV:response XML element containing zero DAV:propstat elements, then
>>> the server MUST substitute a DAV:propstat element consisting of an
>>> empty DAV:prop element and a DAV:status element of value 200 (OK)
>>> [I-D.ietf-httpbis-p2-semantics] in its place."
>>>
>>> This seems to be here to keep the response DTD-valid. Did you consider
>>> just relaxing the DTD, and to allow a response without <DAV:prop>?
>>
>>
>> That is what the CalConnect members originally implemented as can be
>> seen in Appendix B.6, but I believe that one of the implementers was
>> concerned with this form of multi-status not being supported by
>> libraries.  If you think this is a show-stopper, I can take it back to
>> the CalDAV technical committee.
>
> Well, the application of the Preference may break clients in any case. 
> That's why it's optional, after all.
>
> It would be good to understand whether there indeed was a library 
> broken by this (and whether it's possible to fix it), or just some 
> kind of fear.


I will find out if anybody remembers exactly why we made this change.



>>> "If the server honors and applies the return=minimal preference to the
>>> processing of a PROPFIND request as described above, the server SHOULD
>>> include a Preference-Applied [I-D.snell-http-prefer] header field
>>> containing the "return=minimal" token in the response."
>>>
>>> Why?
>>>
>>> The Prefer spec says: "Use of the Preference-Applied header is only
>>> necessary when it is not readily and obviously apparent that a server
>>> applied a given preference and such ambiguity might have an impact on
>>> the client's handling of the response."
>>>
>>> Isn't it obvious in this case? If it's not, maybe the SHOULD needs to
>>> be a MUST?
>>
>>
>> Good question.  This is a recent addition at the request of a CalDAV
>> client author who feels like it would be nice to know if the preference
>> was applied prior to parsing the response body, presumably because it
>> can/does have an effect on how his client processes the body.  I will
>> take this back to the CalDAV technical committee and see if we want to
>> change this to a MUST or just drop the requirement.
>
> My understanding is that it should not affect how the response is 
> processed.


I will ask for further clarification from the client author.



>>> 2.1.1
>>>
>>> "This example tries to fetch an unknown property from a
>>> CARDDAV:addressbook [RFC6352] collection."
>>>
>>> Why do we need to mention CARDDAV here? This seems to be an unncessary
>>> distraction...
>>
>>
>> Yeah.  I was attempting to use examples that show the usefulness in the
>> various *DAV protocols, but maybe it is too much of a distraction.  What
>> are your thoughts on using CALDAV:calendar-multiget and DAV:sync-token
>> in the examples?  I think the CalDAV scheduling example in Section 3
>> should stay, but maybe I should point out how/where the server changes
>> the resource.
>
> It would be cool if the examples needed anything beyond RFC 4918 and 
> RFC 3253.
>
> Instead of sync-token, can we just use something more basis such as 
> content length and media type? For the report, maybe just use 
> expand-property?

I will work on that.



>>> Sections 2.3 and 2.4 suggest changing a 207 response to 200/201 and
>>> require an empty message body. Why does it need to be empty?
>>
>>
>> The argument here is that we don't want the client to have to parse a
>> body if the request is successful.  Do you recommend that we specify 204
>> instead?
>
> The client doesn't need to parse the body, even if it's non empty.

This is true, but including anything in the body defeats the purpose of 
return=minimal.  The 2xx response code tells the client that all 
instructions were performed successfully so there is no need for any 
other verbiage.


>
> We can allow 204 as well; but we should stick with standard HTTP; and 
> over there it's not uncommon that servers send a short text/plain or 
> text/html result, even if it's not needed.

OK.  How would you specify  the use of return=minimal with PROPPATCH and 
MKCOL/MKCALENDAR, or do you think that it can't be applied to these 
methods in the real world?



>>> A.
>>>
>>> "Authors are encouraged to implement the Brief header field
>>> functionality in conjunction with this specification to further
>>> promote interoperability with products that use the Brief header field
>>> exclusively."
>>>
>>> Hmm. So we specifiy something new and tell people to implement the
>>> "old" syntax as well?
>>
>> Several of the CalConnect members originally implemented the Brief
>> header because we liked the functionality and it already had deployment
>> in Microsoft products.  I set out to formally document the Brief header,
>> but the MS folks asked us not to, so we turned to Prefer.  I suppose the
>> only reason to implement Brief at this point is to support older 
>> products.
>>
>> If you feel that this is a show-stopper, I can certainly remove this 
>> text.
>
> I'd get rid of it.

OK.



-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

Received on Thursday, 19 September 2013 14:05:41 UTC