Last Call comment on Etag requirements in draft-dusseault-caldav-12

Hi, I note that draft 12 of caldav still makes requirements that are potentially incompatible with HTTP: Quoting : "In the case where the data stored by a server as a result of a PUT request is not equiv

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

I noticed that the ID tracker now has a comment from the authors (see ), which I'd like to comment over here...: Author's response to Last Call comments on ETags 1) Best common practice in WebDAV Curren

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

Julian Reschke wrote: I noticed that the ID tracker now has a comment from the authors (see ), which I'd like to comment over here...: Author's response to Last Call comments on ETags 1) Best common practic

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

On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote: I agree with Julian. As we've mentioned before, Apache returns a weak ETag on PUT, which turns into a strong ETag sometime later. If clients rely on being able to use that ETag on a GET later, they won't work with Apache, and

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

Lisa Dusseault schrieb: On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote: I agree with Julian. As we've mentioned before, Apache returns a weak ETag on PUT, which turns into a strong ETag sometime later. If clients rely on being able to use that ETag on a GET later, they won't

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

Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) behave this way and make the assumption I describe. How else would you expect a caching or synching client to behave after doing a PUT, when the implementors of those clients were pretty sure that WebDAV servers store

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

Wilfredo, does it make a difference that CalDAV specifies special ETag behavior only on Calendar Component resource items (not for all HTTP resources)? lisa On Jun 19, 2006, at 12:58 PM, Wilfredo Sánchez Vega wrote: Sure, OK, so some clients are broken today because they make some ass

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

Lisa Dusseault schrieb: Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) behave this way and make the assumption I describe. How else would you expect a caching or synching client to behave after doing a PUT, when the implementors of those clients were pretty sure tha

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

On Jun 20, 2006, at 9:56 AM, Julian Reschke wrote: Lisa Dusseault schrieb: Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) behave this way and make the assumption I describe. How else would you expect a caching or synching client to behave after doing a PUT, when

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

On Jun 20, 2006, at 10:27 AM, Wilfredo Sánchez Vega wrote: Not really, no. HTTP defines ETag. An HTTP server should be able to use the same ETag logic on all HTTP resources, and not treat ETags for calendar resources differently than others. Not all users of ETags are going to be a

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

Lisa Dusseault schrieb: My assertion was that if a strong ETag is returned, Xythos WFC assumes that what it PUT was what the server stored, and it seems you agree. You found that if a Last-Modified is returned instead, WFC makes the same assumption -- naturally, they're very similar. It seem

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

Lisa Dusseault schrieb: On Jun 20, 2006, at 10:27 AM, Wilfredo Sánchez Vega wrote: Not really, no. HTTP defines ETag. An HTTP server should be able to use the same ETag logic on all HTTP resources, and not treat ETags for calendar resources differently than others. Not all users of ET

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

Sure, OK, so some clients are broken today because they make some assumptions that are only valid on some server implementations. We know we need a solution; I just don't agree that CalDAV is the right place to specify it. I do understand how it's convenient. -wsv On Jun 19,

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

I agree with Julian. As we've mentioned before, Apache returns a weak ETag on PUT, which turns into a strong ETag sometime later. If clients rely on being able to use that ETag on a GET later, they won't work with Apache, and IIRC, Apache is pretty popular. The ETag requirements in

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

Not really, no. HTTP defines ETag. An HTTP server should be able to use the same ETag logic on all HTTP resources, and not treat ETags for calendar resources differently than others. Not all users of ETags are going to be aware that calendar resources are special. My concern is th

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

Actually, I remember sending a few emails with feedback on this and not getting any replies, and then I went on my honeymoon, so it wasn't quite on my mind for a while. I think that document is the way to go, even if all it ends up saying is something similar to what you have in the Cal

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

Cyrus Daboo schrieb: Hi Julian, --On June 5, 2006 8:30:25 PM +0200 Julian Reschke <[EMAIL PROTECTED]> wrote: I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (). For the record: as far as I can

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

On 7/25/06, Julian Reschke <[EMAIL PROTECTED]> wrote: 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

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

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.

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

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

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

Hi. I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (). 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

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

Hi Julian, --On June 5, 2006 8:30:25 PM +0200 Julian Reschke <[EMAIL PROTECTED]> wrote: I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (). For the record: as far as I can tell, the issue that I