Subject: VTIMEZONE conflicts - possible solution

From: Damon Chaplin <[email-masked]>
Date: Wed, 02 May 2001 19:24:59 -0400

Here's my best idea yet for solving the VTIMEZONE TZID conflicts issue:

 o All the events that a CUA creates itself are placed inside one
   VCALENDAR component, together with all the VTIMEZONES that are used.

 o Events that come in externally, either via iTIP or from importing
   iCalendar data, are placed in separate VCALENDAR components, so they
   can simply keep whatever VTIMEZONEs they come with.

 o The CUA uses a property of some kind on the VCALENDAR,
   e.g. "X-EVOLUTION-VTIMEZONES-VERSION:1.2" to identify the version of
   the builtin VTIMEZONES used within that VCALENDAR. So when it
   wants to create more events it knows which VCALENDAR to add them to.

This would totally avoid the clashing TZID issue, even when the
VTIMEZONEs in the CUA get updated. (It would simply create a new
VCALENDAR with a different X-EVOLUTION-VTIMEZONES-VERSION.)

It also means we don't need to define some new URL-like syntax for
TZIDs (which I still think is a bad idea by the way!)

Damon

---

From: Eric Busboom <[email-masked]>
Date: Thu, 3 May 2001 10:15:52 -0700 (PDT)

On Wed, 2 May 2001, Damon Chaplin wrote:

>  o All the events that a CUA creates itself are placed inside one...
>  o Events that come in externally, either via iTIP or from importing... 
>  o The CUA uses a property of some kind on the VCALENDAR,...

OK, you can certainly do this. These are implementation choices, and an
implementation can store data any way it wants to. But, since these
proposals affect the storage model, they wouldn't be something we could
add to the RFC, and we still should have a specification level solution. 

> TZIDs (which I still think is a bad idea by the way!)

I am not fond of the URI-like syntax either -- I think that either it
should be a URI or it shouldn't be. I just want to require that TZIDs that
begin with a "/" are globally unique, like in a UID or a PRODID. Here is
my proposal again:

------------------------------------------------------------------------------
 
The presence of the SOLIDUS character ( US-ASCII 47) as a prefix
indicates that distinct usages of the TZID will refer to functionally
equivalent timezone data. Two VTIMEZONE are "functionally equivalent" when
the set of time shifts generated by one VTIMEZONE is equivalent to the set
generated by the other.
 
The generator of a TZID MUST ensure that the TZID with a SOLIDUS prefix
uniquely references a single set of timezone shifts. The generator of such
a TZID SHOULD include in the TZID the name of the database where the
timezone information is stored, the name of the timezone, and the version
of the data.
 
For example:
        TZID:=/TimezoneEmporium/America/New_York/1
 
------------------------------------------------------------------------------  

Note that if the sender does not use a TZID with a '/', then the recipient
may have to tackle the problem of timezone conflicts itself. In that
case, I'd suggest that the CUA uses a variant of your re-naming scheme as
a fallback. Maybe it would rename the tmezone to include the organizer's
name, the PRODID of the EVENT that the organizer sent, and a version
number that it determined from comparing the timezone data. Thus you might
change: 

	/America/Los_Angeles 

to 

	/[email-masked]/ABC Corp/1/America/Los_Angeles

Now you have a result similar to if the sender had used the global form --
the TZID is unique and you don't have to store multiple copies of them if
they are all the same.

So, our two ideas are not exclusive; I'm proposing a spec-level solution,
and you are proposing implementation-level solutions. Both can be
implemented with no loss to either.

eric.

---

From: Damon Chaplin <[email-masked]>
Date: Thu, 03 May 2001 14:53:41 -0400

> add to the RFC, and we still should have a specification level solution.

My proposed solution can easily be turned into a spec-level solution.
Just say that a VCALENDAR is a way to group components which share a
set of VTIMEZONEs. And give guidelines for handling data from external
sources.

I think if we can avoid the possibility of security problems we should.

Damon

---

From: Eric Busboom <[email-masked]>
Date: Thu, 3 May 2001 13:22:19 -0700 (PDT)

> set of VTIMEZONEs. And give guidelines for handling data from external

OK. Send some proposed text. 

eric.

---

From: Damon Chaplin <[email-masked]>
Date: Fri, 04 May 2001 14:48:59 -0400

>         TZID:=/TimezoneEmporium/America/New_York/1

If we do go with this, it would be useful to make it easy to separate
out the actual timezone, e.g. 'America/New_York', so it can be
displayed to the user.

Remember that some Olson zones have 2 '/'s, e.g. 'America/Indiana/Marengo'.
(Don't ask me why!)

Damon

---

From: John Stracke <[email-masked]>
Date: Mon, 07 May 2001 12:37:58 -0400

> timezone information is stored, the name of the timezone, and the version

What problem are you trying to solve, again? The VCALENDAR MUST contain the
VTIMEZONE to which the TZID refers, so there's no great need for the TZID to be
globally significant.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"How quietly do you think we can nail these back|
[email-masked]|in?" --Calvin                                   |
\=================================================================/

---

From: John Stracke <[email-masked]>
Date: Mon, 07 May 2001 12:34:06 -0400

> out the actual timezone, e.g. 'America/New_York', so it can be

That's what TZNAME is for.

---

From: Damon Chaplin <[email-masked]>
Date: Mon, 07 May 2001 16:29:35 -0400

> That's what TZNAME is for.

Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component?
It seems silly to duplicate it within each STANDARD and DAYLIGHT subcomponent.

And if the TZNAMEs are actually different in some of the STANDARD and DAYLIGHT
components, which one do we display?

Damon