Serialising Extended Data About Times and Events U. Sharma Internet-Draft Igalia, S.L. Intended status: Standards Track C. Bormann Expires: 23 April 2022 Universität Bremen TZI 20 October 2021 Date and Time on the Internet: Timestamps with additional information draft-ietf-sedate-datetime-extended-01 Abstract This document defines an extension to the timestamp format defined in RFC3339 for representing additional information including a time zone. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 23 April 2022. Copyright Notice Copyright (c) 2021 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 (https://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. Sharma & Bormann Expires 23 April 2022 [Page 1] Internet-Draft Timestamps Extended October 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extended Date/Time format . . . . . . . . . . . . . . . . . . 4 3.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Namespaced . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Multi-character Namespaces . . . . . . . . . . . . . . . 5 3.4. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . 7 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Dates and times are used in a very diverse set of internet applications, all the way from server-side logging to calendaring and scheduling. Each distinct instant in time can be represented in a descriptive text format using a timestamp, and [ISO8601] standardizes a widely- adopted timestamp format, which forms the basis of [RFC3339]. However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account things like DST transitions. Most of these applications attach the timezone to the timestamp in a non-standard format, at least one of which is fairly well-adopted [JAVAZDT]. Furthermore, applications might want to attach even more information to the timestamp, including but not limited to the calendar system it needs to be represented in. This document defines an extension syntax for timestamps as specified in [RFC3339] that has the following properties: * The extension suffix is completely optional, making existing [RFC3339] timestamps compatible with this format. Sharma & Bormann Expires 23 April 2022 [Page 2] Internet-Draft Timestamps Extended October 2021 * The format is compatible with the pre-existing popular syntax for attaching time zone names to timestamps ([JAVAZDT]). * The format provides a generalized way to attach any additional information to the timestamp. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. UTC: Coordinated Universal Time, as maintained since 1988 by the Bureau International des Poids et Mesures (BIPM) in conjunction with leap seconds as announced by the International Earth Rotation and Reference Frames Service [IERS]. From 1972 through 1987 UTC was maintained entirely by Bureau International de l'Heure (BIH). Before 1972 UTC was not generally recognized and civil time was determined by individual jurisdictions using different techniques for attempting to follow Universal Time based on measuring the rotation of the earth. UTC is often mistakenly referred to as GMT, an earlier time scale UTC was designed to be a useful successor for. ABNF: Augmented Backus-Naur Form, a format used to represent permissible strings in a protocol or language, as defined in [RFC5234]. The rules defined in Appendix B of [RFC5234] are imported implictly. Internet Date/Time Format: The date/time format defined in section 3 of this document. Timestamp: This term is used in this document to refer to an unambiguous representation of some instant in time. Z: A suffix which, when applied to a time, denotes a UTC offset of 00:00; often spoken "Zulu" from the ICAO phonetic alphabet representation of the letter "Z". Time Zone: A time zone that is a included in the Time Zone Database (often called tz or zoneinfo) maintained by IANA. CLDR: Common locale data repository [CLDR], a project of the Unicode Consortium to provide locale data to applications. Sharma & Bormann Expires 23 April 2022 [Page 3] Internet-Draft Timestamps Extended October 2021 For more information about time scales, see Appendix E of [RFC1305], Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF.460-6]. 3. Extended Date/Time format This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends [RFC3339] for use in Internet protocols. 3.1. Informative The format should allow implementations to specify additional important information in addition to the bare timestamp. This is done by defining _tags_, each with a _key_ and a _value_ separated by an equals sign, and allowing implementations to include an informative _suffix_ at the end with as many tags as required. The value of a tag can be a hyphen delimited list of multiple values. In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. 3.2. Namespaced Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards. For this, all information needs to be namespaced. Each key is therefore divided into two hyphen-separated sections: the namespace and the key. For example, the calendar as defined by the Unicode consortium could be included as u-ca=. All single-character namespaces are reserved for [BCP47] extensions recorded in the BCP47 extensions registry. For these namespaces: * Case differences are ignored. * The namespace is restricted to single alphanum, corresponding to extension singletons ('x' can be used for a private use extension). * In addition, for CLDR extensions: - There must be a namespace-key and it is restricted to 2 alphanum characters. - A suffix-value is limited to 3*8alphanum. Sharma & Bormann Expires 23 April 2022 [Page 4] Internet-Draft Timestamps Extended October 2021 3.3. Multi-character Namespaces Multi-character namespaces can be registered specifically for use in this format, see Section 4. The registration policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the tags using the namespace registered. (This subsection uses BCP 14 language to describe the requirements on the information interchanged indirectly by providing requirements on the RFC registering a namespace and the principles of its evolution.) The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC. The RFC MUST specify each of the following (directly or included by reference): * The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this section of this document. * The specification and all keys defined by the specification MUST follow the ABNF and other rules for the formation of keys as defined in this document. In particular, it MUST specify that case is not significant and that keys MUST NOT exceed eight characters in length. * The specification MUST specify a canonical representation. * The specification of valid keys MUST be available over the Internet and at no cost. * The specification MUST be in the public domain or available via a royalty-free license acceptable to the IETF and specified in the RFC. * The specification MUST be versioned, and each version of the specification MUST be numbered, dated, and stable. * The specification MUST be stable. That is, namespace keys, once defined by a specification, MUST NOT be retracted or change in meaning in any substantial way. * The specification MUST include, in a separate section, the registration form reproduced in this section (below) to be used in registering the namespace upon publication as an RFC. Sharma & Bormann Expires 23 April 2022 [Page 5] Internet-Draft Timestamps Extended October 2021 * IANA MUST be informed of changes to the contact information and URL for the specification. IANA will maintain a registry of allocated multi-character namespaces. This registry MUST use the record-jar format described by the ABNF in [BCP47]. Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this registration form to , who MUST forward the request to . The maintaining authority of the namespace MUST maintain the accuracy of the record by sending an updated full copy of the record to with the subject line "TIMESTAMP FORMAT NAMESPACE UPDATE" whenever content changes. Only the 'Comments', 'Contact_Email', 'Mailing_List', and 'URL' fields MAY be modified in these updates. Failure to maintain this record, maintain the corresponding registry, or meet other conditions imposed by this section of this document MAY be appealed to the IESG [RFC2028] under the same rules as other IETF decisions (see [RFC2026]) and MAY result in the authority to maintain the extension being withdrawn or reassigned by the IESG. %% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %% Figure 1: Registration record for a multi-character namespace 'Identifier' contains the multi-character sequence assigned to the namespace. The Internet-Draft submitted to define the namespace SHOULD specify which sequence to use, although the IESG MAY change the assignment when approving the RFC. 'Description' contains the name and description of the namespace. 'Comments' is an OPTIONAL field and MAY contain a broader description of the namespace. 'Added' contains the date the namespace's RFC was published in the "date-full" format specified in Figure 2. For example: 2004-06-28 represents June 28, 2004, in the Gregorian calendar. Sharma & Bormann Expires 23 April 2022 [Page 6] Internet-Draft Timestamps Extended October 2021 'RFC' contains the RFC number assigned to the namespace. 'Authority' contains the name of the maintaining authority for the namespace. 'Contact_Email' contains the email address used to contact the maintaining authority. 'Mailing_List' contains the URL or subscription email address of the mailing list used by the maintaining authority. 'URL' contains the URL of the registry for this namespace. The determination of whether an Internet-Draft meets the above conditions and the decision to grant or withhold such authority rests solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. 3.4. Syntax Extensions to RFC 3339 The following rules extend the ABNF syntax defined in [RFC3339] in order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule date-time-ext. time-zone-initial = ALPHA / "." / "_" time-zone-char = time-zone-initial / DIGIT / "-" / "+" time-zone-part = time-zone-initial *13(time-zone-char) ; but not "." or ".." time-zone-name = time-zone-part *("/" time-zone-part) time-zone = "[" time-zone-name "]" namespace = 1*alphanum namespace-key = 1*alphanum suffix-key = namespace ["-" namespace-key] suffix-value = 1*alphanum suffix-values = suffix-value *("-" suffix-value) suffix-tag = "[" suffix-key "=" suffix-values "]" suffix = [time-zone] *suffix-tag date-time-ext = date-time suffix alphanum = ALPHA / DIGIT Figure 2: ABNF grammar of extensions to RFC 3339 Sharma & Bormann Expires 23 April 2022 [Page 7] Internet-Draft Timestamps Extended October 2021 3.5. Examples Here are some examples of Internet extended date/time format. 1996-12-19T16:39:57-08:00 Figure 3: RFC 3339 date-time with timezone offset Figure 3 represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC. Note that this is the same instant in time as 1996-12-20T00:39:57Z, expressed in UTC. 1996-12-19T16:39:57-08:00[America/Los_Angeles] Figure 4: Adding a timezone name Figure 4 represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew] Figure 5: Projecting to the Hebrew calendar Figure 5 represents the exact same instant but it informs calendar- aware implementations that they should project it to the Hebrew calendar. 1996-12-19T16:39:57-08:00[x-foo=bar][x-baz=bat] Figure 6: Adding tags in private use namespaces Figure 6, based on Figure 3, utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. 4. IANA Considerations Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by [RFC8126]; the IETF review process needs to be based on the requirements laid out in Section 3.3. Sharma & Bormann Expires 23 April 2022 [Page 8] Internet-Draft Timestamps Extended October 2021 5. Security Considerations TBD 6. References 6.1. Normative References [BCP47] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006. Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, DOI 10.17487/RFC2028, October 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Sharma & Bormann Expires 23 April 2022 [Page 9] Internet-Draft Timestamps Extended October 2021 6.2. Informative References [CLDR] "Unicode CLDR Project", . [IERS] "International Earth Rotation Service Bulletins", . [ISO8601] International Organization for Standardization, "Data elements and interchange formats — Information interchange — Representation of dates and times", ISO 8601:1988, June 1988, . [ITU-R-TF.460-6] "ITU-R TF.460-6. Standard-frequency and time-signal emissions", February 2002, . [JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter: ISO_ZONED_DATE_TIME", . [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, DOI 10.17487/RFC1305, March 1992, . Appendix A. Acknowledgements TBD Authors' Addresses Ujjwal Sharma Igalia, S.L. Bugallal Marchesi, 22, 1º 15008 A Coruña Spain Email: ryzokuken@igalia.com Sharma & Bormann Expires 23 April 2022 [Page 10] Internet-Draft Timestamps Extended October 2021 Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Sharma & Bormann Expires 23 April 2022 [Page 11]