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

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.

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

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


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

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.

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


 > ...

Best regards, Julian

Received on Thursday, 19 September 2013 13:38:37 UTC