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

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Sep 2013 14:04:07 +0200

(FYI)

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

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:[email-masked]> [1], which may
    be joined by sending a message with subject "subscribe" to <mailto
    :[email-masked]> [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
[email-masked]
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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 14:16:10 +0200

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

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 09:25:14 -0400

Thanks for the feedback Julian. Responses below.

On 09/19/2013 08:16 AM, Julian Reschke wrote:
> 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) 

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.

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

> Why do we need to mention CARDDAV here? This seems to be an unncessary 

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.

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

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

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

> s/subsquent/subsequent/

Fixed.

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

Done.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 15:37:53 +0200

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

> change this to a MUST or just drop the requirement.

My understanding is that it should not affect how the response is processed.

> should stay, but maybe I should point out how/where the server changes

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?

> body if the request is successful.  Do you recommend that we specify 204

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.

> If you feel that this is a show-stopper, I can certainly remove this text.

I'd get rid of it.

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 10:05:04 -0400

On 09/19/2013 09:37 AM, Julian Reschke 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.

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

> My understanding is that it should not affect how the response is 

I will ask for further clarification from the client author.

> It would be cool if the examples needed anything beyond RFC 4918 and 
> RFC 3253.
>

I will work on that.

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

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

>> If you feel that this is a show-stopper, I can certainly remove this 

OK.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 19 Sep 2013 10:38:03 -0400

Hi Ken,

>>> If you feel that this is a show-stopper, I can certainly remove this

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 10:43:30 -0400

On 09/19/2013 10:38 AM, Cyrus Daboo wrote:
> 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 - 
> 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.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 16:44:44 +0200

> instructions were performed successfully so there is no need for any

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.

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 16:53:08 +0200

>> if a server receives both Brief and Prefer it should prefer Prefer!

Prefer: prefer

/me ducks

> 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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 11:32:04 -0400

On 09/19/2013 10:44 AM, Julian Reschke wrote:
> 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.

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 11:34:03 -0400

> broken by this (and whether it's possible to fix it), or just some 

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>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 17:43:40 +0200

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 17:45:54 +0200

>      <D:status>HTTP/1.1 200 OK</D:status>

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 11:50:32 -0400

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Sep 2013 11:53:35 -0400

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 17:55:50 +0200

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Sep 2013 18:07:32 +0200

> with little effort."  (I had "minimal effort" but it didn't read right)

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

> field preferences, if it so chooses."

Sounds good to me.

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 19 Sep 2013 12:24:13 -0400

Hi Ken,

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

> 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