Subject: Re: VTIMEZONE conflicts - possible solution

From: [email-masked]
Date: Thu, 3 May 2001 16:16:04 -0400

Damon replied on 05/03/2001 02:53:41 PM:
> 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. 

Im not sure I like.  If I want to include VEVENTs, VTODOs or VJOURNALs 
that are in UTC then I cannot also include them?  It also smells like a model change and Ive very unkeen on that.  It certainly wont be true of 
any currently shipping CUAs like Outlook, Lotus Organzier and possibly 
others... (That would mean possibly reving VERSION, ugh!!!)

This proposal just sounds likes it pushing the version info from the TZID 
(Erics proposal) into a new property so where is the benefit of doing 
that? 

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

I think this is really a messy CS/CUA storage issue that may not be 
something Id want to build.  I (as a product) view a Calendar as a 
collection of entries no matter the vendor or TZ.  W/this proposal I now 
have to segregate my entries into separate 'calendars' that are related 
simply by TZIDs.  What does this buy me?   Just lots of "which calendar is 
that #!^# UID in?!" agravation IMNHO.  I dont think it makes interop any 
better/easier so what am I missing??

Bruce
PS: Time to go get some food and raise my blood sugar levels so I can 
sound more coherent...
===========================================================================
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: [email-masked]
Date: Tue, 8 May 2001 10:47:38 -0400

Damon wrote on 05/04/2001 02:48:59 PM:
> Remember that some Olson zones have 2 '/'s, e.g. 
'America/Indiana/Marengo'.
> (Don't ask me why!)

That would suggest that we do not want to use '/' as our delimiter if we 
define a new URI like format that is easily decomposable.  Unless we decide that it must be 
prefixed w/an escape character making it something like 'America/Indiana\/Marengo' or we encode it ala 'America/Indiana%2FMarengo' neither of which Im too fond to as it makes the TZID a pseudo URI.   I 
think that an alternate delimiter is probably a safer and cleaner way to 
go (assuming we take this path entirely).

Bruce