Subject: Re: Omit VTIMEZONE when using global identifiers?

From: [email-masked]
Date: Mon, 23 Apr 2001 18:42:54 -0400

(Damn finger splint.  I clicked on send instead of finishing my email...)

Alan replied:
> All taking part in the discussion realised that the paramtext for TZIDs
> does not _have_ to be globally unique, we were discussing cases where
> the '/' prefix is used to imply a globally unique ID.

Ok, there are some compelling reasons FOR the inclusion of TZ information 
even when the TZID is a guid.  The ones I can think of include:

1: The receiving CUA may not have access to any still TBD TZ registry 
mechanism.  As such, they could not resolve any shifts properly! 
2: The receiving CUA may have a slightly different TZ definition for the 
TZID (ie: it was hard coded at ship time and is not dynamically resolved 
at process time).  As such, they would resolve any shifts possibly wrong. 
This would not make Dave Madeo very happy...
3: The receiving CUA may be an older CUA that does not know of any way to 
go and resolve/confirm the non-included TZID.  Again, this is not very 
nice.

I have yet to hear any good and strong reason NOT to include globally 
defined TZIDs (if and when we actually build a registration mechanism and 
get it up and running).  Anyone at CalConnect I or II think they could 
have properly handled a "TZID=/US-New York" referenece w/o it being in the 
iCalendar stream?? I thought not...

We do need to have some better means to convey 'revision of TZID' so that 
when we do get something going that we wont have to re-address issue #2. 
Thats probably best done by LAST-MODIFIED but that wont fit currently as a 
property parameter on DTSTART, etc...  Anyone got a suggestion on how to 
address the revision issue?  If not, Id say that not including the 
'global' TZID is something that really should be avoided...

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: John Stracke <[email-masked]>
Date: Tue, 24 Apr 2001 10:11:55 -0400

[email-masked] wrote:

> 1: The receiving CUA may not have access to any still TBD TZ
> registry mechanism.  As such, they could not resolve any shifts
> properly!

[...]

> 3: The receiving CUA may be an older CUA that does not know of
> any way to go and resolve/confirm the non-included TZID.
> Again, this is not very nice.

In any event, we don't want CUAs to go out and hit a global
registry every time they need a timezone definition, since that
would require a truly massive server.  Embedding the VTIMEZONE in
the event is a step toward reducing the registry's load.

(I believe the IESG tends to look skeptically on any proposal
that requires automatically consulting a global registry.  I
remember that WebDAV had some pushback on their use of URIs as
identifiers until they put in text that these URIs were never to
be resolved.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Chris is the most self-effacing guy I know."|
[email-masked]|"Well, I'm not *that* good at it."           |
\==============================================================/