On 8/29/06, Julian Reschke <julian(_dot_)reschke(_at_)gmx(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf