Cyrus Daboo schrieb:
Hi Julian,
--On June 5, 2006 8:30:25 PM +0200 Julian Reschke
<julian.reschke@xxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf