Subject: draft-murchison-webdav-prefer

From: Ken Murchison <[email-masked]>
Date: Thu, 18 Dec 2014 10:23:10 -0500

All,

I'd like to get some feedback on draft-murchison-webdav-prefer 
<http://tools.ietf.org/html/draft-murchison-webdav-prefer-07> , 
specifically Section 3 
<http://tools.ietf.org/html/draft-murchison-webdav-prefer-07#section-3> 
(the rest of the document is truly WebDAV specific).  Per a request from 
the Apple calendar client folks, we'd like to extend 
Prefer:return=representation 
<http://tools.ietf.org/html/rfc7240#section-4.2> to apply to a 
conditional PUT request that fails with a 412 (Precondition Failed) 
response.  This eliminates the need for a subsequent GET to fetch the 
current representation of a resource that failed to update because of a 
validator mismatch.  I view this as analogous to Get + If-Range.

Does anyone see any issues with this new behavior?  Does it violate 
RFC7230-7232 in any way?  Are we allowed to extended 
return=representation to failure responses (RFC7240 only discusses 
success responses)?  Are there any other sane interpretations of a 412 
response with a Preference-Applied:representation header field which 
would cause ambiguity for the client?

Thanks and Happy Holidays!
Ken

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: James M Snell <[email-masked]>
Date: Thu, 18 Dec 2014 07:52:05 -0800

I think that behavior is acceptable. Please be sure to include the
Preference-Applied response header tho. Just to make it unambiguous.
On Dec 18, 2014 7:26 AM, "Ken Murchison" <[email-masked]> wrote:

> RFC7230-7232 in any way?  Are we allowed to extended return=representation
> to failure responses (RFC7240 only discusses success responses)?  Are there
> any other sane interpretations of a 412 response with a
> Preference-Applied:representation header field which would cause ambiguity
> for the client?
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Dec 2014 16:55:35 +0100

On 2014-12-18 16:23, Ken Murchison wrote:
> ...

To make this useful, the response would also need to return the new 
ETag, right?

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Thu, 18 Dec 2014 10:56:45 -0500

Hi James,

> Preference-Applied response header tho. Just to make it unambiguous.

Yes, absolutely.  The example in the draft includes it as does my dev 
implementation.

> On Dec 18, 2014 7:26 AM, "Ken Murchison" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     All,
>
>     (the rest of the document is truly WebDAV specific).  Per a
>     request from the Apple calendar client folks, we'd like to extend
>     conditional PUT request that fails with a 412 (Precondition
>     Failed) response.  This eliminates the need for a subsequent GET
>     to fetch the current representation of a resource that failed to
>     update because of a validator mismatch.  I view this as analogous
>     to Get + If-Range.
>
>     Does anyone see any issues with this new behavior?  Does it
>     violate RFC7230-7232 in any way?  Are we allowed to extended
>     success responses)?  Are there any other sane interpretations of a
>     412 response with a Preference-Applied:representation header field
>     which would cause ambiguity for the client?
>

---

From: Ken Murchison <[email-masked]>
Date: Thu, 18 Dec 2014 10:58:34 -0500

> To make this useful, the response would also need to return the new 

Yes.  That is shown in the example, but I can add text to reinforce that 
point if you feel its necessary.

On another note, I'm assuming since the representation corresponds to 
the request URI, that Content-Location isn't required, correct?