From 5a9661d62a5d7598f2273f86da810fe645de8de4 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 12 Oct 2023 04:59:02 +0000 Subject: [PATCH] Script updating gh-pages from ff7ae0a. [ci skip] --- index.html | 8 + .../draft-ietf-sedate-datetime-extended.html | 2214 +++++++++++++++++ .../draft-ietf-sedate-datetime-extended.txt | 849 +++++++ registry-group-name/index.html | 45 + 4 files changed, 3116 insertions(+) create mode 100644 registry-group-name/draft-ietf-sedate-datetime-extended.html create mode 100644 registry-group-name/draft-ietf-sedate-datetime-extended.txt create mode 100644 registry-group-name/index.html diff --git a/index.html b/index.html index 96893b5..f52b220 100644 --- a/index.html +++ b/index.html @@ -32,6 +32,14 @@

Preview for branch mention-8601-2019

diff with main +

Preview for branch registry-group-name

+ + + + + + +
Internet Extended Date/Time Fmt (IXDTF)plain textdiff with main
+ + diff --git a/registry-group-name/draft-ietf-sedate-datetime-extended.txt b/registry-group-name/draft-ietf-sedate-datetime-extended.txt new file mode 100644 index 0000000..ab8c040 --- /dev/null +++ b/registry-group-name/draft-ietf-sedate-datetime-extended.txt @@ -0,0 +1,849 @@ + + + + +Serialising Extended Data About Times and Events U. Sharma +Internet-Draft Igalia, S.L. +Updates: 3339 (if approved) C. Bormann +Intended status: Standards Track Universität Bremen TZI +Expires: 14 April 2024 12 October 2023 + + + Date and Time on the Internet: Timestamps with additional information + draft-ietf-sedate-datetime-extended-latest + +Abstract + + This document defines an extension to the timestamp format defined in + RFC3339 for representing additional information including a time + zone. + + It updates RFC3339 in the specific interpretation of the local offset + Z, which is no longer understood to "imply that UTC is the preferred + reference point for the specified time"; see Section 2. + + + // (This "cref" paragraph will be removed by the RFC editor:) The + // present version (-09) addresses comments received during IETF last + // call. + +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/. Subscribe at + https://www.ietf.org/mailman/listinfo/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." + + This Internet-Draft will expire on 14 April 2024. + +Copyright Notice + + Copyright (c) 2023 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 + 1.1. Scope + 1.2. Definitions + 2. Updating RFC 3339 + 2.1. Background + 2.2. Update to RFC 3339 + 2.3. Notes + 3. Internet Extended Date/Time format (IXDTF) + 3.1. Format of Extended Information + 3.2. Registering Keys for Extended Information Tags + 3.3. Optional Generation, Elective vs. Critical Consumption + 3.4. Inconsistent time-offset/Time-Zone Information + 4. Syntax Extensions to RFC 3339 + 4.1. ABNF + 4.2. Examples + 5. The u-ca Suffix Key: Calendar Awareness + 6. IANA Considerations + 7. Security Considerations + 7.1. Excessive Disclosure + 7.2. Data Format Implementation Vulnerabilities + 7.3. Operating with Inconsistent Data + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +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. [ISO8601-1:2019] standardizes a + widely-adopted timestamp format, an earlier version of which + [ISO8601:1988] formed the basis of the Internet Date/Time Format + [RFC3339]. However, this format allows timestamps to contain only + very little additional relevant information. 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 a pressing issue for applications that handle each instant + with an associated time zone name, in order to take into account + events such as daylight saving time transitions. Many of these + applications attach the time zone 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 in + which it should be represented. + +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 additional + information to the timestamp. + + We refer to this format as the Internet Extended Date/Time Format + (IXDTF). + + This document does not address extensions to the format where the + semantic result is no longer 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 (such as a + political decision to enact or rescind daylight saving time) + affect the instant in time represented by the timestamp. + + * "Floating time", i.e., a local time without information describing + the UTC offset or time zone in which it should be interpreted. + + * The use of timescales different from UTC, such as International + Atomic Time (TAI). + + However, additional information augmenting a fixed timestamp may be + sufficient to detect an inconsistency between intention and the + actual information in the timestamp, such as between the UTC offset + and time zone name. For instance, inconsistencies might arise + because of: + + * political decisions as discussed above, or + + * updates to time zone definitions being applied at different times + by timestamp producers and receivers, or + + * errors in applications producing and consuming timestamps. + + While the information available in an IXDTF string is not generally + sufficient to resolve an 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 Extended Date/Time Format (IXDTF): The date/time format + defined in Section 4 of this document. + + Timestamp: An unambiguous representation of a particular instant in + time. + + UTC Offset: Difference between a given local time and UTC, usually + given in negative or positive hours and minutes. For example, + local time in New York in the wintertime is 5 hours behind UTC, so + its UTC offset is "-05:00". + + 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". (Definition from Section 2 of + [RFC3339].) + + Time Zone: A set of rules representing the relationship of local + time to UTC for a particular place or region. Mathematically, a + time zone can be thought of as a function that maps timestamps to + UTC offsets. Time zones can deterministically convert a timestamp + to local time. They can also be used in the reverse direction to + convert local time to a timestamp, with the caveat that some local + times may have zero or multiple possible timestamps due to nearby + daylight saving time changes or other changes to the UTC offset of + that time zone. Unlike the UTC offset of a timestamp which makes + no claims about the UTC offset of other related timestamps (and + which is therefore unsuitable for performing local-time operations + such as "one day later"), a time zone also defines how to derive + new timestamps based on differences in local time. For example, + to calculate "one day later than this timestamp in San Francisco", + a time zone is required because the UTC offset of local time in + San Francisco can change from one day to the next. + + IANA Time Zone: A named time zone that is included in the Time Zone + Database (often called tz or zoneinfo) maintained by IANA + [TZDB][BCP175]. Most IANA time zones are named for the largest + city in a particular region that shares the same time zone rules, + e.g., Europe/Paris or Asia/Tokyo [TZDB-NAMING]. + + The rules defined for a named IANA time zone can change over time. + The use of a named IANA time zone implies that the intent is for + the rules to apply that are current at the time of interpretation: + the additional information conveyed by using that time zone name + is to change with any rule changes as recorded in the IANA time + zone database. + + Offset Time Zone: A time zone defined by a specific UTC offset, e.g. + +08:45, and serialized using as its name the same numeric UTC + offset format used in an RFC 3339 timestamp, for example: + + 2022-07-08T00:14:07+08:45[+08:45] + + An offset in the suffix that does not repeat the offset of the + timestamp is inconsistent (see Section 3.4). + + Although serialization with offset time zones is supported in this + document for backwards compatibility with java.time.ZonedDateTime + [JAVAZDT], use of offset time zones is strongly discouraged. In + particular, programs MUST NOT copy the UTC offset from a timestamp + into an offset time zone in order to satisfy another program which + requires a time zone suffix in its input. Doing this will + improperly assert that the UTC offset of timestamps in that + location will never change, which can result in incorrect + calculations in programs that add, subtract, or otherwise derive + new timestamps from the one provided. For example, 2020-01- + 01T00:00+01:00[Europe/Paris] will let programs add six months to + the timestamp while adjusting for Summer Time (daylight saving + time). But the same calculation applied to + 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result + that will be off by one hour in the timezone Europe/Paris. + + CLDR: Common locale data repository [CLDR], a project of the Unicode + Consortium to provide locale data to applications. + + For more information about timescales, see Appendix E of [RFC1305], + Section 3 of [ISO8601:1988], and the appropriate ITU documents + [ITU-R-TF.460-6]. + +2. Updating RFC 3339 + +2.1. Background + + Section 4.3 of [RFC3339] states that an offset given as Z or +00:00 + implies that "UTC is the preferred reference point for the specified + time". The offset -00:00 is provided as a way to express that "the + time in UTC is known, but the offset to local time is unknown". + + This convention mirrors a similar convention for date/time + information in email headers, described in Section 3.3 of [RFC5322] + and introduced earlier in Section 3.3 of [RFC2822]. This email + header convention is in actual use, while its adaptation into + [RFC3339] always was handicapped by the fact that [ISO8601:2000] and + later versions do not actually allow -00:00. + + Implementations that needed to express the semantics of -00:00 + therefore tended to use Z instead. + +2.2. Update to RFC 3339 + + This specification updates Section 4.3 of [RFC3339], aligning it with + the actual practice of interpreting the offset Z to mean the same as- + 00:00: "the time in UTC is known, but the offset to local time is + unknown". + + A revised Section 4.3 of [RFC3339] with the update could read as + follows: + + | If the time in UTC is known, but the offset to local time is + | unknown, this can be represented with an offset of "Z". (The + | original version of this specification provided "-00:00" for this + | purpose, which is not allowed by [ISO8601:2000] and therefore is + | less interoperable; Section 3.3 of [RFC5322] describes a related + | convention for email which does not have this problem). This + | differs semantically from an offset of "+00:00", which implies + | that UTC is the preferred reference point for the specified time. + +2.3. Notes + + Note that the semantics of the local offset +00:00 is not updated; + this retains the implication that UTC is the preferred reference + point for the specified time. + + Note also that the fact that [ISO8601:2000] and later do not allow + -00:00 as a local offset reduces the level of interoperability that + can be achieved in using this feature; the present specification + however does not formally deprecate this syntax. With the update to + RFC 3339, the local offset Z can be used in its place. + +3. Internet Extended Date/Time format (IXDTF) + + This section discusses desirable qualities of formats for the + timestamp extension suffix and defines the IXDTF format, which + extends [RFC3339] for use in Internet protocols. + +3.1. Format of Extended Information + + The format allows implementations to specify additional important + information in addition to a bare [RFC3339] timestamp. + + This is done by defining _tags_, each with a _key_ and a _value_ + separated by an equals sign. The value of a tag can be one or more + items delimited by hyphen/minus signs. + + Applications can build an informative timestamp _suffix_ using any + number of these tags. + + Keys are lower-case only. Values are case-sensitive unless otherwise + specified. + + See Section 3.3 for the handling of inconsistent information in a + suffix. + +3.2. Registering Keys for Extended Information Tags + + Suffix tag keys are registered by supplying the information specified + in this section. This information is modeled after that specified + for the media type registry [RFC6838]; if in doubt, the provisions of + this registry should be applied analogously. + + Key Identifier: The key (conforming to suffix-key in Section 4.1) + + Registration status: "Provisional" or "Permanent" + + Description: A very brief description of the key. + + Change controller: Who is in control of evolving the specification + governing values for this key. This information can include email + addresses of contact points and discussion lists, and references + to relevant web pages (URLs). + + Reference: A reference. For permanent tag keys, this includes a + full specification. For provisional tag keys, there is an + expectation that some information is available even if that does + not amount to a full specification; in this case, the registrant + is expected to improve this information over time. + + Key names that start with an underscore are intended for experiments + in controlled environments and cannot be registered; such keys MUST + NOT be used for interchange and MUST be rejected by implementations + not specifically configured to take part in such an experiment. See + [BCP178] for a discussion about the danger of experimental keys + leaking out to general production and why that MUST be prevented. + +3.3. Optional Generation, Elective vs. Critical Consumption + + For the IXDTF format, suffix tags are always _optional_: They can be + added or left out as desired by the generator of the string. (An + application might require the presence of specific suffix tags, + though.) + + Without further indication, suffix tags are also _elective_: The + recipient is free to ignore any suffix tag included in an IXDTF + string. Reasons might include that the recipient does not implement + (or know about) the specific suffix key, or that it does recognize + the key but cannot act on the value provided. + + A suffix tag may also indicate that it is _critical_: The recipient + is advised that it MUST NOT act on the Internet Extended Date/Time + Format (IXDTF) string unless it can process the suffix tag as + specified. A critical suffix tag is indicated by following its + opening bracket with an exclamation mark (see critical-flag in + Section 4.1). + + For example, IXDTF strings such as: + + 2022-07-08T00:14:07+01:00[Europe/Paris] + + are internally inconsistent (see Section 3.4), because Europe/Paris + did not use a time zone offset of +01:00 in July 2022. The time zone + hint given in the suffix tag is elective, though, so the recipient is + not required to act on the inconsistency; it can treat the Internet + Date/Time Format string as if it were: + + 2022-07-08T00:14:07+01:00 + + | Note that as per Section 2 (see also Section 3.4), the IXDTF + | string: + | + | 2022-07-08T00:14:07Z[Europe/Paris] + | + | does not exhibit such an inconsistency, as the local offset of + | Z does not imply a specific preferred time zone of + | interpretation. Using the Time Zone Database rules for Europe/ + | Paris in the summer of 2022, it is equivalent to: + | + | 2022-07-08T02:14:07+02:00[Europe/Paris] + + Similarly, an unknown suffix may be entirely ignored: + + 2022-07-08T00:14:07+01:00[knort=blargel] + + (assuming that the recipient does not understand the suffix key + knort). + + In contrast to this elective use of a suffix tag, + + 2022-07-08T00:14:07+01:00[!Europe/Paris] + 2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese] + 2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese] + 2022-07-08T00:14:07Z[!knort=blargel] + + each have an internal inconsistency or an unrecognized suffix key/ + value that are marked as critical, so a recipient MUST treat these + IXDTF strings as erroneous. This means that the application MUST + reject the data, or perform some other error handling, such as asking + the user how to resolve the inconsistency (see Section 3.4). + + Note that applications MAY also perform additional processing on + inconsistent or unrecognized elective suffix tags, such as asking the + user how to resolve the inconsistency. While they are not required + to do so with elective suffix tags, they are required to reject or + perform some other error handling when encountering inconsistent or + unrecognized suffix tags marked as critical. + + An application that encounters duplicate use of a suffix key in + elective suffixes and does not want to perform additional processing + on this inconsistency MUST choose the first suffix that has that key, + i.e., + + 2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese] + 2022-07-08T00:14:07Z[u-ca=chinese] + + are then treated the same. + +3.4. Inconsistent time-offset/Time-Zone Information + + An RFC 3339 timestamp can contain a time-offset value that indicates + the offset between local time and UTC (see Section 4 of [RFC3339], + noting that Section 2 of the present specification updates + Section 4.3 of [RFC3339]). + + The information given in such a time-offset value can be inconsistent + with the information provided in a time zone suffix for an IXDTF + timestamp. + + For example, a calendar application could store an IXDTF string + representing a far-future meeting in a particular time zone. If that + time zone's definition is subsequently changed to abolish daylight + saving time, IXDTF strings that were originally consistent may now be + inconsistent. + + In case of inconsistent time-offset and time zone suffix, if the + critical flag is used on the time zone suffix, an application MUST + act on the inconsistency. If the critical flag is not used, it MAY + act on the inconsistency. Acting on the inconsistency may involve + rejecting the timestamp, or resolving the inconsistency via + additional information such as user input and/or programmed behavior. + + For example, the IXDTF timestamps in Figure 1 represent 00:14:07 UTC, + indicating a local time with a time-offset of +00:00. However, + because Europe/London used offset +01:00 in July 2022, the timestamps + are inconsistent: + + 2022-07-08T00:14:07+00:00[!Europe/London] + 2022-07-08T00:14:07+00:00[Europe/London] + + Figure 1: Inconsistent IXDTF timestamps + + As per Section 4.3 of [RFC3339] as updated by Section 2, IXDTF + timestamps may also forego indicating local time information in their + [RFC3339] part by using Z instead of a numeric time zone offset. The + IXDTF timestamps in Figure 2 (which represent the same instant in + time as the strings in Figure 1) are not inconsistent because they do + not assert any particular local time nor local offset in their + [RFC3339] part. Instead, applications that receive these strings can + calculate the local offset and local time using the rules of the time + zone suffix, such as Europe/London in the example below. + + 2022-07-08T00:14:07Z[!Europe/London] + 2022-07-08T00:14:07Z[Europe/London] + + Figure 2: No inconsistency in IXDTF timestamps + + Note that -00:00 may be used instead of Z, because they have the same + meaning according to Section 2, but -00:00 is not allowed by + [ISO8601:2000] and later so Z is preferred. + +4. Syntax Extensions to RFC 3339 + +4.1. ABNF + + The following rules extend the ABNF syntax defined in [RFC3339] in + order to allow the inclusion of an optional suffix. + + The Internet Extended Date/Time Format (IXDTF) is described by the + rule date-time-ext. + + date-time and time-numoffset are imported from Section 5.6 of + [RFC3339], ALPHA and DIGIT from Appendix B.1 of [RFC5234]. + + time-zone-initial = ALPHA / "." / "_" + time-zone-char = time-zone-initial / DIGIT / "-" / "+" + time-zone-part = time-zone-initial *time-zone-char + ; but not "." or ".." + time-zone-name = time-zone-part *("/" time-zone-part) + time-zone = "[" critical-flag + time-zone-name / time-numoffset "]" + + key-initial = lcalpha / "_" + key-char = key-initial / DIGIT / "-" + suffix-key = key-initial *key-char + + suffix-value = 1*alphanum + suffix-values = suffix-value *("-" suffix-value) + suffix-tag = "[" critical-flag + suffix-key "=" suffix-values "]" + suffix = [time-zone] *suffix-tag + + date-time-ext = date-time suffix + + critical-flag = [ "!" ] + + alphanum = ALPHA / DIGIT + lcalpha = %x61-7A + + Figure 3: ABNF grammar of extensions to RFC 3339 + + Note that a time-zone is syntactically similar to a suffix-tag, but + does not include an equals sign. This special case is only available + for time zone tags. + + time-zone-name is intended to be the name of an IANA Time Zone. As + generator and recipient may be using different revisions of the Time + Zone Database, recipients may not be aware of such an IANA Time Zone + name and should treat such a situation as any other inconsistency. + + | Note: At the time of writing, the length of each time-zone-part + | is limited to a maximum of 14 characters by the rules in + | [TZDB-NAMING]. One platform is known to enforce this limit, an + | entry in a timezone database on another platform is known to + | exceed this limit. As the time-zone-name will ultimately have + | to be looked up in the database, which therefore has control + | over the length, the time-zone-part production in Figure 3 is + | deliberately permissive. + +4.2. Examples + + Here are some examples of Internet Extended Date/Time Format (IXDTF). + + 1996-12-19T16:39:57-08:00 + + Figure 4: RFC 3339 date-time with time zone offset + + Figure 4 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 5: Adding a time zone name + + Figure 5 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 6: Projecting to the Hebrew calendar + + Figure 6 represents the exact same instant, but it informs calendar- + aware implementations (see Section 5) that they should project it to + the Hebrew calendar. + + 1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat] + + Figure 7: Adding experimental tags + + Figure 7, based on Figure 4, utilizes keys identified as experimental + by a leading underscore to declare two additional pieces of + information in the suffix; these can be interpreted by + implementations that take part in the controlled experiment making + use of these tag keys. + +5. The u-ca Suffix Key: Calendar Awareness + + Out of the possible suffix keys, the suffix key u-ca is allocated to + indicate the calendar in which the date/time is preferably presented. + + A calendar is a set of rules defining how dates are counted and + consumed by implementations. The set of suffix values allowed for + this suffix key is the set of values defined for the Unicode Calendar + Identifier [TR35]. A resource that has been built to provide links + into the most recent stable and development [CLDR] information about + that is provided by [CLDR-LINKS]. + +6. IANA Considerations + + + // RFC Editor: please replace RFCthis with the RFC number of this RFC + // and remove this note. + + IANA is requested to establish a registry called "Timestamp Suffix + Tag Keys" in a new registry group "Internet Date/Time Format". Each + entry in the registry shall consist of the information described in + Section 3.2. Initial contents of the registry are specified in + Table 1. + + +============+==============+==============+============+=========+ + | Key | Registration | Description: | Change |Reference| + | Identifier | status | | controller | | + +============+==============+==============+============+=========+ + | u-ca | Permanent | Preferred | IESG |Section 5| + | | | Calendar for | |of | + | | | Presentation | |RFCthis | + +------------+--------------+--------------+------------+---------+ + + Table 1: Initial Content of Timestamp Suffix Tag Keys registry + + The registration policy [BCP26] is "Specification Required" for + permanent entries, and "Expert Review" for provisional ones. In the + second case, the expert is instructed to ascertain that a basic + specification does exist, even if not complete or published yet. + +7. Security Considerations + +7.1. Excessive Disclosure + + The ability to include various pieces of ancillary information with a + timestamp might lead to excessive disclosure. An example for + possibly excessive disclosure is given in Section 7 of [RFC3339]. + Similarly, divulging information about the calendar system or the + language of choice may provide more information about the originator + of a timestamp than the data minimization principle would permit + [DATA-MINIMIZATION]. More generally speaking, generators of IXDTF + timestamps need to consider whether information to be added to the + timestamp is appropriate to divulge to the recipients of this + information, and need to err on the side of minimizing such + disclosure if the set of recipients is not under control of the + originator. + +7.2. Data Format Implementation Vulnerabilities + + As usual when extending the syntax of a data format, this can lead to + new vulnerabilities in implementations parsing and processing the + format. No considerations are known for the IXDTF syntax that would + pose concerns that are out of the ordinary. + +7.3. Operating with Inconsistent Data + + Information provided in the various parts of an IXDTF string may be + inconsistent in interesting ways, both with the extensions defined in + this specification (see for instance Section 3.4) and with future + extensions still to be defined. Where consistent interpretation + between multiple actors is required for security purposes (e.g., + where timestamps are embedded as parameters in access control + information), only such extensions can be employed that have a + defined resolution of such inconsistent data. + +8. References + +8.1. Normative References + + [BCP175] Lear, E. and P. Eggert, "Procedures for Maintaining the + Time Zone Database", BCP 175, RFC 6557, + DOI 10.17487/RFC6557, February 2012, + . + + [BCP178] 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, + . + + [BCP26] 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, + . + + [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, + . + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +8.2. Informative References + + [CLDR] "Unicode CLDR Project", . + + [CLDR-LINKS] + Unicode CLDR, "Stable Links Info", + . + + [DATA-MINIMIZATION] + Arkko, J., "Emphasizing data minimization among protocol + participants", Work in Progress, Internet-Draft, draft- + arkko-iab-data-minimization-principle-05, 10 July 2023, + . + + [IERS] "International Earth Rotation Service Bulletins", + . + + [ISO8601-1:2019] + ISO, "Date and time — Representations for information + interchange — Part 1: Basic rules", ISO 8601-1:2019, + February 2019, . + + [ISO8601:1988] + ISO, "Data elements and interchange formats — Information + interchange — Representation of dates and times", + ISO 8601:1988, June 1988, + . Also available + from . + + [ISO8601:2000] + ISO, "Data elements and interchange formats — Information + interchange — Representation of dates and times", + ISO 8601:2000, December 2000, + . + + [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, + . + + [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, + DOI 10.17487/RFC2822, April 2001, + . + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + . + + [TR35] "Unicode Technical Standard #35: Unicode Locale Data + Markup Language (LDML)", . + + [TZDB] "Sources for time zone and daylight saving time data", + . + + [TZDB-NAMING] + "Theory and pragmatics of the tz code and data", + . + +Acknowledgements + + Richard Gibson and Justin Grant provided editorial improvements. The + authors would like to thank Francesca Palombini for her AD review. + +Contributors + + Justin Grant + Email: justingrant.ietf.public@gmail.com + + +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 diff --git a/registry-group-name/index.html b/registry-group-name/index.html new file mode 100644 index 0000000..088c261 --- /dev/null +++ b/registry-group-name/index.html @@ -0,0 +1,45 @@ + + + + ietf-wg-sedate/draft-ietf-sedate-datetime-extended registry-group-name preview + + + + +

Editor's drafts for registry-group-name branch of ietf-wg-sedate/draft-ietf-sedate-datetime-extended

+ + + + + + +
Internet Extended Date/Time Fmt (IXDTF)plain textsame as main
+ + +