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

[Julian Reschke <[e-mail]>]

Hi.

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).

Best regards,

Julian

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


Julian Reschke wrote:
> Lisa Dusseault wrote:
>> Thanks for the input.  Speaking as a document author here, I'm 
>> confident we've made a decent set of tradeoffs, balancing possible 
>> risks against benefits, and attempting to minimize the risks too.
>>
>> The basic risk is that any requirements related to ETags may conflict 
>> with future requirements.  We've attempted to minimize this risk by 
>> making only one requirement -- that servers MUST NOT return strong 
>> ETags if they have changed the data provided to be stored.  We believe 
>> that this requirement is quite within the spirit of ETag design.   We 
>> didn't make any requirements about weak ETags, nor did we require any 
>> behavior that future specs might make illegal.  Since today with HTTP 
>> it's perfectly acceptable not to return an ETag at all, future 
>> requirements on ETags would at least have to work with a huge deployed 
>> base of HTTP servers that don't return any ETag on PUT responses.
>>
>> Thus, any future ETag-related requirements that invalidated this 
>> CalDAV requirement, would also conflict with the huge deployed base of 
>> HTTP.  I 
> 
> How so?
> 
> A potential requirement of an XyzDav spec to return ETags even though 
> the content was rewritten wouldn't be in conflict with HTTP at all. It 
> would just be impossible to implement a resource that's both compliant 
> to CalDAV and XyzDav.
> 
> This is why I think CalDav uses the wrong approach. There's a simple way 
> to give CalDav clients that piece of information and which is guaranteed 
> to be compatible with other specs, and that's what CalDav should do.
> 
> Or, alternatively, it could just stay silent and let that other spec 
> work out the solution, instead of trying to come up with a fait accompli.
> 
>  > ...
> 
> Best regards, Julian
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 


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