Subject: Last Call comment on Etag requirements in draft-dusseault-caldav-12

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Apr 2006 12:30:19 +0200

Hi,

I note that draft 12 of caldav still makes requirements that are 
potentially incompatible with HTTP:

Quoting 
<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.section.5.3.4.p.4>:

"In the case where the data stored by a server as a result of a PUT 
request is not equivalent by octet equality to the submitted calendar 
object resource, the behavior of the ETag response header is undefined, 
with the exception that a strong entity tag MUST NOT be returned in the 
response. As a result, clients may need to retrieve the modified 
calendar object resource (and ETag) as a basis for further changes, 
rather than use the calendar object resource it had sent with the PUT 
request."

This is a requirement that is not in RFC2616. Adding this to CalDav may 
make it impossible to implement resources that are both compliant to 
CalDav and other HTTP based specifications (which may have a different 
opinion about ETags in PUT responses).

If CalDav clients *really* require knowledge about this situation, 
please define it in a way that will not potentially be in conflict with 
other specifications, such as by adding a *new* response header, 
indicating that content was not rewritten (as proposed in 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html> 
two weeks ago).

Best regards, Julian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Apr 2006 13:25:54 -0700

Thanks for the input.  Speaking as a document author here, I'm  
confident we've made a decent set of tradeoffs, balancing possible  
risks against benefits, and attempting to minimize the risks too.

The basic risk is that any requirements related to ETags may conflict  
with future requirements.  We've attempted to minimize this risk by  
making only one requirement -- that servers MUST NOT return strong  
ETags if they have changed the data provided to be stored.  We  
believe that this requirement is quite within the spirit of ETag  
design.   We didn't make any requirements about weak ETags, nor did  
we require any behavior that future specs might make illegal.  Since  
today with HTTP it's perfectly acceptable not to return an ETag at  
all, future requirements on ETags would at least have to work with a  
huge deployed base of HTTP servers that don't return any ETag on PUT  
responses.

Thus, any future ETag-related requirements that invalidated this  
CalDAV requirement, would also conflict with the huge deployed base  
of HTTP.  I find that sufficiently unlikely as to be an acceptable  
risk to take.  Any standard we write has some risk of making  
requirements that are in conflict with future spec requirements and  
so we always take this kind of risk.

I do hope that new work on ETags and PUT will clarify this situation  
further for all protocols, and if it becomes desirable to re-issue  
CalDAV to make use of that general work, I'll be happy to re-issue it.

Lisa

On Apr 27, 2006, at 3:30 AM, Julian Reschke wrote:

> Quoting <http://greenbytes.de/tech/webdav/draft-dusseault- 
> caldav-12.html#rfc.section.5.3.4.p.4>:
>
> request is not equivalent by octet equality to the submitted  
> calendar object resource, the behavior of the ETag response header  
> is undefined, with the exception that a strong entity tag MUST NOT  
> be returned in the response. As a result, clients may need to  
> retrieve the modified calendar object resource (and ETag) as a  
> basis for further changes, rather than use the calendar object  
> resource it had sent with the PUT request."
>
> This is a requirement that is not in RFC2616. Adding this to CalDav  
> may make it impossible to implement resources that are both  
> compliant to CalDav and other HTTP based specifications (which may  
> have a different opinion about ETags in PUT responses).
>
> please define it in a way that will not potentially be in conflict  
> with other specifications, such as by adding a *new* response  
> header, indicating that content was not rewritten (as proposed in  
> <http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/ 
> 000787.html> two weeks ago).
>
> Best regards, Julian
>
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Apr 2006 22:42:03 +0200

Lisa Dusseault wrote:
> Thanks for the input.  Speaking as a document author here, I'm confident 
> we've made a decent set of tradeoffs, balancing possible risks against 
> benefits, and attempting to minimize the risks too.
> 
> making only one requirement -- that servers MUST NOT return strong ETags 
> if they have changed the data provided to be stored.  We believe that 
> this requirement is quite within the spirit of ETag design.   We didn't 
> make any requirements about weak ETags, nor did we require any behavior 
> that future specs might make illegal.  Since today with HTTP it's 
> perfectly acceptable not to return an ETag at all, future requirements 
> on ETags would at least have to work with a huge deployed base of HTTP 
> servers that don't return any ETag on PUT responses.
> 
> Thus, any future ETag-related requirements that invalidated this CalDAV 
> requirement, would also conflict with the huge deployed base of HTTP.  I 

How so?

A potential requirement of an XyzDav spec to return ETags even though 
the content was rewritten wouldn't be in conflict with HTTP at all. It 
would just be impossible to implement a resource that's both compliant 
to CalDAV and XyzDav.

This is why I think CalDav uses the wrong approach. There's a simple way 
to give CalDav clients that piece of information and which is guaranteed 
to be compatible with other specs, and that's what CalDav should do.

Or, alternatively, it could just stay silent and let that other spec 
work out the solution, instead of trying to come up with a fait accompli.

 > ...

Best regards, Julian