Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

[Julian Reschke <[e-mail]>]

Cyrus Daboo schrieb:
> Hi Julian,
> 
> --On June 5, 2006 8:30:25 PM +0200 Julian Reschke 
> <[e-mail]> wrote:
> 
>> I notice that draft-dusseault-caldav-12 now is in IESG Evaluation
>> (<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>> =11253>).
>>
>> For the record: as far as I can tell, the issue that I raised below is
>> critical (given the fact that we have a separate activity to clarify this
>> in HTTP), and has not been addressed. It's not clear to me whether the
>> client issue it attempts to solve really is important. If it is, there is
>> a simpler way to accomplish this ([1]) that doesn't risk making CalDAV
>> incompatible with other specs extending HTTP (or HTTP itself, for that
>> matter).
> 
> We are planning on addressing this ETag issue in a revision now that 
> last-call is over. Authors are discussing right now.

The new text says 
(<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-13.html#rfc.section.5.3.4.p.2>):

"A response to a GET request targeted at a calendar object resource MUST 
contain an ETag response header field indicating the current value of 
the strong entity tag of the calendar object resource.

Servers SHOULD return a strong entity tag (ETag header) in a PUT 
response when the stored calendar object resource is equivalent by octet 
equality to the calendar object resource submitted in the body of the 
PUT request. This allows clients to reliably use the returned strong 
entity tag for data synchronization purposes. For instance, the client 
can do a PROPFIND request on the stored calendar object resource and 
have the DAV:getetag property returned, and compare that value with the 
strong entity tag it received on the PUT response, and know that if they 
are equal, then the calendar object resource on the server has not been 
changed.

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 not 
specified here, 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."

Again, this profiles HTTP in a way that may turn out to be incompatible 
with the way the issue will be resolved in general; also this conflicts 
with ETag requirements in XCAP, which is also under IESG evaluation. By 
all means, please let this issue be clarified in a *single* place and in 
a way consistent for all HTTP resources.

Also note a proposal was made back in April how CalDAV *could* resolve 
the syncing issue without relying on a specific ETag behavior which may 
not be the one a clarification of HTTP yields (see [1]). It would have 
been nice if the authors would have given feedback on why the proposed 
solution doesn't work for them.


Best regards, Julian


[1] 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html>




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