Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd)

[Jari Urpalainen <[e-mail]>]

On Sat, 2006-04-15 at 10:17 +0200, ext Julian Reschke wrote:
> Lisa Dusseault wrote:
> > 
> > On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:
> > 
> >>> happen, some clients might always do a GET (poor performance) and 
> >>> others might always not (poor interoperability).
> >>
> >> Just tell clients to do conditional GETs with the cache validator they 
> >> got upon PUT. The client may not have the same content octet-for-octet 
> >> as the server, but besides that I see no problem (yet).
> > 
> > Yes, but that's exactly it, there's confusion about what the cache 
> > validator they got upon PUT means, or in what cases the server is 
> > allowed to return it.   Many clients cache calendar items for offline 
> > use, and if the server has added its own custom properties or modified 
> > data, that may well need to be available offline as well.
> 
> Currently, there's no way to find out. If this is a requirement, CalDAV 
> will either have to rely on draft-whitehead-http-etag solving that 
> problem, or come up with its own solution.
> 
> I'd prefer the former approach, because solving this once and for all 
> HTTP based specs certainly is better.
> 
> If CalDAV wants to do its own thing, it must make sure that it doesn't 
> contradict other specs, on which it builds or that servers may want to 
> implement in parallel with CalDAV. A safe way to do that for now would 
> be to add a new response header that contains just that piece of 
> information, such as:
> 
> 	X-Content-Rewritten: "T" / "F"
> 
> Best regards, Julian

We had similar ambiquities/difficulties with ETags in XCAP, where adding
new headers were not the preferred way to solve this kind of issues.
That said, as I have also previously said that 5.3.4 section was
somewhat difficult to understand and incorrect (rfc2616 reference and no
clear why reasoning of ETag behavior), I agree with Julian that a new
X-header or a normative reference to draft-whitehead-http-etag is a
better way to solve this issue, and certainly the latter option the best
one. 
br,
Jari