Subject: Re: Omit VTIMEZONE when using global identifiers?

From: [email-masked]
Date: Fri, 6 Apr 2001 14:14:45 -0400

George replied:
> > Also, if we define the global TZ registry, can we remove the 
requirement
> > to include a VTIMEZONE in a component when the TZID parameters 
reference
> > global names?
> 
>   Good idea.
> 
>   What happens when an application encounters a timezone from the
> the global TZ registry that was recently added, and that the application
> is not aware about? Should it assume that it came from the global 
registry
> and print a message saying something like: "your timezone registry may 
be out
> of date, please update." 

Whew, got lots of group backlog in just 4 days.  Good thing its possible 
to see a threaded view to keep up on it all...

Im not sure that not sending global definitions is that good an idea just 
yet.  Besides the case that a client may not have easy access to the 
absolute latest defintions (via some TBD mechanism that we haven't even thought about building yet) there is the problem that defintions may change and 
get updated.  For example, between 1973 and 1976 the US changed their DST 
shift rules every year.  France and Brazil set theirs on some regular 
basis as well.  As such, a client that uses the absolutely latest 
defintion may send a request to a client that has an earlier definition of 
the exact same TZID.  As such, misscheduling can occur.

The only solid way to prevent this from happening is to require that the 
VTIMEZONE information is always sent by the sender.  That way the 
receiving clients can tell if their definition of the 'standard' TZID is 
the same or not.  Otherwise we could have an issue with latency in 
timezone definition updates causing scheduling problems.

Unless an entry has some really really funky repeat set, the VTIMEZONE 
info that covers it should not be prohibitively large to include.  Of 
course for those .0001% of the end users out there who use a C&S system 
that allows for truely infinitely repeating events this could eventually 
become a bandwidth issue but I expect a newer protocol (or at least a 
newer revision) to deal with this kind of fringe use case later on...

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: [email-masked]
Date: Thu, 19 Apr 2001 10:29:28 -0400

John replied:
>Two different timezones in
>the same iCalendar could be solved by on-the-fly TZIDs.

I appologize for the timeout, Ive been heads down on some critical work 
in-house to the detriment of the WG list...

Actually, I would hope that the 'globally defined' TZIDs would be used 
over the "I think Ill name them Fred and Barney" TZID approach once we 
actually get the TZIDs registered.  Otherwise whats the use of globally 
registering them??  Lets just have chaos all around...

Bruce

---

From: [email-masked]
Date: Mon, 23 Apr 2001 18:28:08 -0400

Alan replied:
> To resplit some more hairs- if you reread the first passage,
> (which was quoted from the RFC) you'll see that the words "unique"
> and "globally" do appear in the normalative text, in the phrase
> 
>      "represents a unique ID in a globally defined time zone registry"

Thats taken out of context a bit.  The entire line is:

   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
   prefix, indicates that this TZID represents a unique ID in a globally
   defined time zone registry (when such registry is defined).

The original intent was that for non-solidus'd TZIDs the value is not a 
guid but rather luid (locally unique in the iCalendar stream).  For 
solidus'd values, the value MUST be a guid.  That does not address the 
issue of revisions to a standardized TZID (ie: France or David's Brazil 
calls) but it does provide a means for a CUA to find and possibly match a 
TZID that is not necessarily in the iCalendar stream (and even find the 
latest definition, etc).  There is no mention of non-solidus'd values 
being globally unique, that is just some inplicit extension of the cited 
text by some folks.

Frank can correct me if Im wrong about all this though.  Im not sure Derik 
is still even lurking on this list to confirm / deny this.  You can also 
search the archives for any thread on this topic going back to ~Day 1 if 
that would help.

Enough digression and hairs though.  I think we all agree that a TZID that 
is not solidus prefixed is NOT a guid and that we have an issue w/dealing 
with revision to standardized values which is separate from any RFC 2445 
update (since we have no registration system in place yet).  Any dissent 
on this at least?

Bruce

---

From: [email-masked]
Date: Mon, 23 Apr 2001 17:44:31 -0500

YES, Bruce. Local TZID has no SOLIDUS character and has a requirement to be
unique only within the iCalendar object. If the TZID value has a SOLIDUS
prefix, then it signals a registered value and MUST BE globally unique.
 
YES, there could be an issue about updates to registered time zone
definitions. Biggest problem right now is the lack of a registrar and
process!
 
-- Frank