[VCARDDAV] Coding for timezone values using tzid (was I-D Action:draft-ietf-vcarddav-vcardrev-07.txt)

[Sly Gryphon <sgryphon at computer.org>]

I would like to strongly suggest that the TZ property be defined to use 
values from the tz database, i.e.

[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight 
Saving Time Data", <http://www.twinsun.com/tz/tz-link.htm>, updated 
periodically.

This was discussed at IETF 74, and the main objection seemed to be worry 
that the tz database may disappear. There was also discussion of 
creating an IANA registry and a draft is available.

The tz database is already the de-facto standard, it is in the 
public-domain and the information is widely replicated; the notion that 
it could actually “disappear” is absurd. The concern is probably really 
over other things that could happen, including:
- The tz database may no longer be published at twinsun.com / nih.gov.
- The tz database could stop being updated (or be insufficiently updated).
- Multiple derived implementations (forks) could arise.
- Endpoints could be using different versions of the database.

If situations 1 or 2 occur, the database doesn’t disappear, it just 
stops being updated (it will still exist in the public domain and be 
widely available on the Internet, in many unix implementations, etc). 
Because it is so widely used, it is almost certain that if this ever did 
occur that at least one derivative would arise. At that point would also 
be an appropriate time for whoever takes it over to create it as an IANA 
registry (or under some other standards body).

What could happen if it stops being updated (which I think is unlikely; 
the tz database has already existed longer than vCard I think) is that 
in the meanwhile individual implementations could start to diverge, and 
there is even the possibility that multiple forks arise (multiple 
standards bodies take it over). This situation however is not really 
different than the normal situation where implementations simply use 
different versions of the database, it has been individually modified, 
or is only partially supported (e.g. a mobile device may only recognize 
a limited subset).

These problems are not really solved by moving it into a IANA registry – 
implementations could still use different versions of the registry. In 
fact creating an IANA registry whilst the main tz database is still 
healthy and strong, whilst well intentioned, could actually be 
counter-productive – a lot of effort keeping things in sync to achieve 
no real benefit over simply using tz database directly … and if they 
aren’t in sync you *cause* problem 3.

So, the focus should be on solving the real problem of handling 
unrecognised values, e.g. if using different versions of the database. 
The first thought may be to add a “version” attribute, but this is only 
of limited use.

e.g. If you used version 2009h, but I have updated to version 2009i (or 
the other way around), what can really be done about it? Even if I did 
have the historic version available, the newer one could very well have 
corrections in it (which I should probably be using anyway).

This also doesn’t solve the problem of what happens if you say version 
2009h, and I have something called 2009h, but the value you specify 
still doesn’t exist in my copy.

So, really what it boils down to is how to handle unrecognized values.

The first point is we should specify to use the tz database for 
specifying timezones so that in most cases both sides have the best 
chance to understand what is meant. For this purpose the tz database is 
stable enough for future use, even if it never ever gets updated ever 
again, the historic 2009i version (i.e. current version) is going to be 
easily sufficient for the majority of cases. The current database has 
several hundred values that could be used, each well enough defined for 
both sides to usually understand what is meant. (The actual rules will 
surely change in the next 10 years, but the vCard standard isn’t 
concerned so much with the rules but with consistent identifiers.)

To handle unrecognized values (say a mobile device with only a limited 
number of timezones), one option is to handle all unrecognized values in 
some default manner, e.g. the same way you would handle if the property 
is missing altogether.

Another way would be to make the field structured text and allow both a 
TZID and, for fallback purposes, an offset as at the time specified in REV.
e.g.
TZ:Australia/Sydney;+10:00
REV:20090612T102345Z

If you do allow offset, then it needs to be defined "as at a particular 
time", e.g. defined as at the REV time of the vCard. (This means you 
don't need to change the card when DST changes unless you also change 
the REV time; alternatively if you do update the offset you would need 
to change the REV time as well).

Note that the tz database is already used in other standards, so if you 
aren't happy with referencing it directly, you could, for example, 
reference the subset in Unicode Technical Standard #35 (UTS35) - Local 
Data Markup Language (LDML). Note that Unicode/LDML recognised the issue 
of wanting stable identifiers when the tz database may change, so they 
define a paricular limited subset and alias/mapping to those canonical 
values. (This, of course, involves additional processing and so may not 
be desireable). UTS35 LDML also includes a mapping from Microsoft 
Windows timezone names to the canonical TZIDs.

[UTS35] Davis, M., "Unicode Locale Data Markup Language (LDML)", Unicode 
Technical Standard #35, version 1.7, May 2007.

Another possibility is that the tz database is already referenced in RFC 
4833 (DHCPv4), and a data type for the field (in DHCP) is registered 
with IANA (just the field definition, not the values itself). This means 
that vCard could simply refer to the field as "a value as defined for 
the DHCPv4 IPv4 option code 100", or "a value defined for the DHCPv4 
IPv6 option OPTION_NEW_TZDB_TIMEZONE(42)".

[RFC4833] Lear, E., and P. Eggert, "Timezone Options for DHCP", RFC 
4833, April 2007.

I think it is simplest to just directly refer to the tz database as the 
de-facto standard for this value (unless someone disagrees that it is a 
de-facto standard). Having the first value in the field being “a value 
from the tz database” (effectively the same as DHCPv4 RFC 4833 refers to 
it) has no practical difference from it being a value from an IANA 
registry “which we promise to keep up to date with the TZ database”.

Implementers will still go to the TZ database for their implementation 
of actual rules, and still have exactly the same problems of 
unrecognized values or different versions of the database. In fact, 
putting the IANA registry into the mix could increase problems (increase 
potential mismatch).

If you still want to publish something via the IETF, then maybe a Best 
Current Practice note or an Informational note (referring to using the 
TZ database) might be more appropriate than creating an IANA registry 
via RFC – support for it being a BCP could be that it is widely deployed 
in existing (unix) systems as the way to refer to timezones, and in fact 
already referenced by RFCs and other standards such as Unicode.

In this case, vCard should probably still refer to the tz database as 
the primary normative reference, and make any draft BCP purely 
informational (to avoid depending on it).

Sly Gryphon