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

[Julian Reschke <[e-mail]>]

Lisa Dusseault wrote:
> 
> On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:
> 
>> Lisa Dusseault wrote:
>>> On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote:
>>>> Lisa Dusseault wrote:
>>>>> Unfortunately, that just does not solve the problem for CalDAV, 
>>>>> which is likely to have interoperability problems if we don't make 
>>>>> firm
>>>>
>>>> ...such as...?
>>> The near certainty, from talking to implementors, that some CalDAV 
>>> servers will add their own iCalendar properties to the body of the 
>>> iCalendar resources that clients create, and the undesirability of 
>>> clients always having to do GET after a PUT just to see whether this 
>>> in fact happened.  If we don't explain how to see whether this didn't
>>
>> Why would they need to do that?
> 
> Usually it's a bunch of concerns for backward compatibility with 
> existing systems -- e.g. compatibility with a limited set of timezone 
> definitions.  Timezones complicate this problem, as with so many other 
> problems.

Misunderstanding. What I meant was: why would the client need to know 
whether the server rewrote the entry? This would only be relevant if 
clients use an ETag returned upon PUT for a conditional GET with byte 
range header afterwards.

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