Date and Time on the Internet: Timestamps with additional information
draft-ryzokuken-datetime-extended-02

Document Type Active Internet-Draft (individual)
Author Ujjwal Sharma 
Last updated 2021-06-18
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Additional Resources
- GitHub Username: ryzokuken
- GitHub Repository
- Additional Web Page
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Calendaring Extensions Working Group                           U. Sharma
Internet-Draft                                              Igalia, S.L.
Intended status: Standards Track                            18 June 2021
Expires: 20 December 2021

 Date and Time on the Internet: Timestamps with additional information
                  draft-ryzokuken-datetime-extended-02

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 20 December 2021.

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                  Expires 20 December 2021                [Page 1]
Internet-Draft             Timestamps Extended                 June 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extended Date and Time format . . . . . . . . . . . . . . . .   3
     3.1.  Informative . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Namespaced  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Syntax Extensions to RFC3339  . . . . . . . . . . . . . .   7
     3.4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   5.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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 doesn't allow timestamps to contain any
   additional relevant information, which means 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, atleast 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 must 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.

   *  The format is compatible to the pre-existing popular syntax for
      attaching time zone names to timestamps ([JAVAZDT]).

   *  The format provides generalized way to attach any additional
      information to the timestamp.

Sharma                  Expires 20 December 2021                [Page 2]
Internet-Draft             Timestamps Extended                 June 2021

2.  Definitions

   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 [RFC2119].

   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.

   ABNF  Augmented Backus-Naur Form, a format used to represent
      permissible strings in a protocol or language, as defined in
      [RFC2234].

   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.

   For more information about time scales, see Appendix E of [RFC1305],
   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].

3.  Extended Date and 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.

Sharma                  Expires 20 December 2021                [Page 3]
Internet-Draft             Timestamps Extended                 June 2021

3.1.  Informative

   The format should allow implementations to specify additional
   important information in addition to the bare timestamp.  This is
   done by allowing implementations to include an informative suffix at
   the end with as many tags as required, each with a key and value
   separated by an equals sign.  The value 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 the suffix 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=<value>".

   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".

   Multi-character namespaces can be registered specifically for use in
   this format.  They are assigned by IANA using the "IETF Review"
   policy defined by [RFC5226].  This policy requires the development of
   an RFC, which SHALL define the name, purpose, processes, and
   procedures for maintaining the subtags.  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 or include each of the following:

Sharma                  Expires 20 December 2021                [Page 4]
Internet-Draft             Timestamps Extended                 June 2021

   *  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.

   *  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 [RFC5646].  Upon publication of a namespace as an RFC,
   the maintaining authority defined in the RFC MUST forward this
   registration form to <mailto:iesg@ietf.org>, who MUST forward the
   request to <mailto:iana@iana.org>.  The maintaining authority of the
   namespace MUST maintain the accuracy of the record by sending an
   updated full copy of the record to <mailto:iana@iana.org> 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.

Sharma                  Expires 20 December 2021                [Page 5]
Internet-Draft             Timestamps Extended                 June 2021

   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:
   %%

   '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 Section 3.3.  For example: 2004-06-28
   represents June 28, 2004, in the Gregorian calendar.

   '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.

Sharma                  Expires 20 December 2021                [Page 6]
Internet-Draft             Timestamps Extended                 June 2021

   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.3.  Syntax Extensions to [RFC3339]

   The following rules extend the ABNF syntax defined in [RFC3339] in
   order to allow the inclusion of an optional suffix.

   time-zone-char = ALPHA / "." / "_"
   time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; 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

3.4.  Examples

   Here are some examples of Internet extended date/time format.

   1996-12-19T16:39:57-08:00

   This 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 equivalent to 1996-12-20T00:39:57Z in UTC.

   1996-12-19T16:39:57-08:00[America/Los_Angeles]

   This 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]

   This represents the exact same instant but it informs calendar-aware
   implementations that they should project it to the Hebrew calendar.

Sharma                  Expires 20 December 2021                [Page 7]
Internet-Draft             Timestamps Extended                 June 2021

   1996-12-19T16:39:57-08:00[x-foo=bar][x-baz=bat]

   This timestamp 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.  Normative References

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, IETF RFC 2234,
              DOI 10.17487/RFC2234, November 1997,
              <https://www.rfc-editor.org/info/rfc2234>.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation and Analysis", RFC 1305,
              IETF RFC 1305, DOI 10.17487/RFC1305, March 1992,
              <https://www.rfc-editor.org/info/rfc1305>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, IETF RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", RFC 5646, IETF RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC2026]  Bradner, S., "The Internet Standards Process — Revision
              3", RFC 2026, IETF RFC 2026, DOI 10.17487/RFC2026, October
              1996, <https://www.rfc-editor.org/info/rfc2026>.

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", RFC 2028, IETF RFC 2028,
              DOI 10.17487/RFC2028, October 1996,
              <https://www.rfc-editor.org/info/rfc2028>.

5.  Informative References

   [ISO8601]  International Organization for Standardization, "Data
              elements and interchange formats", ISO 8601:1988, June
              1988, <https://www.iso.org/standard/15903.html>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, IETF RFC 3339,
              DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [ITU-R-TF] "", ITU-R TF.460-6.

Sharma                  Expires 20 December 2021                [Page 8]
Internet-Draft             Timestamps Extended                 June 2021

   [IERS]     "International Earth Rotation Service Bulletins",
              <https://www.iers.org/IERS/EN/Publications/Bulletins/
              bulletins.html>.

   [JAVAZDT]  "Java SE 8, java.time.format, DateTimeFormatter:
              ISO_ZONED_DATE_TIME",
              <https://docs.oracle.com/javase/8/docs/api/java/time/
              format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.

Author's Address

   Ujjwal Sharma
   Igalia, S.L.
   Bugallal Marchesi, 22, 1º
   A Coruña
   Spain

   Email: ryzokuken@igalia.com

Sharma                  Expires 20 December 2021                [Page 9]