Re: Where to put VTIMEZONE and VALARM?

[Eric Busboom <eric@xxxxxxxxxxxxxxxxxx>]

On Tue, 24 Apr 2001 Bruce_Kahn@xxxxxxxx wrote:

> Graham wrote on 04/24/2001 05:04:32 PM:
> >     I am suggesting renaming the older one(s) to a non-standardized
> > name(s), and keeping both (all) of the VTIMEZONEs at the VCALENDAR
> > level.
> 
> That would work for me. 

I really don't like the idea of requiring the receiver to rename the
TZIDs. It is just mandating a hack, and the problem should be solved
rather than hacked. 

> Anyone want to code up the matching of the original TZIDs from the 
> Organzier on later updates/invites w/the changed one??  

Given that there are no requirements for the time span that a VTIMEZONE
covers -- outside of covering the event it relates to -- I don't think
trying to match incoming VTIMEZONES with existing ones is a good idea
either. A CUA could send out any number of VTIMEZONEs with different time
spans, and the receiver would have to be smart enough to correlate these,
or risk having a potential enormous tmezone database. 

Besides, I think that is an abuse of the RRULEs. If we need a way to match
up two timezone definitions, let's make it explicit, rather than hoping
that the sender doesn't play odd games when constructing timezone
definitions. 

How about having the sender do the re-write rather than the client? That
is, the sender would use a TZID that is unique to the sender, basically
attaching a UID to every TZID that it uses? The sender should guarantee
that every TZID name that it sends out is associated with only one
timezone definition, and that that name is unique to it. 

I imagine that this would result in TZIDs that are correlated to:
	A Timezone
	A Vendor
	A Product
	A version of the timezone

So, suppose, for instance, that a TZNAME was:

	//Gnome/Evolution/1/America/Los_Angeles

The recipient can be assured that whenever it gets this name, the name
applies to a single version of a particular timezone, as it is defined by
the sender.  If the sender makes any changes to the definition, it
should use a new TZNAME.

Of course, there should be some signal to indicate that these names are
special -- perhaps the "//" as above?

This would also allow groups of vendors to create timezone databases on
their own. For instance the first version of the translation of the Olsen
database could use:

	//Olsen/1/America/Los_Angeles

To refer to version 1 of America/Los_Angeles in the Olsen database. A CUA
that also used this version of the Olsen database would not have to store
the VTIMEZONE of other products that used the same datbase.

If a CUA had version 1 of America/Los_Angeles and got version 2, then it
would just store it. 

If a CUA did get a conflict, it may resort to renaming, but in general
that would not be required. 

This would solve most of the problems that we have been discussing, such
as how to create a global registry and how to avoid conflicts with TZIDs,
without changing the storage model or requiring the recipient to muck with
the TZIDs.


eric.