Re: [Tzdist] WG Document Adoption

[Cyrus Daboo <[e-mail]>]

Hi Lester,

--On August 25, 2014 at 12:25:17 PM +0100 Lester Caine <[e-mail]> 
wrote:

> It would seem that decisions have already been made as to the way
> forward which already precludes a more complete solution which does not
> have the restrictions imposed by iCalendar?

No. We (Mike and I and others at CalConnect) have also had the hope that 
the tzdist protocol could be extended to support delivery of time zone data 
in other formats. In particular, we would like to see zoneinfo data 
delivered directly via tzdist. We have tried to ensure we have enough 
extensibility in the protocol to support that in the future. But for now, 
our focus has been on iCalendar because that is where we have an actual 
demand for this service. In fact, tzdist came about because iCalendar 
vendors with their own web-calendar products had already invented their own 
proprietary tzdist protocol to support web-calendar local time 
calculations. And now we also have CalDAV/iCalendar products that want to 
use the "timezones-by-reference" approach to improve performance (as per 
the other draft being proposed for adoption in this WG: 
draft-daboo-caldav-timezone-ref-01).

> Either the service is to provide timezone data in it's entirety, or it
> should identify the fact that it is only really intended to support
> 'modern day' timezone information. But even here, I don't think proper
> consideration has been given to passing on current updates to timezone
> information in a reliable manor.

Isn't it sufficient to advertise the "truncation" dates as we do now? I 
agree that perhaps we should have a clearer idea of the lower bound

> I actually object to draft-douglass-timezone-service-11 simply because
> it is reliant on a third party document to provide key definitions ...
> the RFC5545 provides VTIMEZONE, but in isolation to this document, and
> we therefore do not have a standard transfer format that can be used as
> a base to provided other formats. The VTIMEZONE format needs a few
> tidies to ensure that the tzdist mechanism will work reliably!

Can you enumerate some specific things you think are missing from 
VTIMEZONE? The fact remains, that for the most part, "consumers" of 
VTIMEZONE are typically focussed on only a small period of time (recent 
past to recent future) as is the nature of events created and managed by 
iCalendar clients.

> I understand the need to make things practical, but taking short cuts is
> what has resulted in problems existing for decades simply because there
> is not a standard. Even once there is a timezone service available it is
> still restricted by how other systems interact with it and since a lot
> of the time we have no idea on a clients current timezone simply having
> the information available may be pointless?

My take on your concerns is that we need to make sure that we have enough 
pieces in the current protocol to support delivering more comprehensive 
time zone data in the future if such formats appear. It definitely seems 
that a more precise way to indicate a lower bound of validity may be needed 
in spite of the fact such a thing does not really exist in iCalendar.

So do you think that the addition of some addition properties to the tzdist 
protocol (excluding VTIMEZONE) would be sufficient to cover the case of 
future, more comprehensive, time zone data formats? If so, can we wait for 
those to be defined in "version: 2" of the tzdist protocol once such data 
formats arise?

> ( Slight aside is VTIMEZONE going to be replaced by VTIME_ZONE ! To my
> mind even that 'change' has not been fully reviewed? )

No - I have said that I will change "timezone" to "time zone" in 
descriptive text, but I have no intention of forcing protocol elements to 
use split terms (either time-zone or time_zone when spaces are not 
allowed). As for VTIMEZONE, that has been a standard for almost 20 years 
now - it is never going to change. Of course iCalendar could be replaced by 
something different in the future and that can do whatever it wants...

-- 
Cyrus Daboo