Subject: Re: Where to put VTIMEZONE and VALARM?

From: [email-masked]
Date: Tue, 24 Apr 2001 17:45:14 -0400

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. 

Anyone want to code up the matching of the original TZIDs from the 
Organzier on later updates/invites w/the changed one??  Id love to hear 
from Damon or Eric about how they approached this since one of them raised 
it recently...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Eric Busboom <[email-masked]>
Date: Wed, 25 Apr 2001 11:37:53 -0700 (PDT)

> > name(s), and keeping both (all) of the VTIMEZONEs at the VCALENDAR

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. 

> 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.

---

From: Damon Chaplin <[email-masked]>
Date: Sun, 29 Apr 2001 19:42:07 -0400

> the sender.  If the sender makes any changes to the definition, it

But what happens if a malicious app sends out VTIMEZONEs with the
same TZIDs as a proper client app? It could mess up your timezone
database.

I still think the simplest thing to do is just rename clashing
TZIDs, so you get "America/Los_Angeles", "America/Los_Angeles(2)",
"America/Los_Angeles(3)", etc.

Its fairly easy to do and works with existing iCalendar apps.
And it should only happen when you import iCalendar data or get
an iTIP request.

Damon

---

From: Eric Busboom <[email-masked]>
Date: Sun, 29 Apr 2001 22:53:32 -0700 (PDT)

> same TZIDs as a proper client app? It could mess up your timezone

Don't overwrite existing TZID entries with new ones. Not only would the
attacker have to guess the right TZID, including zone name and database
name, and be the first to send you a meeting with that TZID, but you would
also have to book the meeting on the calendar. That is very remote, and
even if it succedes, it is not very exciting for the attacker.

> "America/Los_Angeles(3)", etc.

But in this case you are certain to have one copy of every VTIMEZONE that
you have every recieved, and a CS will have to store a copy for every
VTIMEZONE that every user has ever recieved. 

With the current proposal, there is no renaming for the client to do, and
the VTIMEZONES can be shared. That is even easier that the renaming; all
you have to do is set the names in the timezone database to follow the
poposed form, and use them as they come out of the database --- there is
no renaming to do anywhere. 

eric.

---

From: Damon Chaplin <[email-masked]>
Date: Mon, 30 Apr 2001 15:27:44 -0400

> even if it succedes, it is not very exciting for the attacker.

They don't have to guess the TZIDs - they can just read them in iMIP
requests.

Admittedly it is remote, but iCalendar shouldn't leave the slightest
possibility of someone else interfering with your calendar.

> VTIMEZONE that every user has ever recieved.

You can compare VTIMEZONEs so you don't have duplicates.

> no renaming to do anywhere.

I agree that it would be nicer to do it that way. (I think I even
suggested
something like that a while back.) But I think it is insecure so we
can't.

Damon