RFC 9557

Date and Time on the Internet: Timestamps with Additional Information

📅 published April 2024, from ietf

RFC 9557: Date and Time on the Internet: Timestamps with Additional Information ✨

Okay bestie, this one is a glow-up for timestamps 🎀 It's RFC 9557, written by U. Sharma (Igalia, S.L.) and C. Bormann (Universität Bremen TZI). It's a Standards Track doc, dated April 2024, with ISSN 2070-1721 💅 It updates RFC 3339, so it builds on that one rather than replacing it. The header doesn't list anything it obsoletes, so this is just an update 🦋

(part 1 of 4, more coming soon 💜)

Abstract 🌸

This doc gives the timestamp format from RFC 3339 an extension so you can attach extra info to a timestamp, time zone included 🕰️

It updates RFC 3339 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" 👀

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9557.

Copyright (c) 2024 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 and Elective vs. Critical Consumption
  3.4.  Inconsistent time-offset and 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 show up in a super diverse set of Internet apps, all the way from server-side logging to calendaring and scheduling 📅

Each distinct instant in time can be written down in a descriptive text format using a timestamp. [ISO8601-1:2019] standardizes a widely adopted timestamp format, and an earlier version of it, [ISO8601:1988], formed the basis of the Internet Date/Time Format [RFC3339]. The problem is this format lets timestamps carry very little extra relevant info 😩 Anything else you want to know about a timestamp has to be handled separately or stuffed in a non-standard way 💀

This is a pressing issue for apps that pair each instant with a time zone name so they can handle things like daylight saving time transitions ⏰ Lots of these apps attach the time zone to the timestamp in a non-standard format, and at least one of those formats is pretty well-adopted [JAVAZDT]. Apps might even want to attach more stuff to the timestamp, including (but not limited to) the calendar system it should be represented in 🌈

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 🦋

1.1. Scope 🌸

[RFC3339] defines a syntax for timestamps to represent date and time in the Internet. This doc defines an extension syntax that gets these properties:

  • The extension suffix is completely optional, so existing [RFC3339] timestamps are compatible with this format 🫶
  • The format is compatible with the pre-existing popular syntax for attaching time zone names to timestamps [JAVAZDT] 💅
  • The format gives you 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 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; or
  • 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 the 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,
  • updates to time zone definitions being applied at different times by timestamp producers and receivers, or
  • errors in programs 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 kick off some out-of-band processing to get enough info for such a resolution 🔍

In order to address some of the requirements implied here, related specifications in the future might define syntax and semantics of strings similar to those described in [RFC3339]. Note that the extension syntax defined in this document is designed so it can be useful for such specifications as well 🌟

(to be continued in part 2 🫶)

1.2. Definitions 💅

okay so before we get into the juicy stuff, we need to agree on some words 🤓 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 Systems Service [IERS]. From 1972 through 1987, UTC was maintained entirely by the 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 (Greenwich Mean Time), an earlier timescale for which UTC was designed to be a useful successor. 🌍

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

IXDTF: Internet Extended Date/Time Format, 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 the city of New York, NY, USA in the wintertime in 2023 was 5 hours behind UTC, so its UTC offset was -05:00. 🗽

Z: A suffix that, when applied to a time, denotes a UTC offset of 00:00; often pronounced "Zulu" from the ICAO phonetic alphabet representation of the letter "Z". (The definition is from Section 2 of [RFC3339]; see the International Civil Aviation Organization (ICAO) document [ICAO-PA] for the phonetic alphabet mentioned.) 🫶

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, California", 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 that are current at the time of interpretation to apply: 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 [RFC3339] 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 that 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). However, 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 time zone Europe/Paris.

Okay, this is the part to read twice 😭 Copying the offset into an offset time zone just to make another program happy is a trap, and it breaks the math for anything that adds or subtracts time. Use a real named zone instead!

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]. (Note: [RFC1305] was obsoleted by [RFC5905], which no longer contains the Appendix E referenced here.) 🕰️

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 that is 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] was always compromised 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". 🎀

Section 4.3 of [RFC3339] is revised to 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. 🧐

Also note 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; however, the present specification does not formally deprecate this syntax. With the update to [RFC3339], the local offset Z should now 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 applications 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 lowercase 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 Types" 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, 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 and Elective vs. Critical Consumption 🎀

For the IXDTF format, suffix tags are always optional 🌸 The generator of the string can add them or leave them out, whatever it likes. (An application might require specific suffix tags to be there, though 👀)

Without further indication, suffix tags are also elective 💖 The recipient is free to ignore any suffix tag in an IXDTF string. It might not implement that suffix key, or not even know about it, or it might recognize the key but not be able to do anything with the value it was given.

A suffix tag can also be critical ⚠️ The recipient is advised that it MUST NOT act on the IXDTF string unless it can process the suffix tag as specified. You mark a critical suffix tag by putting an exclamation mark right after its opening bracket (see critical-flag in Section 4.1) ✨

Here's how it plays out. IXDTF strings like this one:

2022-07-08T00:14:07+01:00[Europe/Paris]

are internally inconsistent (see Section 3.4) 💀 Europe/Paris did not use a time zone offset of +01:00 in July 2022. BUT the time zone hint in that suffix tag is elective, so the recipient isn't 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].

An unknown suffix can also be totally ignored 🙈

2022-07-08T00:14:07+01:00[knort=blargel]

(assuming that the recipient does not understand the suffix key knort).

Now compare that with these ones, where the suffix is marked critical 🚨

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 of these has an internal inconsistency, or an unrecognized suffix key/value, that is marked as critical. So a recipient MUST treat these IXDTF strings as erroneous 😤 That means the application MUST reject the data or do some other error handling, like asking the user how to resolve the inconsistency (see Section 3.4).

Note that applications MAY also do extra processing on inconsistent or unrecognized elective suffix tags, like asking the user how to fix the inconsistency. They aren't required to do that with elective suffix tags, but they are required to reject the string or do some other error handling when they run into inconsistent or unrecognized suffix tags that are marked as critical 🫶

If an application runs into a duplicate use of a suffix key among the elective suffixes, and doesn't want to do any extra processing on that inconsistency, it MUST choose the first suffix that has that key. So these are treated the same:

2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
2022-07-08T00:14:07Z[u-ca=chinese]

3.4. Inconsistent time-offset and Time Zone Information 🌈

An [RFC3339] timestamp can contain a time-offset value that shows 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]).

That time-offset value can disagree with the information in a time zone suffix on an IXDTF timestamp. Oops 😬

For example, a calendar app could store an IXDTF string for a far-future meeting in a particular time zone. If that time zone's definition later changes to abolish daylight saving time, IXDTF strings that used to be consistent may now be inconsistent 📅

If there's an inconsistency between the time-offset and the time zone suffix: when 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 it might mean rejecting the timestamp, or resolving it with extra information like user input and/or programmed behavior 🧚

Look at the IXDTF timestamps in Figure 1. They represent 00:14:07 UTC, which indicates a local time with a time-offset of +00:00. But because Europe/London used offset +01:00 in July 2022, these timestamps are inconsistent. The first case is one where the application MUST act on the inconsistency (the time zone suffix is marked critical). The second case is one where it MAY act on the inconsistency (the time zone suffix is elective) 🍓

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 can also skip the 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 as the strings in Figure 1) are NOT inconsistent, because they don't assert any particular local time or local offset in their [RFC3339] part. Instead, applications that receive these strings can work out the local offset and local time using the rules of the time zone suffix, like Europe/London in the Figure 2 example. Just like Figure 1, this has one case with a time zone suffix marked critical (so the application must understand the time zone information) and one marked elective, which is only provided as additional information 💅

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] so you can include 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], and ALPHA and DIGIT are imported 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

Heads up: a time-zone looks a lot like a suffix-tag, but it doesn't have an equals sign. That's the only place this special case is allowed, and it's for time zone tags only 🤓

The ABNF definition of time-zone-part matches "." and "..", which are both explicitly excluded (see the note below on time-zone-part).

time-zone-name is meant to be the name of an IANA Time Zone. A generator and a recipient might be using different revisions of the Time Zone Database, so recipients may not know about a given IANA Time Zone name. They should treat that situation like 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, and a time zone name on another platform is known to exceed this limit. As the time-zone-name will ultimately have to be looked up in the local database, which therefore has control over the length, the time-zone-part production in Figure 3 is deliberately permissive.

4.2. Examples

This section has 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 is 39 minutes and 57 seconds after the 16th hour of December 19, 1996, with an offset of -08:00 from UTC. Fun fact: this is the same instant 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 is the exact same instant as the previous example, but it also specifies the human time zone associated with it ("Pacific Time") so time-zone-aware applications can take that into account 🌴

1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

Figure 6: Projecting to the Hebrew Calendar

Figure 6 is the exact same instant again, but it tells calendar-aware applications (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, uses keys that are identified as experimental by a leading underscore. These declare two extra pieces of information in the suffix, which can be interpreted by implementations taking part in the controlled experiment that uses 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]. [CLDR-LINKS] provides links to the most recent information about [CLDR], both stable and specific development stages 🌸

6. IANA Considerations ✨

okay so IANA is making a brand new registry called "Timestamp Suffix Tag Keys" 🗂️ and it's living inside a new registry group called "Internet Date/Time Format" 💅 every entry in it shall consist of the info from Section 3.2. the starter entries are listed in Table 1 👇

+============+==============+==============+============+=========+
| Key        | Registration | Description  | Change     |Reference|
| Identifier | Status       |              | Controller |         |
+============+==============+==============+============+=========+
| u-ca       | Permanent    | Preferred    | IETF       |Section 5|
|            |              | Calendar for |            |of RFC   |
|            |              | Presentation |            |9557     |
+------------+--------------+--------------+------------+---------+

  Table 1: Initial Contents of Timestamp Suffix Tag Keys Registry

so the registration policy [BCP26] is "Specification Required" for permanent entries 🎀 and "Expert Review" for provisional ones 🌸 for the provisional ones, the experts are told to make sure a basic specification exists, even if it's not finished or published yet 📝

the experts also get a little reminder to be frugal 🥹 short key identifiers that hint at generally applicable meaning should be saved for suffix keys that are likely to be widely used and that can really benefit from the shortness of the identifier 🧚 and if the experts notice key identifiers that are already deployed and in use, they may also start a registration on their own, if they think that would help prevent possible future collisions 🫶

7. Security Considerations 🔐

7.1. Excessive Disclosure

okay this part is kinda serious bestie 😭 the ability to tack extra bits of info onto a timestamp might lead to excessive disclosure 🙈 Section 7 of [RFC3339] has an example of what possibly excessive disclosure looks like 📖 and similarly, spilling details about the calendar system or the language you picked could tell people more about who made the timestamp than the data minimization principle would allow [DATA-MINIMIZATION] 💀 more generally, if you're generating IXDTF timestamps, you need to think about whether the extra info is okay to share with the people receiving it 🧐 and if the recipients aren't under the originator's control, you need to err on the side of sharing less 🤫🔒

7.2. Data Format Implementation Vulnerabilities

so when you extend the syntax of a data format, it can create new vulnerabilities in the implementations that parse and process it 🐛 that's just the usual drama 🙄 no considerations are known for the IXDTF syntax that would raise concerns beyond the ordinary ✨

7.3. Operating with Inconsistent Data

the different parts of an IXDTF string can be inconsistent in interesting ways 👀 this can happen with the extensions defined here (see Section 3.4 for example) and with future extensions that haven't been defined yet 🔮 so where multiple actors need a consistent interpretation for security purposes (like when timestamps are embedded as parameters in access control information 🚪), only extensions with a well-understood and shared way of resolving that inconsistent data should be used 🫡

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 🫶

this spec builds on work from ECMA TC39, especially the Temporal proposal 🙌

Richard Gibson and Justin Grant gave editorial improvements ✏️ Mark McFadden and Bron Gondwana, the SEDATE WG Chairs (Bron also as CALEXT WG Chair), helped set up the structures needed to navigate the multi-SDO environment 🧭 John Klensin critically accompanied the development of this spec, which led to significant improvements 💜 and the authors would especially like to thank Francesca Palombini for her AD review and her overall guidance during development 👑

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
📦 where this page comes from