Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)

On 8/29/06, Julian Reschke <julian.reschke@gmx.de> wrote:
> >> Section 5.3.4., para. 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 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. [[anchor22: See comments on ietf-
> >>      discuss mailing list. --reschke]]
> >>
> >> -> Not fixed.
> >
> > Correct.
>
> Yet, this is the problem I'm concerned about most.

Why can't the CalDAV spec note the ambiguity with Etags and move on? I
don't think it's appropriate for this document add semantics to the
general purpose ETag header with a MUST NOT, since "calendar object
resource" is meaningless from a general HTTP perspective.

also concerned,

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf