[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