Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

[Doug Royer <[e-mail]>]

On 12/11/2014 02:01 PM, Cyrus Daboo wrote:
> Hi Doug,
>
> --On December 11, 2014 at 12:59:26 PM -0700 Doug Royer 
> <[e-mail]> wrote:
>
>> Perhaps some kind of a 'do you really want that old TZ' message could be
>> used. Both ways someone needs to notice/notify the other of an error.
>> Without sending the organizers TZ, how would anyone know?
>
> A key benefit of tzdist is to avoid the need to send around a whole 
> bunch of messages trying to "negotiate" the proper time zone. Clients 
> should simply not have to do that. As it is clients should not have to 
> include VTIMEZONE objects in iTIP messages - its a waste of bandwidth 
> and storage (and it is exactly why we have 
> draft-ietf-tzdist-caldav-timezone-ref which does do away with 
> VTIMEZONEs in the data exchanged between clients and servers).

There is no negotiate involved in ether method, if one is out of date in 
both models, things are busted.

It gives the illusion of not being needed. But offline CUAs exist, 
limited connectivity CUAs exist, and non-compliant CUAs will still 
exist. How will you tell if nothing is sent?

And it BREAKS ALL currently compliant CUAs.

I don't use caldav. The issue belongs in the base iCal/iTIP methods then 
it works for all transports. Most of my events come from MIME objects in 
email, some from URLs I download into my calendar. Other than testing, I 
have never gotten a caldav event.

Would the proposed method still send TZ data in email and file/url 
PUBLISH methods? if not you are proposing two different iCal object 
sets, caldav and non-caldav. That seems a bigger red flag.

> Having everyone agree to use a reliable and timely tzdist service 
> eliminates many (not all) of the big issues that exist today. Yes, 
> clients will still need to be smarter about dealing with time zone 
> changes when they occur - and that is what this debate needs to stay 
> focussed on. What information does tzdist need to provide in the data 
> it provides to ensure that clients have the necessary information to 
> do more advanced reconciliation of events when a time zone change occurs.
>

I disagree with it solving the error issue. It hides those issues and 
breaks existing code.

The issue it solves is with creating new or updating events. And for 
local time zones.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[e-mail]
714-989-6135