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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
(FYI)


-------- Original Message --------
Subject: I-D Action: draft-murchison-webdav-prefer-05.txt
Date: Thu, 12 Sep 2013 10:27:27 -0700
From: [hidden email]
Reply-To: [hidden email]
To: [hidden email]


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : Use of the Prefer Header Field in Web Distributed
Authoring and Versioning (WebDAV)
        Author(s)       : Kenneth Murchison
        Filename        : draft-murchison-webdav-prefer-05.txt
        Pages           : 30
        Date            : 2013-09-12

Abstract:
    This specification defines how the HTTP Prefer header field can be
    used by a WebDAV client to request that certain behaviors be employed
    by a server while constructing a response to a successful request.

Editorial Note (To be removed by RFC Editor before publication)

    Please send comments to the Web Distributed Authoring and Versioning
    (WebDAV) mailing list at <mailto:[hidden email]> [1], which may
    be joined by sending a message with subject "subscribe" to <mailto
    :[hidden email]> [2].  This mailing list is archived at
    <http://lists.w3.org/Archives/Public/w3c-dist-auth/> [3].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-murchison-webdav-prefer-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-murchison-webdav-prefer-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 2013-09-17 14:04, Julian Reschke wrote:

> (FYI)
>
>
> -------- Original Message --------
> Subject: I-D Action: draft-murchison-webdav-prefer-05.txt
> Date: Thu, 12 Sep 2013 10:27:27 -0700
> From: [hidden email]
> Reply-To: [hidden email]
> To: [hidden email]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>      Title           : Use of the Prefer Header Field in Web Distributed
> Authoring and Versioning (WebDAV)
>      Author(s)       : Kenneth Murchison
>      Filename        : draft-murchison-webdav-prefer-05.txt
>      Pages           : 30
>      Date            : 2013-09-12
> ...

Here's my feedback.

Summary: I like it. Thanks for doing the work.

Detailed feedback below:

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


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


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

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?

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?


Editorial:

The draft is kind of chatty with respect to references. Example:

"When a PROPFIND [RFC4918] method request contains a Prefer
[I-D.snell-http-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)
[I-D.ietf-httpbis-p2-semantics] from the 207 (Multi-Status) [RFC4918]
response."

My recommendation is to either strip some -- in particular the whole
draft is about WebDAV and Prefer, so keeping to point at 4918 all the
time is a bit tiring, or to make them more useful by making them more
specific:

"When a PROPFIND ([RFC4918], Section 9.1) request contains a Prefer
header field with a preference of "return=minimal"
([I-D.snell-http-prefer], Section 4.2) the server SHOULD omit all
DAV:propstat XML elements containing a DAV:status XML element of value
404 (Not Found) ([I-D.ietf-httpbis-p2-semantics], Section 6.5.4) from
the 207 (Multi-Status) response ([RFC4918], Section 11.1)."

Also/method request/request/


3.

s/subsquent/subsequent/

9.2

Please format the MSDN references so that the URIs turn up in the
generated TXT version.

For example:

<reference anchor="MSDN.aa563501"
target="http://msdn.microsoft.com/en-us/library/aa563501.aspx">
...





Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
Thanks for the feedback Julian. Responses below.



On 09/19/2013 08:16 AM, Julian Reschke wrote:

> On 2013-09-17 14:04, Julian Reschke wrote:
>> (FYI)
>>
>>
>> -------- Original Message --------
>> Subject: I-D Action: draft-murchison-webdav-prefer-05.txt
>> Date: Thu, 12 Sep 2013 10:27:27 -0700
>> From: [hidden email]
>> Reply-To: [hidden email]
>> To: [hidden email]
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>      Title           : Use of the Prefer Header Field in Web Distributed
>> Authoring and Versioning (WebDAV)
>>      Author(s)       : Kenneth Murchison
>>      Filename        : draft-murchison-webdav-prefer-05.txt
>>      Pages           : 30
>>      Date            : 2013-09-12
>> ...
>
> Here's my feedback.
>
> Summary: I like it. Thanks for doing the work.
>
> Detailed feedback below:
>
> 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.



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



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



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



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



> Editorial:
>
> The draft is kind of chatty with respect to references. Example:
>
> "When a PROPFIND [RFC4918] method request contains a Prefer
> [I-D.snell-http-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)
> [I-D.ietf-httpbis-p2-semantics] from the 207 (Multi-Status) [RFC4918]
> response."
>
> My recommendation is to either strip some -- in particular the whole
> draft is about WebDAV and Prefer, so keeping to point at 4918 all the
> time is a bit tiring, or to make them more useful by making them more
> specific:
>
> "When a PROPFIND ([RFC4918], Section 9.1) request contains a Prefer
> header field with a preference of "return=minimal"
> ([I-D.snell-http-prefer], Section 4.2) the server SHOULD omit all
> DAV:propstat XML elements containing a DAV:status XML element of value
> 404 (Not Found) ([I-D.ietf-httpbis-p2-semantics], Section 6.5.4) from
> the 207 (Multi-Status) response ([RFC4918], Section 11.1)."

I agree.  I will remove the redundant references and/or be more specific
where needed.



> Also/method request/request/

Fixed.


> 3.
>
> s/subsquent/subsequent/

Fixed.


> 9.2
>
> Please format the MSDN references so that the URIs turn up in the
> generated TXT version.
>
> For example:
>
> <reference anchor="MSDN.aa563501"
> target="http://msdn.microsoft.com/en-us/library/aa563501.aspx">
> ...

Done.

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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

Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
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


Reply | Threaded
Open this post in threaded view
|

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

Cyrus Daboo-2
Hi Ken,

--On September 19, 2013 at 10:05:04 AM -0400 Ken Murchison
<[hidden email]> wrote:

>>> If you feel that this is a show-stopper, I can certainly remove this
>>> text.
>>
>> I'd get rid of it.
>
> OK.
>

Well I do think it is worth mentioning that the Brief header exists and
this new draft is defining a standards-based alternative to that -
emphasizing that servers/clients that currently support Brief can also
implement Prefer without any problems. The only thing to state is that if a
server receives both Brief and Prefer it should prefer Prefer!

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
On 09/19/2013 10:38 AM, Cyrus Daboo wrote:

> Hi Ken,
>
> --On September 19, 2013 at 10:05:04 AM -0400 Ken Murchison
> <[hidden email]> wrote:
>
>>>> If you feel that this is a show-stopper, I can certainly remove this
>>>> text.
>>>
>>> I'd get rid of it.
>>
>> OK.
>>
>
> Well I do think it is worth mentioning that the Brief header exists
> and this new draft is defining a standards-based alternative to that -
> emphasizing that servers/clients that currently support Brief can also
> implement Prefer without any problems. The only thing to state is that
> if a server receives both Brief and Prefer it should prefer Prefer!
>

Do you have any suggested text to replace/augment what I have in
Appendix A?  I think Julian wants me to remove the suggestion that
Prefer-based implementations also implement Brief.

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ken Murchison
On 2013-09-19 16:05, Ken Murchison wrote:

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

I agree there's no need. I just wonder how strong the requirement no to
return anything is. I want to avoid a situation where clients blow up
just because they get a tiny status message.

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

Just state that the response can be any suitable success message (200,
201, 204), and - for 200/201 - a response payload (a) is not needed and
(b) does not need to be processed.

> ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ken Murchison
On 2013-09-19 16:43, Ken Murchison wrote:

> On 09/19/2013 10:38 AM, Cyrus Daboo wrote:
>> Hi Ken,
>>
>> --On September 19, 2013 at 10:05:04 AM -0400 Ken Murchison
>> <[hidden email]> wrote:
>>
>>>>> If you feel that this is a show-stopper, I can certainly remove this
>>>>> text.
>>>>
>>>> I'd get rid of it.
>>>
>>> OK.
>>>
>>
>> Well I do think it is worth mentioning that the Brief header exists
>> and this new draft is defining a standards-based alternative to that -
>> emphasizing that servers/clients that currently support Brief can also
>> implement Prefer without any problems. The only thing to state is that
>> if a server receives both Brief and Prefer it should prefer Prefer!

Prefer: prefer

/me ducks

> Do you have any suggested text to replace/augment what I have in
> Appendix A?  I think Julian wants me to remove the suggestion that
> Prefer-based implementations also implement Brief.

Stating where it came from is good (plus having the references).

I just wouldn't recommend to implement it; if you do so, people *will*
ask what the point of the new spec is.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
In reply to this post by Julian Reschke
On 09/19/2013 10:44 AM, Julian Reschke wrote:

> On 2013-09-19 16:05, Ken Murchison wrote:
>> ...
>>>> 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.
>> ...
>
> I agree there's no need. I just wonder how strong the requirement no
> to return anything is. I want to avoid a situation where clients blow
> up just because they get a tiny status message.

Playing devil's advocate here: If a client sends return=minimal with a
PROPATCH or MKCOL/MKCALENDAR and can't handle the minimal response, then
its a bad client.  If it can't handle a minimal success response is MUST
NOT send return=minimal.  Likewise, if a server can't properly send a
minimal response, then it MUST NOT return Preference-Applied.

The more I think about this, I'm wondering why we can't specify that
return=minimal requires an empty body upon success, or just specify that
the server return 204.  If either a client or server can't implement it
this way, then it is free to not use or ignore the preference.



>>> 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?
>
> Just state that the response can be any suitable success message (200,
> 201, 204), and - for 200/201 - a response payload (a) is not needed
> and (b) does not need to be processed.

I'd really like to nail this down, so there isn't a any variance in
responses.  If we can't specify empty body, can we just go with 204?

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
In reply to this post by Julian Reschke
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.

Can you confirm that the following would be a valid multistatus
response?  I think we had some question on that.

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
   <D:response>
     <D:href>/container/</D:href>
     <D:status>HTTP/1.1 200 OK</D:status>
   </D:response>
</D:multistatus>


--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ken Murchison
On 2013-09-19 17:32, Ken Murchison wrote:

> On 09/19/2013 10:44 AM, Julian Reschke wrote:
>> On 2013-09-19 16:05, Ken Murchison wrote:
>>> ...
>>>>> 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.
>>> ...
>>
>> I agree there's no need. I just wonder how strong the requirement no
>> to return anything is. I want to avoid a situation where clients blow
>> up just because they get a tiny status message.
>
> Playing devil's advocate here: If a client sends return=minimal with a
> PROPATCH or MKCOL/MKCALENDAR and can't handle the minimal response, then
> its a bad client.  If it can't handle a minimal success response is MUST
> NOT send return=minimal.  Likewise, if a server can't properly send a
> minimal response, then it MUST NOT return Preference-Applied.
>
> The more I think about this, I'm wondering why we can't specify that
> return=minimal requires an empty body upon success, or just specify that
> the server return 204.  If either a client or server can't implement it
> this way, then it is free to not use or ignore the preference.

We could, but then a 200 with text/plain "Success" is a valid HTTP
response message, and fully self-descriptive. A client that breaks for
it is just a broken client, no matter what it asked for.

We should resist the temptation to over-constrain things when HTTP
already gives the right answer.

>> Just state that the response can be any suitable success message (200,
>> 201, 204), and - for 200/201 - a response payload (a) is not needed
>> and (b) does not need to be processed.
>
> I'd really like to nail this down, so there isn't a any variance in
> responses.  If we can't specify empty body, can we just go with 204?

I would avoid that. Don't profile HTTP when you don't have to.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ken Murchison
On 2013-09-19 17:34, Ken Murchison wrote:

> ...
>> 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.
>
> Can you confirm that the following would be a valid multistatus
> response?  I think we had some question on that.
>
> <?xml version="1.0" encoding="utf-8"?>
> <D:multistatus xmlns:D="DAV:">
>    <D:response>
>      <D:href>/container/</D:href>
>      <D:status>HTTP/1.1 200 OK</D:status>
>    </D:response>
> </D:multistatus>


It appears so; the DTD for <response> is:

<!ELEMENT response (href, ((href*, status)|(propstat+)),
                     error?, responsedescription? , location?) >

That being said: if I client actually attempts DTD validation on
responses it will have lots of other problems :-).

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
In reply to this post by Julian Reschke
On 09/19/2013 11:43 AM, Julian Reschke wrote:
On 2013-09-19 17:32, Ken Murchison wrote:
On 09/19/2013 10:44 AM, Julian Reschke wrote:
On 2013-09-19 16:05, Ken Murchison wrote:
...
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.
...

I agree there's no need. I just wonder how strong the requirement no
to return anything is. I want to avoid a situation where clients blow
up just because they get a tiny status message.

Playing devil's advocate here: If a client sends return=minimal with a
PROPATCH or MKCOL/MKCALENDAR and can't handle the minimal response, then
its a bad client.  If it can't handle a minimal success response is MUST
NOT send return=minimal.  Likewise, if a server can't properly send a
minimal response, then it MUST NOT return Preference-Applied.

The more I think about this, I'm wondering why we can't specify that
return=minimal requires an empty body upon success, or just specify that
the server return 204.  If either a client or server can't implement it
this way, then it is free to not use or ignore the preference.

We could, but then a 200 with text/plain "Success" is a valid HTTP response message, and fully self-descriptive. A client that breaks for it is just a broken client, no matter what it asked for.

We should resist the temptation to over-constrain things when HTTP already gives the right answer.

Just state that the response can be any suitable success message (200,
201, 204), and - for 200/201 - a response payload (a) is not needed
and (b) does not need to be processed.

I'd really like to nail this down, so there isn't a any variance in
responses.  If we can't specify empty body, can we just go with 204?

I would avoid that. Don't profile HTTP when you don't have to.



OK.  How about something like this:

"... the server SHOULD return a 200 (OK) response, preferably with an empty (zero-length) message body, ..."

This suggests an empty body, but doesn't require it.
-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Reply | Threaded
Open this post in threaded view
|

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

Ken Murchison
In reply to this post by Julian Reschke
On 09/19/2013 10:53 AM, Julian Reschke wrote:

> On 2013-09-19 16:43, Ken Murchison wrote:
>> On 09/19/2013 10:38 AM, Cyrus Daboo wrote:
>>> Hi Ken,
>>>
>>> --On September 19, 2013 at 10:05:04 AM -0400 Ken Murchison
>>> <[hidden email]> wrote:
>>>
>>>>>> If you feel that this is a show-stopper, I can certainly remove this
>>>>>> text.
>>>>>
>>>>> I'd get rid of it.
>>>>
>>>> OK.
>>>>
>>>
>>> Well I do think it is worth mentioning that the Brief header exists
>>> and this new draft is defining a standards-based alternative to that -
>>> emphasizing that servers/clients that currently support Brief can also
>>> implement Prefer without any problems. The only thing to state is that
>>> if a server receives both Brief and Prefer it should prefer Prefer!
>
> Prefer: prefer
>
> /me ducks
>
>> Do you have any suggested text to replace/augment what I have in
>> Appendix A?  I think Julian wants me to remove the suggestion that
>> Prefer-based implementations also implement Brief.
>
> Stating where it came from is good (plus having the references).
>
> I just wouldn't recommend to implement it; if you do so, people *will*
> ask what the point of the new spec is.
>

How about something like this:

"Client and server implementations that already support the Brief field
header should be able to add support for the return=minimal preference
with little effort."  (I had "minimal effort" but it didn't read right)

"If a server receives both Brief and Prefer header fields in a request,
it MUST ignore the Brief header field and only apply the Prefer header
field preferences, if it so chooses."


--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ken Murchison
On 2013-09-19 17:50, Ken Murchison wrote:

> On 09/19/2013 11:43 AM, Julian Reschke wrote:
>> On 2013-09-19 17:32, Ken Murchison wrote:
>>> On 09/19/2013 10:44 AM, Julian Reschke wrote:
>>>> On 2013-09-19 16:05, Ken Murchison wrote:
>>>>> ...
>>>>>>> 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.
>>>>> ...
>>>>
>>>> I agree there's no need. I just wonder how strong the requirement no
>>>> to return anything is. I want to avoid a situation where clients blow
>>>> up just because they get a tiny status message.
>>>
>>> Playing devil's advocate here: If a client sends return=minimal with a
>>> PROPATCH or MKCOL/MKCALENDAR and can't handle the minimal response, then
>>> its a bad client.  If it can't handle a minimal success response is MUST
>>> NOT send return=minimal.  Likewise, if a server can't properly send a
>>> minimal response, then it MUST NOT return Preference-Applied.
>>>
>>> The more I think about this, I'm wondering why we can't specify that
>>> return=minimal requires an empty body upon success, or just specify that
>>> the server return 204.  If either a client or server can't implement it
>>> this way, then it is free to not use or ignore the preference.
>>
>> We could, but then a 200 with text/plain "Success" is a valid HTTP
>> response message, and fully self-descriptive. A client that breaks for
>> it is just a broken client, no matter what it asked for.
>>
>> We should resist the temptation to over-constrain things when HTTP
>> already gives the right answer.
>>
>>>> Just state that the response can be any suitable success message (200,
>>>> 201, 204), and - for 200/201 - a response payload (a) is not needed
>>>> and (b) does not need to be processed.
>>>
>>> I'd really like to nail this down, so there isn't a any variance in
>>> responses.  If we can't specify empty body, can we just go with 204?
>>
>> I would avoid that. Don't profile HTTP when you don't have to.
>>
>
>
> OK.  How about something like this:
>
> "... the server SHOULD return a200 (OK)response, preferably with an
> empty (zero-length) message body, ..."
>
> This suggests an empty body, but doesn't require it.

I wouldn't rule out 204.

"The server SHOULD return a minimal success response, such as 200 (OK)
(preferably with ...), or a 204 (No Content)."

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ken Murchison
On 2013-09-19 17:53, Ken Murchison wrote:

> On 09/19/2013 10:53 AM, Julian Reschke wrote:
>> On 2013-09-19 16:43, Ken Murchison wrote:
>>> On 09/19/2013 10:38 AM, Cyrus Daboo wrote:
>>>> Hi Ken,
>>>>
>>>> --On September 19, 2013 at 10:05:04 AM -0400 Ken Murchison
>>>> <[hidden email]> wrote:
>>>>
>>>>>>> If you feel that this is a show-stopper, I can certainly remove this
>>>>>>> text.
>>>>>>
>>>>>> I'd get rid of it.
>>>>>
>>>>> OK.
>>>>>
>>>>
>>>> Well I do think it is worth mentioning that the Brief header exists
>>>> and this new draft is defining a standards-based alternative to that -
>>>> emphasizing that servers/clients that currently support Brief can also
>>>> implement Prefer without any problems. The only thing to state is that
>>>> if a server receives both Brief and Prefer it should prefer Prefer!
>>
>> Prefer: prefer
>>
>> /me ducks
>>
>>> Do you have any suggested text to replace/augment what I have in
>>> Appendix A?  I think Julian wants me to remove the suggestion that
>>> Prefer-based implementations also implement Brief.
>>
>> Stating where it came from is good (plus having the references).
>>
>> I just wouldn't recommend to implement it; if you do so, people *will*
>> ask what the point of the new spec is.
>>
>
> How about something like this:
>
> "Client and server implementations that already support the Brief field
> header should be able to add support for the return=minimal preference
> with little effort."  (I had "minimal effort" but it didn't read right)

Right. You need a proper parser for "Prefer", after all.

> "If a server receives both Brief and Prefer header fields in a request,
> it MUST ignore the Brief header field and only apply the Prefer header
> field preferences, if it so chooses."

Sounds good to me.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Cyrus Daboo-2
In reply to this post by Ken Murchison
Hi Ken,

--On September 19, 2013 at 11:53:35 AM -0400 Ken Murchison
<[hidden email]> wrote:

> "Client and server implementations that already support the Brief field
> header should be able to add support for the return=minimal preference
> with little effort."  (I had "minimal effort" but it didn't read right)

Change:

"field header" to "header field"
"should be able to" to "can".

> "If a server receives both Brief and Prefer header fields in a request,
> it MUST ignore the Brief header field and only apply the Prefer header
> field preferences, if it so chooses."

The MUST and "if it so choose" are conflicting. How about:

    If a server supporting the Prefer header receives both Brief and Prefer
    header fields in a request, it MUST ignore the Brief header field and
    only use the Prefer header field preferences.

--
Cyrus Daboo