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

[Mike Douglass <[e-mail]>]

On 12/11/2014 05:16 PM, Doug Royer wrote:
> 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.
>
It already appears to be the case that most server and client 
implementations - caldav or non-caldav - don't trust the data sent to 
them via iTip. That information is often truncated and/or out of date.

We managed to get away with it in the US because the rules changed so 
infrequently. Also there were many fewer centralized calendar services.

By providing an easily accessible and frequently updated timezone source 
hopefully we can reduce the errors.

At the moment the vtimezone information sent with iTip is mostly 
(expensive) noise and we (server and client implementors) treat it as such.

We ran tests on a number of current clients and servers - both through 
CalDAV and simply importing events - and dropping the VTIMEZONE 
information worked fine.

If an organizer sends an event with out of date tz rules I'm not going 
to present that to an attendee as if it is correct.

I'd argue that the iCalendar spec is deficient in that it ought to send 
the local time AND the UTC time as calculated by the organizers and 
attendees - that would give us all an opportunity to check the 
calculation using our (recently fetched) tz data. No version is needed - 
nor do we have to derive our tz rules from the same source. They just 
have to agree. That though is an extension to iCalendar and not 
something for tzdist.



>> 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.
>
>
>
> _______________________________________________
> Tzdist mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tzdist