Date and Time on the Internet: Timestamps with additional information
draft-ietf-sedate-datetime-extended-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (sedate WG) | |
|---|---|---|---|
| Authors | Ujjwal Sharma , Carsten Bormann | ||
| Last updated | 2021-12-03 | ||
| Replaces | draft-ryzokuken-datetime-extended | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sedate-datetime-extended-02
Serialising Extended Data About Times and Events U. Sharma
Internet-Draft Igalia, S.L.
Intended status: Standards Track C. Bormann
Expires: 6 June 2022 Universität Bremen TZI
3 December 2021
Date and Time on the Internet: Timestamps with additional information
draft-ietf-sedate-datetime-extended-02
Abstract
This document defines an extension to the timestamp format defined in
RFC3339 for representing additional information including a time
zone.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-
extended/.
Discussion of this document takes place on the Serialising Extended
Data About Times and Events (SEDATE) Working Group mailing list
(mailto:sedate@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/sedate/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-
extended.
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."
Sharma & Bormann Expires 6 June 2022 [Page 1]
Internet-Draft Timestamps Extended December 2021
This Internet-Draft will expire on 6 June 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Extended Date/Time format . . . . . . . . . . . . . . . . . . 5
2.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Namespaced . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Registered . . . . . . . . . . . . . . . . . . . . . . . 6
3. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . . . 7
3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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.
Sharma & Bormann Expires 6 June 2022 [Page 2]
Internet-Draft Timestamps Extended December 2021
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.
1.1. Scope
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 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.
This document does not address extensions to the format where the
semantic result no longer is a fixed timestamp that is referenced to
a (past or future) UTC time. For instance, it does not address:
* Future time given as a local time in some specified time zone,
where changes to the definition of that time zone (e.g., a
political decision to enact or rescind daylight savings time)
changes the actual time in UTC time.
* Time given as a "floating time", i.e., a local time without
information as to which time zone this local time refers to.
* The use of time scales different from UTC, such as TAI.
However, the additional information provided that augments a fixed
timestamp may be sufficient to detect an inconsistency between
intention and the actual information given in the timestamp, e.g.,
Sharma & Bormann Expires 6 June 2022 [Page 3]
Internet-Draft Timestamps Extended December 2021
between the additional timezone information given and the timezone
offset recorded in the timestamp. For instance, such an
inconsistency might arise because of:
* Political decisions as discussed above, or
* errors in the applications producing and consuming such a
timestamp.
While the information available is not generally sufficient to
resolve the inconsistency, it may be used to initiate some out of
band processing to obtain sufficient information for such a
resolution.
In order to address some of the requirements implied here, future
related specifications might define syntax and semantics of strings
similar to [RFC3339]. Note that the extension syntax defined in the
present document is designed in such a way that it can be useful for
such specifications as well.
1.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 timescale
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 implicitly.
Internet Date/Time Format: The date/time format defined in section 3
of this document.
Sharma & Bormann Expires 6 June 2022 [Page 4]
Internet-Draft Timestamps Extended December 2021
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 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.
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].
2. 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.
2.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. The key of a tag can be split into two parts by
including a hyphen/minus sign "-"; the first part (including the "-")
can then be used as a namespace. The value of a tag can be a hyphen/
minus delimited list of multiple values.
Out of these tags, applications can build an informative _suffix_ at
the end with as many tags as required.
Keys are case-sensitive. Values are case-sensitive unless otherwise
specified.
In case a suffix repeats a key or otherwise contains conflicting
tags, implementations MUST give precedence to whichever value is
positioned first.
// I'd rather place a MUST NOT for this case, first. This definitely
// needs to be expanded into some general text about error handling.
//
// -- --- cabo
Sharma & Bormann Expires 6 June 2022 [Page 5]
Internet-Draft Timestamps Extended December 2021
2.2. Namespaced
Suffix keys identify a _namespace_. By including a hyphen/minus sign
"-", the namespace can be separated from the rest of the key; if no
hyphen/minus sign is included, the whole key is the namespace.
For example, if "u-" is a namespace for the Unicode consortium, a
calendar as defined by that consortium could be included as
u-ca=<value>.
An IANA registry for namespaces can be used to allocate namespaces
for specific applications, as defined in Section 4. Two namespaces
are allocated by the present document:
* "u-" for keys defined by the Unicode consortium.
* "x-" for keys used within experiments. Such keys are not for
general interchange and MUST be rejected by a recipient unless
that is specifically enabled for an experiment. See [RFC6648] for
additional considerations about "x-" namespaces.
* In addition, for CLDR extensions:
// I don't know how this would be used, so I can't edit this text.
//
// -- --- cabo
- There must be a namespace-key and it is restricted to 2
alphanum characters.
- A suffix-value is limited to 3*8alphanum.
Additional namespaces can be registered under an Expert review
policy, providing a description for the intended use. This may be a
general concept, or a specific organization that is intended to
register keys within this namespace.
2.3. Registered
Actual keys are registered by supplying the information in Figure 1:
Sharma & Bormann Expires 6 June 2022 [Page 6]
Internet-Draft Timestamps Extended December 2021
%%
Identifier:
Description:
Comments:
Added:
RFC:
Authority:
Contact_Email:
Mailing_List:
URL:
%%
Figure 1: Registration record for a tag key
'Identifier' contains the key name.
'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 key's definition was published in the
"date-full" format specified in Figure 2. 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.
3. Syntax Extensions to RFC 3339
3.1. ABNF
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.
date-time is imported from Section 5.6 of [RFC3339], ALPHA and DIGIT
from Appendix B.1 of [RFC5234].
Sharma & Bormann Expires 6 June 2022 [Page 7]
Internet-Draft Timestamps Extended December 2021
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
Note that a time-zone is syntactically similar to a suffix-tag, but
does not use a suffix-key and an equals sign. This special case is
only available for timezone tags.
3.2. 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.
Sharma & Bormann Expires 6 June 2022 [Page 8]
Internet-Draft Timestamps Extended December 2021
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
Define a registry that can contain both namespaces and keys.
Namespaces can be recognized by ending with a hyphen/minus. Actual
keys do not. See Section 2.3 for the detailed information (to be
edited).
The policy is "RFC required", "Specification Required", ???
// We need to define the policy for both namespaces and full keys.
//
// -- --- cabo[RFC8126].
5. Security Considerations
TBD
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
Sharma & Bormann Expires 6 June 2022 [Page 9]
Internet-Draft Timestamps Extended December 2021
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[CLDR] "Unicode CLDR Project", <https://cldr.unicode.org>.
[IERS] "International Earth Rotation Service Bulletins",
<https://www.iers.org/IERS/EN/Publications/Bulletins/
bulletins.html>.
[ISO8601] International Organization for Standardization, "Data
elements and interchange formats — Information interchange
— Representation of dates and times", ISO 8601:1988, June
1988, <https://www.iso.org/standard/15903.html>.
[ITU-R-TF.460-6]
"ITU-R TF.460-6. Standard-frequency and time-signal
emissions", February 2002,
<https://www.itu.int/rec/R-REC-TF.460/en>.
[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>.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/info/rfc6648>.
Sharma & Bormann Expires 6 June 2022 [Page 10]
Internet-Draft Timestamps Extended December 2021
Appendix A. Acknowledgements
TBD
Authors' Addresses
Ujjwal Sharma
Igalia, S.L.
Bugallal Marchesi, 22, 1º
15008 A Coruña
Spain
Email: ryzokuken@igalia.com
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Sharma & Bormann Expires 6 June 2022 [Page 11]