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

[Julian Reschke <julian.reschke at gmx.de>]

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 seems that the client always assumes that the server does no 
content-rewriting, no matter what it returns. So it's incorrect to 
assume it makes specific assumptions about ETags on PUTs. It doesn't.

> You're probably quite right about the general case, that existing WebDAV 
> clients don't handle content-rewriting servers at all.  What's the best

Several clients handle it well, because they don't have a local content 
cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP 
Netweaver KM.

> thing a content-rewriting server can do in this situation?  I would hope 
> that if a client receives neither an ETag nor a Last-Modified in a PUT 
> response, then the next time it synchronizes and sees an ETag that it's 
> never seen before, the client downloads the resource.  This allows the 
> content to eventually get synchronized although perhaps not as fast as 
> would be ideal.

As there's no guarantee in HTTP about content rewriting not occurring, 
clients should always re-sync (at some point of time). An optimization 
(which happens to be the one I've been proposing several times now) 
would be a way for the server to indicate that content was *not* 
rewritten, avoiding the additional retrieval.

> But CalDAV clients will have to handle content-rewriting servers at 
> least handling events (calendar component resources), because during 
> protocol development we heard from a couple server developers that 
> they'd need to add custom iCalendar properties to an event as soon as it 
> was stored, thus rewriting the content.

Yes. I'm not sure how this is different from the generic case, though.

Best regards, Julian

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