summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6557.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6557.txt')
-rw-r--r--doc/rfc/rfc6557.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6557.txt b/doc/rfc/rfc6557.txt
new file mode 100644
index 0000000..4fc99e8
--- /dev/null
+++ b/doc/rfc/rfc6557.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Lear
+Request for Comments: 6557 Cisco Systems GmbH
+BCP: 175 P. Eggert
+Category: Best Current Practice UCLA
+ISSN: 2070-1721 February 2012
+
+
+ Procedures for Maintaining the Time Zone Database
+
+Abstract
+
+ Time zone information serves as a basic protocol element in
+ protocols, such as the calendaring suite and DHCP. The Time Zone
+ (TZ) Database specifies the indices used in various protocols, as
+ well as their semantic meanings, for all localities throughout the
+ world. This database has been meticulously maintained and
+ distributed free of charge by a group of volunteers, coordinated by a
+ single volunteer who is now planning to retire. This memo specifies
+ procedures involved with maintenance of the TZ database and
+ associated code, including how to submit proposed updates, how
+ decisions for inclusion of those updates are made, and the selection
+ of a designated expert by and for the time zone community. The
+ intent of this memo is, to the extent possible, to document existing
+ practice and provide a means to ease succession of the database
+ maintainers.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6557.
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 1]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+1. Introduction
+
+ The IETF has specified several standards that make use of time zone
+ information. Time zone names are used in DHCP to configure devices
+ with correct local time [RFC4833]. Time zone names can appear in the
+ TZID field of calendaring VEVENTs [RFC5545]. The normative reference
+ for these values is the TZ Database [TZDB]. From the early 1980s
+ through 2011, that database, which has been in use on nearly all UNIX
+ systems, Java systems, and other sorts of systems, was hosted at the
+ U.S. National Institutes of Health (NIH). The database consists of
+ both historic and current entries for geographies throughout the
+ world. Associated with the database is a reference implementation of
+ ISO/IEC 9899 C [ISO9899C] and IEEE 1003.1 [IEEE1003.1] POSIX time
+ functions that can be used to convert time values.
+
+ The database was previously maintained by volunteers who participated
+ in the <tz@elsie.nci.nih.gov> mailing list that was also hosted at
+ the NIH. The database itself is updated approximately twenty times
+ per year, depending on the year, based on information these experts
+ provide to the maintainer. Arthur David Olson has maintained the
+ database, coordinated the mailing list, and provided a release
+ platform since the database's inception. With his retirement now
+ approaching, it is necessary to provide a means for this good work to
+ continue.
+
+ The time zone community has requested that the IETF adopt the ongoing
+ maintenance of the Time Zone Database. The time zone community would
+ like the IETF to maintain it in a consistent fashion to its
+ administration of the Internet protocol parameters and values.
+
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 2]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ IANA (Internet Assigned Numbers Authority): For purposes of this
+ RFC, IANA is a role, not an organization. The IANA Considerations
+ defined in this RFC will be provided by the Internet Corporation
+ for Assigned Names and Numbers (ICANN) in accordance with the
+ IETF-ICANN "Memorandum of Understanding Concerning Technical Work
+ of the Internet Assigned Numbers Authority", which was signed and
+ ratified in March of 2000[RFC2860].
+
+ TZ Database: The Time Zone Database, sometimes referred to as the
+ "Olson Database". This database consists of information about
+ offsets from UTC for different localities, including daylight
+ saving time (DST) transition information.
+
+ TZ Coordinator: The person or people who maintain and manage release
+ of the TZ Database. The TZ Coordinator also has responsibility
+ for managing the TZ mailing list. The TZ Coordinator is an IANA
+ Designated Expert, as defined in Section 3.2 of [RFC5226], except
+ as regards to appeals, as discussed in Section 5 of this document.
+ Roughly speaking, this means that the IESG will choose one or more
+ experts to manage the TZ database, code, and mailing list. The TZ
+ Coordinator will also lead work to develop appropriate service
+ metrics. There SHALL be a single lead individual and at least one
+ backup individual for this function.
+
+ TZ mailing list: The forum where matters relating to the TZ database
+ and supporting code are discussed.
+
+ The rest of this document specifies the following:
+
+ 1. Transferring and maintenance of the TZ mailing list;
+
+ 2. Procedures for selecting a technical expert who will play the
+ role of TZ Coordinator and release manager for the TZ database;
+
+ 3. Procedures for updating the TZ database;
+
+ 4. Maintenance and ownership of reference code; and
+
+ 5. Ownership of the database.
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 3]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+2. The TZ Mailing List
+
+ For many years, the TZ mailing list has been the forum where
+ discussion of changes to the TZ database and support files would take
+ place. In addition, the TZ mailing list is used to announce releases
+ of the database. Currently, the TZ mailing list is administered by
+ the TZ Coordinator.
+
+ This list membership, formerly at the NIH, has been transitioned to
+ the IANA mail server. Its address, moving forward, is <tz@iana.org>.
+ Subscriptions are processed at
+ <https://mm.icann.org/mailman/listinfo/tz/>. The TZ Coordinator will
+ continue to manage the list. While the TZ Coordinator may establish
+ other rules of governance for the list, members of that list will be
+ informed that a condition of participating on the list is that all
+ contributions to the list are released to the public domain, and that
+ by placing their contribution in the public domain, contributors
+ waive forever any intellectual property claims.
+
+ The list will be used just as it has been: to learn of, discuss, and
+ confirm TZ definition changes, as well as to serve as an announcement
+ list for new versions of the database.
+
+3. Making Updates to the TZ Database
+
+ Updates to the TZ database are made by the TZ Coordinator in
+ consultation with the TZ mailing list. The TZ Coordinator is
+ empowered to decide, as the designated expert, appropriate changes,
+ but SHOULD take into account views expressed on the mailing list.
+
+ The TZ Coordinator will also decide the timing of database releases.
+ Today, the release itself consists of several archive files that are
+ downloaded from a well-known location.
+
+ Moving forward, the TZ database, supporting code, and any appropriate
+ supporting information SHOULD be cryptographically signed prior to
+ release using well known public keys, along with any appropriate
+ supporting information and distributed from
+ <http://www.iana.org/time-zones>.
+
+ The criteria for updates to the database include the following:
+
+ 1. New TZ names (e.g., locations) are only to be created when the
+ scope of the region a name was envisioned to cover is no longer
+ accurate.
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 4]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+ 2. In order to correct historical inaccuracies, a new TZ name MAY be
+ added when it is necessary to indicate what was the consensus
+ view at a given time and location. Such TZ names are usually not
+ added when the inaccuracy was prior to 1970.
+
+ 3. Changes to existing entries SHALL reflect the consensus on the
+ ground in the region covered by that entry.
+
+ To be clear, the TZ Coordinator SHALL NOT set time zone policy for a
+ region but use judgment and whatever available sources exist to
+ assess what the average person on street would think the time
+ actually is, or in case of historical corrections, was.
+
+4. Selecting or Replacing a TZ Coordinator
+
+ From time to time it will be necessary to appoint a new TZ
+ Coordinator. This could occur for a number of reasons:
+
+ o The TZ Coordinator is retiring (as Arthur David Olson is) or has
+ announced that he or she will be unable to continue to perform the
+ function;
+
+ o The TZ Coordinator is missing, has become incapacitated, or has
+ died; or
+
+ o The TZ Coordinator is not performing the function in accordance
+ with community wishes.
+
+ In any of these cases, members of the community should raise the
+ issue on the TZ mailing list and attempt to reach consensus on a new
+ candidate to fulfill the role of TZ Coordinator. If rough consensus
+ cannot be reached easily, the Area Directors of the IETF Applications
+ Area should attempt to guide the members of the community to rough
+ consensus. The candidate that is agreed upon by the community
+ through rough consensus shall be presented to the IESG for
+ confirmation. If rough consensus cannot be reached, even with
+ guidance from the Applications Area Directors, the IESG shall use
+ whatever means it has at its disposal to choose a candidate who in
+ its best judgment will be able to fulfill the role of TZ Coordinator.
+
+5. Appealing Database Decisions
+
+ The TZ Coordinator makes decisions based on expertise, as well as
+ with guidance from the TZ mailing list. If a member of the community
+ has a concern with an individual decision made by the TZ Coordinator
+ with regard to the TZ database, the individual shall proceed as
+ follows:
+
+
+
+
+Lear & Eggert Best Current Practice [Page 5]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+ 1. Attempt to resolve the concern directly with the TZ Coordinator.
+
+ 2. If a resolution cannot be reached directly with the TZ
+ Coordinator, express the concern to the community and attempt to
+ achieve rough consensus regarding a resolution on the TZ mailing
+ list. The Area Directors of the IETF Applications Area may at
+ their discretion attempt to guide the members of the community to
+ rough consensus.
+
+ 3. As a last resort, if a resolution cannot be reached on the TZ
+ mailing list, appeal to the IESG for a resolution. The appellant
+ must show that the decision made by the TZ Coordinator (a) was
+ materially in error and (b) has caused material harm. In its
+ deliberations regarding an appeal, the IESG shall weigh all the
+ evidence presented to it and use its best judgment in determining
+ a resolution.
+
+6. Maintenance and Distribution of Reference Code
+
+ Currently, the maintainer of the TZ database also maintains reference
+ code, most of which is public domain. The reference implementation
+ shall be distributed along with an associated cryptographic signature
+ verifiable by a public key. Several files from this software are
+ currently distributed under license. Where they exist, licenses
+ SHALL NOT be changed.
+
+7. Database Ownership
+
+ The TZ database itself is not an IETF Contribution or an IETF
+ document. Rather it is a pre-existing and regularly updated work
+ that is in the public domain, and is intended to remain in the public
+ domain. Therefore, BCPs 78 [RFC5378] and 79 [RFC3979] do not apply
+ to the TZ Database or contributions that individuals make to it.
+ Should any claims be made and substantiated against the TZ Database,
+ the organization that is providing the IANA Considerations defined in
+ this RFC, under the memorandum of understanding with the IETF,
+ currently ICANN, may act in accordance with all competent court
+ orders. No ownership claims will be made by ICANN or the IETF Trust
+ on the database or the code. Any person making a contribution to the
+ database or code waives all rights to future claims in that
+ contribution or in the TZ Database.
+
+8. IANA Considerations
+
+ This section documents the following IANA actions:
+
+ o Assistance on request of the IESG in selection of the TZ
+ Coordinator, based on the procedures set forth above.
+
+
+
+Lear & Eggert Best Current Practice [Page 6]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+ o Maintenance of a repository for the TZ database and associated
+ reference code. The TZ Coordinator SHALL be named by the IESG as
+ described above, and will act as the maintainer of the database
+ and code, as described above.
+
+ o Creation of appropriate access for the TZ Coordinator to maintain
+ the database, as well as necessary tooling that may be required,
+ so long as no direct software costs are incurred.
+
+ o Establishment of security of the system upon which the database
+ resides. Both current and historical versions of the database
+ will be stored and distributed via HTTP/HTTPS.
+
+ o Maintenance of a cryptographic private key that is used to sign
+ the database and that will survive a change of TZ Coordinator.
+
+9. Security Considerations
+
+ The distribution of the database is currently not secured. This memo
+ states that the TZ database SHOULD be distributed with a valid
+ cryptographic signature moving forward.
+
+10. Acknowledgments
+
+ The authors would like to thank the TZ mailing list for their
+ remarkable achievements over the many years. Thanks also to Marshall
+ Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony
+ Finch, Elwyn Davies, Alfred Hoenes, Ted Hardie, Barry Leiba, Russ
+ Housley, Pete Resnick, and Elise Gerich for the improvements they
+ made to this document. A special acknowledgment should be given to
+ Arthur David Olson for his excellent stewardship, to Rob Elz for
+ continuing that stewardship, and to the team at ICANN for their good
+ efforts, moving forward.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+ Understanding Concerning the Technical Work of the
+ Internet Assigned Numbers Authority", RFC 2860,
+ June 2000.
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 7]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and
+ Daylight Saving Time Data", 1987,
+ <ftp://ftp.iana.org/tz/code/tz-link.htm>.
+
+11.2. Informational References
+
+ [IEEE1003.1] Institute of Electrical and Electronics Engineers,
+ "Standard for Information Technology - Portable
+ Operating System Interface (POSIX) - Base Definitions",
+ IEEE Standard 1003.1-2008, December 2008.
+
+ [ISO9899C] International Standards Organization, "Information
+ technology -- Programming languages -- C", ISO/
+ IEC Standard 9899:2011, December 2011.
+
+ [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
+ Technology", BCP 79, RFC 3979, March 2005.
+
+ [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP",
+ RFC 4833, April 2007.
+
+ [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors
+ Provide to the IETF Trust", BCP 78, RFC 5378,
+ November 2008.
+
+ [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
+ Core Object Specification (iCalendar)", RFC 5545,
+ September 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 8]
+
+RFC 6557 Maintaining the Time Zone Database February 2012
+
+
+Authors' Addresses
+
+ Eliot Lear
+ Cisco Systems GmbH
+ Richtistrasse 7
+ CH-8304 Wallisellen
+ Switzerland
+
+ Phone: +41 1 878 9200
+ EMail: lear@cisco.com
+
+
+ Paul Eggert
+ UCLA
+ Computer Science Department
+ 4532J Boelter Hall
+ Los Angeles, CA 90095
+ USA
+
+ Phone: +1 310 267 2254
+ EMail: eggert@cs.ucla.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Eggert Best Current Practice [Page 9]
+