Re: [Tzdist] AD review of draft-ietf-tzdist-caldav-timezone-ref-03

[Cyrus Daboo <[e-mail]>]

Hi Eliot,

--On August 25, 2015 at 7:27:47 AM +0200 Eliot Lear <[e-mail]> wrote:

>> That also sounds reasonable.  What will the default be if
>> CalDAV-Timezones is absent?
>>
>
> For backward compatibility I would suggest that it be that VTIMEZONEs
> are transmitted.

Well actually I would rather stick with what the current spec says: by 
default no vtz is sent - but the new text I proposed would make it clear 
that an exception might have to be made for a small number of existing 
clients. The point is to provide the immediate benefit of not sending vtz 
to existing clients without having to wait for them to be updated to send 
the new header.

The alternative to the above, is to go with the default of sending vtz, but 
allow the server to "whitelist" known clients and not send vtz to those. 
Most implementations would simply whitelist everything and then special 
case those clients that would be a problem - in effect making the default 
to not send vtz. However, defining like this does make it appear to be more 
backwards compatible.

In summary, two choices for the WG (with #1 being the currently defined 
behavior):

1) In the absence of the new request header, by default the server does not 
send VTIMEZONE components, but it SHOULD provide an option to override that 
behavior for specific clientsE, based on User-Agent, that always require a 
VTIMEZON.

2) In the absence of the new request header, by default the server always 
sends VTIMEZONE components, but it MAY provide an option to override that 
behavior for specific clients, based on User-Agent, that are known to 
ignore VTIMEZONEs in the data.

-- 
Cyrus Daboo