From: http://www.ietf.org/internet-drafts/draft-royer-calsch-xmltz-00.txt (ephemeral URL) Title: Time Zones in XML Reference: IETF Calendaring and Scheduling Working Group, Internet Draft 'draft-royer-calsch-xmltz-00' Date: September 10, 2004 ======================================================================== Calendaring and Scheduling D. Royer Internet-Draft IntelliCal, LLC Expires: March 11, 2005 Sep 10, 2004 Time Zones in XML draft-royer-calsch-xmltz-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 11, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The iCalendar data format is being updated and included in those discussions is the desire to update the time zone information. This is a proposal for time zone updates to iCalendar. The time zone information will be available in XML format. To comment on this document send email to ietf-calendar@imc.org . This document also specifies an IANA registration process for time zones. No attempt is made to specify any specific time zones as that is political information that is out of scope for this document. Royer Expires March 11, 2005 [Page 1] Internet-Draft Time Zones in XML Sep 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . . . . 3 1.2 Related Documents . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Time Zone XML Object . . . . . . . . . . . . . . . . . . . . . 5 3. Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 timezones element . . . . . . . . . . . . . . . . . . . . . . 7 3.2 tzid element . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 dname element . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 tzurl element . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 change element . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 geoinclude element . . . . . . . . . . . . . . . . . . . . . . 7 3.7 geoexclude element . . . . . . . . . . . . . . . . . . . . . . 7 3.8 notes element . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA registration of time zones . . . . . . . . . . . . . . . 9 5. Time Zone Server . . . . . . . . . . . . . . . . . . . . . . . 10 6. Time Zone DTD . . . . . . . . . . . . . . . . . . . . . . . . 11 7. TZURL URL . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1 Fetch by TZID . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2 Fetch by Geographical Position . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 A. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Royer Expires March 11, 2005 [Page 2] Internet-Draft Time Zones in XML Sep 2004 1. Introduction Applications that do calendaring across time zones need to share the time zone information in order for the applications to correctly calculate the time of appointments in the users time zone. Included in this document is a transport independent format for time zones. It is anticipated that the objects described here can be stored on local hard drives, fetched and updated across the network, and registered by the IANA registration authority. Included in a time zone definition is a world unique name which always MUST include the revisions of the object. This will allow applications to determine if their copy of a time zone is newer, older, or the same as the sender used simply by examining the name used. For example: Could be the time zone name (US_Pacific) and revision (16) used by the original application. If the using application does not have the US_Pacific time zone, or if the using application does not have revision 16 of the time zone definition, then the application can query a time zone server and retrieve the information. 1.1 Formatting Conventions 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 [RFCWORDS]. 1.2 Related Documents Implementers will need to be familiar with several other memos that, along with this one, describe the Internet calendaring and scheduling standards. These documents are: [iCAL] - (RFC2445) Which specifies the objects, data types, properties and property parameters used in the protocols, along with the methods for representing and encoding them. [iTIP] - (RFC2446) Which specifies an interoperability protocol for scheduling between different installations. Royer Expires March 11, 2005 [Page 3] Internet-Draft Time Zones in XML Sep 2004 [iMIP] - (RFC2447) Which specifies the Internet email binding for [iTIP]. [GUIDE] - (RFC3283), a guide to implementers and describes the elements of a calendaring system, how they interact with each other, how they interact with end users, and how the standards and protocols are used. This memo does not attempt to repeat the specification of concepts and definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts and definitions. The time zone information is being updated in this document. 1.3 Definitions TIME ZONE - Time zones are defined by geographic boundaries that are specified by political entities. All time zone names in this document are to be considered as example names only. Geographic Position - The longitude and latitude of a point on earth. Royer Expires March 11, 2005 [Page 4] Internet-Draft Time Zones in XML Sep 2004 2. Time Zone XML Object Each object contains the time zone name, revisions supported, and time zone definition. The object is modeled after the iCalendar "VTIMEZONE" component. Here is an example of a time zone with only one revision: US/Pacific http://tz-server.example.com/US/Pacific/1 . . . The "tzid" element describes a time zone. The "name" attribute is a unique IANA registered name for the time zone. The "rev" attribute is a numeric sequence number starting date and time where this revision is first valid. from one (1) with the first revision of the object published. Each change results in an additional "tzid" element added. No alterations are allowed to published revisions. Once published the time zone definition may not be updated. If there are errors then Royer Expires March 11, 2005 [Page 5] Internet-Draft Time Zones in XML Sep 2004 there MUST BE a new "tzid" element added and the revision incremented. The "date" attribute is a timestamp that contains the registration The "tzurl" element is optional and points to a location where this object can be downloaded. Any valid URL type is allowed. There can be one "tzurl" element per unique revision. The "change" element contains the UTC time for each time zone change. There is one "change" element for each unique time zone change. The list must be sorted by UTC time with the oldest time listed first. The "at" attribute is the UTC time for a specified change. The "tzname" attribute is an abbreviated name that may be used for that time range. The "offset" is the number of seconds from UTC, with negative numbers being West and positive numbers being East of UTC. Royer Expires March 11, 2005 [Page 6] Internet-Draft Time Zones in XML Sep 2004 3. Elements 3.1 timezones element The "timezones" element is the outermost wrapper for all objects described in this document. It may contain one or more "tzid" elements". 3.2 tzid element Each "tzid" element describes exactly one time zone and must include a "rev" attribute. Within each "timezones" element, the "tzid" element and "rev" pair must be unique. The "date" attribute is optional and describes the registration date for the revision. 3.3 dname element The "dname" element provides the human readable name for the time zone. There may be zero or more "dname" elements within each "tzid". There MUST NOT be two or more "dname" elements within a "tzid" that contain the same "lang" attribute. The mandatory "lang" attribute is the language for which the "dname" applies and its value is an IANA registered language name. 3.4 tzurl element The "tzurl" element value must be a valid URL that points to the same revision object if fetched. It MUST point to a "timezones" element that contains exactly one "tzid" element of the same matching revision". 3.5 change element Each time change must have exactly one "change" element entry in the "tzid" element. The "change" elements MUST BE sorted by UTC date and time, ascending. 3.6 geoinclude element Contains a comma separated latitude/latitude points that outline a polygon of the time zone. All area in the polygon is considered in the time zone minus any polygon listed in any "geoexclude" elements. 3.7 geoexclude element Contains a comma separated latitude/latitude points that outline a polygon to be excluded from the time zone. At least one point must be inside a "geoinclude" element polygon. The purpose of this element is Royer Expires March 11, 2005 [Page 7] Internet-Draft Time Zones in XML Sep 2004 to allow for holes inside of "geoinclude" polygons. 3.8 notes element The "notes" element may contain any plain text notes associated with the "tzid" or "timezones" element. Royer Expires March 11, 2005 [Page 8] Internet-Draft Time Zones in XML Sep 2004 4. IANA registration of time zones To be done... Royer Expires March 11, 2005 [Page 9] Internet-Draft Time Zones in XML Sep 2004 5. Time Zone Server To be done... Royer Expires March 11, 2005 [Page 10] Internet-Draft Time Zones in XML Sep 2004 6. Time Zone DTD To be done... Royer Expires March 11, 2005 [Page 11] Internet-Draft Time Zones in XML Sep 2004 7. TZURL URL This URL is used to fetch and specify the type of information to be collect time zone information from a time zone server More to be done... 7.1 Fetch by TZID Given a TZID this describes how to get the entire time zone definition or the latest revision for a time zone. More to be done... 7.2 Fetch by Geographical Position Given a latitude and longitude this describes how to get the entire time zone definition or the latest revision for the location. More to be done... Note: Geographical position information is optional so not all time zones may be retrievable using this method. Author's Address Doug Royer IntelliCal, LLC 267 Kentlands Blvd. #3041 Gaithersburg, MD 20878 US Phone: +1-866-594-8574 Fax: +1-866-594-8574 EMail: Doug@IntelliCal.com URI: http://Royer.com/People/Doug Royer Expires March 11, 2005 [Page 12] Internet-Draft Time Zones in XML Sep 2004 Appendix A. Bibliography [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet Calendaring", RFC 3283, June 2002, ftp://ftp.isi.edu/in-notes/rfc3283.txt [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., "iCalendar Transport-Independent Interoperability Protocol (iTIP) Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt [MIME] Borenstein, N. and Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996 ftp://ftp.isi.edu/in-notes/rfc2045.txt [RFCWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997 ftp://ftp.isi.edu/in-notes/rfc2119.txt [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997 ftp://ftp.isi.edu/in-notes/rfc2222.txt [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., "Guidelines for new URL Schemes", RFC 2718, November 1999, ftp://ftp.isi.edu/in-notes/rfc2718.txt [URI] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998 ftp://ftp.isi.edu/in-notes/rfc2396.txt [URL] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform Resource Locators (URL)", RFC 1738, December 1994 ftp://ftp.isi.edu/in-notes/rfc1738.txt Royer Expires March 11, 2005 [Page 13] Internet-Draft Time Zones in XML Sep 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Royer Expires March 11, 2005 [Page 14] Internet-Draft Time Zones in XML Sep 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Royer Expires March 11, 2005 [Page 15]