On 8/29/06, Julian Reschke <julian.reschke@xxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf