Subject: Re: Where to put VTIMEZONE and VALARM?

From: [email-masked]
Date: Thu, 26 Apr 2001 15:00:25 -0400

eric wrote on 04/25/2001 02:37:53 PM:
> 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

This is kinda like creating a PRODID for TZs but actually using it as a 
key of sorts (unlike our prohibition on relying on the PRODID value to 
impart extra meaning to items).  It could work as stated.  One question 
does come to mind though: do we want a structured format (ala URIs) or do 
we want to treat it like UID and just make it an opaque hashable/indexable 
value??  I lean towards the URI concept so that its simple and clear to 
detect different versions of a TZ def from different products but the 
overall usage is probably going to be more of the opaque type...

> Of course, there should be some signal to indicate that these names are
> special -- perhaps the "//" as above?

Given that we already declared the soldue (aka '/') character the prefix 
character for a 'globally registered' name (that follows it), do we want 
to use a different character to indicate our 'change of design' (ie: "~" 
or some other character)?  Since we are basically inventing a namespace 
mechanism (but not truely registering it anywhere) I just want to avoid 
any possible problems that may occur for those already implenting some 
form of "is it global or local" mechanism in their current engines. 

Hmm, just a crazy thought that popped in my head: do we need to have any 
prefix marker at all??  We may but maybe not.  In 2445 we say that '/' 
prefixes some global (TBD) ID and  all other values are just local ID.  Is 
there a downside to treating "Gnome/Evolution/1/America/Los_Angeles"  as a 
local ID?  I can see a use for a special prefix marker of some kind too, 
depending on how I hold up the spec and twist it around but I can see a 
KISS answer of "just make all of them 'local' and let the CUAs match them 
w/their own table of 'local' IDs..."  Someone nudge me off the fence...

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

A good incentive for a structured URI format.

> If a CUA did get a conflict, it may resort to renaming, but in general
> that would not be required. 

Im not sure that a conflict should really happen if each vendor is 
responsible for versioning their TZ information.  How could, say, 
Evolution put out 2 defintions for the "Gnome/Evolution/1/America/Los_Angeles" TZID that were different?  Wouldn't that violate the intent/use of 
versioning??

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

It resolves some issues but make some others come up (like dealing with 
various CUAs building caches of other CUAs IDs and getting "metadata 
bloat", 'compacting' down obsoleted or redudnant cached definitions, etc). 
 This does help solve some stuff but Ill bet it raises some other issues 
elsewhere.  A good suggestion to mull over though...

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: Sun, 29 Apr 2001 15:51:02 -0700 (PDT)

On Thu, 26 Apr 2001 [email-masked] wrote:

> local ID? 

The reason that I suggested a marker was that when a vendor does not use
the "product-global" TZID, then the receiving CUA may have to resort to
the renaming trick suggested earlier. It seems that the CUA could use a
hint as to wether the sender of the VTIME is guaranteeing that the TZID
will not have to be renamed, and the marker is that hint.

Considering your suggestions that the TZID could be a URI, I am equally
equivocal.

The main advantage of using a URI, I'd suppose, is that the receiver could
fetch the object referenced by the URI through the net or a filesystem. But,
the sender is required to send the VTIMEZONE, and what would the receiver
want to fetch that would not already be in the VTIMEZONE?

And, unless we defined how the URI would be used, both the sender and
receiver would have to agree on what to do with it. This would most likely
result in a proprietary use of the TZID URI. Well, it is already OK for a
vendor to make the TZID a URI and define some proprietary use for it
between the vendor's own CUAs, so adding text to RFC would not really
change anything.

So, here is my proposal: 

------------------------------------------------------------------------------

Additions to 4.8.3.1 Time Zone Identifier

  ;tzidprefix = "/" / "~"
     ; Defined previously. Just listed here for reader convenience. 

[ Add another character to tzidprefix: '~' ( TILDE, US-ASCII 126). ]

This presence of the TILDE character ( US-ASCII 126) as a prefix indicates
that all 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 TILDE 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

-----------------------------------------------------------------------------

Another idea: since there is no global tinezone database, the "/" prefiz
reaaly does not mean anything ueful, and after the addition above, it will
still not really mean anything. Instead of adding a new prefix character,
could we skip it and commandeer the "/"? That is, make the "/" serve the
purpose of "~" in the above proposal?

In that case, remove this text: 

------------------------------------------------------------------------------

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

      Note: This document does not define a naming convention for time
        zone identifier s. Implementers may want to use the naming
        conventions defined in existing time zone specifications such as
        the public-domain Olson database [TZ]. The specification of
        globally unique time zone identifiers is no

------------------------------------------------------------------------------

and replace it with:

------------------------------------------------------------------------------

This presence of the SOLIDUS character ( US-ASCII 47) as a prefix
indicates that all 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

------------------------------------------------------------------------------

I like the second proposal better, since the TZID looks cleaner and it
does not leave the cruft of the previous "/" prefix text laying around.
And I think that it fits with the original idea of a global database,
except that we are allowing for multiple, unregisters databases.

eric.