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

[Lester Caine <[e-mail]>]

On 13/12/14 01:13, Doug Royer wrote:
>> ...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). ...
> 
> I do agree tzdist is the best way!
> 
> Transitionally, CUAs that are currently compliant are going to send them
> and some will choke if they are not included. The WebEx meeting to this
> working group is an example. It send the VTIMEZONE and everyone that
> uses it will call in at the same UTC time. Assuming their CUA uses it :-)
> 
> Replacing it with TZID + TZURL + some version info is also acceptable if
> that is the direction to move. Just don't ban VTIMEZONE as email (iTIP)
> may be the only way to get appointment information on Internet
> restricted systems.

Strip section in some strange language I do not understand ;)

I think that this perhaps is a fundamental part of the problem? Since
the charter is predicated on iCalendar in an attempt to 'make things
easy for the first pass', all of the baggage of that is weighing down
the discussion. My own starting point bypasses that baggage simply
because it did not provide a usable base. VTIMEZONE came into existence
because of the unreliability of a users TZ local data? Fix that problem
and the need goes away? So using it to fix the problem is part of what
is wrong here? I'm looking for tzdist to provide a SINGLE reliable view
of TZ that gets around all of the problems currently CREATED by the
likes of iCalendar and the other consumers of TZ using different views.
iCalendar is only one user and not one that many embedded systems would
use for example, which is why 'expand' being a separate tzdist function
IS necessary.

This is why for me avoiding contaminating the TZ rule set with
conversions to VTIMEZONE's different format IS important. I have no
problem with a third party server producing VTIMEZONE converted TZ data
in much the same way as tzurl already seems to do? The FIRST requirement
of tzdist should be to ensure that the core data used for that matches
every body else's ... a step that the charter totally scraps. But as
long as one can access *A* clean and reliable source AND be able to
identify the version of it that was used for a particular job, then I
will be happy. It's the fact that currently when I look at data from
200x the TZ data is an unknown even if the publisher claims a particular
TZ version.

Once one has a reliable way of getting a stable set of data out in the
field, for which version is a key element, then everything else should
dovetail in on top. Much of the side discussion on the EXISTING race
hazard is in how the current process works and 'not breaking' something
that is fundamentally already broken? If event data is published with a
simple tag to the used tzdist version, the whole job becomes simple and
if people WANT to take advantage of the security provided by being able
to see that the current tzdist version is different then they can do ...
or they continue to simply ignore the information.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk