rfc9557.original		rfc9557.txt
	Serialising Extended Data About Times and Events U. Sharma		Internet Engineering Task Force (IETF) U. Sharma
	Internet-Draft Igalia, S.L.		Request for Comments: 9557 Igalia, S.L.
	Updates: 3339 (if approved) C. Bormann		Updates: 3339 C. Bormann
	Intended status: Standards Track Universität Bremen TZI		Category: Standards Track Universität Bremen TZI
	Expires: 25 April 2024 23 October 2023		ISSN: 2070-1721 March 2024
	Date and Time on the Internet: Timestamps with additional information		Date and Time on the Internet: Timestamps with Additional Information
	draft-ietf-sedate-datetime-extended-11
	Abstract		Abstract
	This document defines an extension to the timestamp format defined in		This document defines an extension to the timestamp format defined in
	RFC3339 for representing additional information including a time		RFC 3339 for representing additional information, including a time
	zone.		zone.
	It updates RFC3339 in the specific interpretation of the local offset		It updates RFC 3339 in the specific interpretation of the local
	Z, which is no longer understood to "imply that UTC is the preferred		offset Z, which is no longer understood to "imply that UTC is the
	reference point for the specified time"; see Section 2.		preferred reference point for the specified time".
	// (This "cref" paragraph will be removed by the RFC editor:) The
	// present version (-11) addresses comments received during IESG
	// review.
	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		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 25 April 2024.		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 Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Scope
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Definitions
	2. Updating RFC 3339 . . . . . . . . . . . . . . . . . . . . . . 7		2. Updating RFC 3339
	2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Background
	2.2. Update to RFC 3339 . . . . . . . . . . . . . . . . . . . 7		2.2. Update to RFC 3339
	2.3. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Notes
	3. Internet Extended Date/Time format (IXDTF) . . . . . . . . . 8		3. Internet Extended Date/Time Format (IXDTF)
	3.1. Format of Extended Information . . . . . . . . . . . . . 8		3.1. Format of Extended Information
	3.2. Registering Keys for Extended Information Tags . . . . . 9		3.2. Registering Keys for Extended Information Tags
	3.3. Optional Generation, Elective vs. Critical Consumption . 9		3.3. Optional Generation and Elective vs. Critical Consumption
	3.4. Inconsistent time-offset/Time-Zone Information . . . . . 11		3.4. Inconsistent time-offset and Time Zone Information
	4. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . . . 12		4. Syntax Extensions to RFC 3339
	4.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. ABNF
	4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14		4.2. Examples
	5. The u-ca Suffix Key: Calendar Awareness . . . . . . . . . . . 14		5. The u-ca Suffix Key: Calendar Awareness
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations
	7.1. Excessive Disclosure . . . . . . . . . . . . . . . . . . 16		7.1. Excessive Disclosure
	7.2. Data Format Implementation Vulnerabilities . . . . . . . 16		7.2. Data Format Implementation Vulnerabilities
	7.3. Operating with Inconsistent Data . . . . . . . . . . . . 16		7.3. Operating with Inconsistent Data
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 16		8.1. Normative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 17		8.2. Informative References
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19		Acknowledgements
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19		Contributors
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses
	1. Introduction		1. Introduction
	Dates and times are used in a very diverse set of internet		Dates and times are used in a very diverse set of Internet
	applications, all the way from server-side logging to calendaring and		applications, all the way from server-side logging to calendaring and
	scheduling.		scheduling.
	Each distinct instant in time can be represented in a descriptive		Each distinct instant in time can be represented in a descriptive
	text format using a timestamp. [ISO8601-1:2019] standardizes a		text format using a timestamp. [ISO8601-1:2019] standardizes a
	widely-adopted timestamp format, an earlier version of which		widely adopted timestamp format, an earlier version of which
	[ISO8601:1988] formed the basis of the Internet Date/Time Format		[ISO8601:1988] formed the basis of the Internet Date/Time Format
	[RFC3339]. However, this format allows timestamps to contain only		[RFC3339]. However, this format allows timestamps to contain very
	very little additional relevant information. Beyond that, any		little additional relevant information. Beyond that, any contextual
	contextual information related to a given timestamp needs to be		information related to a given timestamp needs to be either handled
	either handled separately or attached to it in a non-standard manner.		separately or attached to it in a non-standard manner.
	This is a pressing issue for applications that handle each such		This is a pressing issue for applications that handle each such
	instant in time with an associated time zone name, in order to take		instant in time with an associated time zone name in order to take
	into account events such as daylight saving time transitions. Many		into account events such as daylight saving time transitions. Many
	of these applications attach the time zone to the timestamp in a non-		of these applications attach the time zone to the timestamp in a non-
	standard format, at least one of which is fairly well-adopted		standard format, at least one of which is fairly well-adopted
	[JAVAZDT]. Furthermore, applications might want to attach even more		[JAVAZDT]. Furthermore, applications might want to attach even more
	information to the timestamp, including but not limited to the		information to the timestamp, including but not limited to the
	calendar system in which it should be represented.		calendar system in which it should be represented.
	1.1. Scope		1.1. Scope
	This document defines an extension syntax for timestamps as specified		This document defines an extension syntax for timestamps, as
	in [RFC3339] that has the following properties:		specified in [RFC3339], that has the following properties:
	* The extension suffix is completely optional, making existing		* The extension suffix is completely optional, making existing
	[RFC3339] timestamps compatible with this format.		timestamps [RFC3339] compatible with this format.
	* The format is compatible with the pre-existing popular syntax for		* The format is compatible with the pre-existing popular syntax for
	attaching time zone names to timestamps [JAVAZDT].		attaching time zone names to timestamps [JAVAZDT].
	* The format provides a generalized way to attach additional		* The format provides a generalized way to attach additional
	information to the timestamp.		information to the timestamp.
	We refer to this format as the Internet Extended Date/Time Format		We refer to this format as the Internet Extended Date/Time Format
	(IXDTF).		(IXDTF).
	This document does not address extensions to the format where the		This document does not address extensions to the format where the
	semantic result is no longer a fixed timestamp that is referenced to		semantic result is no longer a fixed timestamp that is referenced to
	a (past or future) UTC time. For instance, it does not address:		a (past or future) UTC time. For instance, it does not address:
	* Future time given as a local time in some specified time zone,		* future time given as a local time in some specified time zone,
	where changes to the definition of that time zone (such as a		where changes to the definition of that time zone (such as a
	political decision to enact or rescind daylight saving time)		political decision to enact or rescind daylight saving time)
	affect the instant in time represented by the timestamp.		affect the instant in time represented by the timestamp;
	* "Floating time", i.e., a local time without information describing		* "floating time", i.e., a local time without information describing
	the UTC offset or time zone in which it should be interpreted.		the UTC offset or time zone in which it should be interpreted; and
	* The use of timescales different from UTC, such as International		* the use of timescales different from UTC, such as International
	Atomic Time (TAI).		Atomic Time (TAI).
	However, additional information augmenting a fixed timestamp may be		However, additional information augmenting a fixed timestamp may be
	sufficient to detect an inconsistency between intention and the		sufficient to detect an inconsistency between the intention and the
	actual information in the timestamp, such as between the UTC offset		actual information in the timestamp, such as between the UTC offset
	and time zone name. For instance, inconsistencies might arise		and time zone name. For instance, inconsistencies might arise
	because of:		because of:
	* political decisions as discussed above, or		* political decisions, as discussed above,
	* updates to time zone definitions being applied at different times		* updates to time zone definitions being applied at different times
	by timestamp producers and receivers, or		by timestamp producers and receivers, or
	* errors in programs producing and consuming timestamps.		* errors in programs producing and consuming timestamps.
	While the information available in an IXDTF string is not generally		While the information available in an IXDTF string is not generally
	sufficient to resolve an inconsistency, it may be used to initiate		sufficient to resolve an inconsistency, it may be used to initiate
	some out of band processing to obtain sufficient information for such		some out-of-band processing to obtain sufficient information for such
	a resolution.		a resolution.
	In order to address some of the requirements implied here, future		In order to address some of the requirements implied here, related
	related specifications might define syntax and semantics of strings		specifications in the future might define syntax and semantics of
	similar to [RFC3339]. Note that the extension syntax defined in the		strings similar to those described in [RFC3339]. Note that the
	present document is designed in such a way that it can be useful for		extension syntax defined in the present document is designed in such
	such specifications as well.		a way that it can be useful for such specifications as well.
	1.2. Definitions		1.2. Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	UTC: Coordinated Universal Time, as maintained since 1988 by the		UTC: Coordinated Universal Time, as maintained since 1988 by the
	Bureau International des Poids et Mesures (BIPM) in conjunction		Bureau International des Poids et Mesures (BIPM) in conjunction
	with leap seconds as announced by the International Earth Rotation		with leap seconds, as announced by the International Earth
	and Reference Frames Service [IERS]. From 1972 through 1987, UTC		Rotation and Reference Systems Service [IERS]. From 1972 through
	was maintained entirely by Bureau International de l'Heure (BIH).		1987, UTC was maintained entirely by the Bureau International de
	Before 1972, UTC was not generally recognized and civil time was		l'Heure (BIH). Before 1972, UTC was not generally recognized, and
	determined by individual jurisdictions using different techniques		civil time was determined by individual jurisdictions using
	for attempting to follow Universal Time based on measuring the		different techniques for attempting to follow Universal Time based
	rotation of the earth.		on measuring the rotation of the earth.
	UTC is often mistakenly referred to as GMT, an earlier timescale		UTC is often mistakenly referred to as Greenwich Mean Time (GMT),
	for which UTC was designed to be a useful successor.		an earlier timescale for which UTC was designed to be a useful
			successor.
	ABNF: Augmented Backus-Naur Form, a format used to represent		ABNF: Augmented Backus-Naur Form, a format used to represent
	permissible strings in a protocol or language, as defined in		permissible strings in a protocol or language, as defined in
	[RFC5234]. The rules defined in Appendix B of [RFC5234] are		[RFC5234]. The rules defined in Appendix B of [RFC5234] are
	imported implicitly.		imported implicitly.
	Internet Extended Date/Time Format (IXDTF): The date/time format		IXDTF: Internet Extended Date/Time Format, the date/time format
	defined in Section 4 of this document.		defined in Section 4 of this document.
	Timestamp: An unambiguous representation of a particular instant in		Timestamp: An unambiguous representation of a particular instant in
	time.		time.
	UTC Offset: Difference between a given local time and UTC, usually		UTC Offset: Difference between a given local time and UTC, usually
	given in negative or positive hours and minutes. For example,		given in negative or positive hours and minutes. For example,
	local time in the city of New York, NY, USA, in the wintertime in		local time in the city of New York, NY, USA in the wintertime in
	2023, is 5 hours behind UTC, so its UTC offset is "-05:00".		2023 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		Z: A suffix which, when applied to a time, denotes a UTC offset of
	00:00; often spoken "Zulu" from the ICAO phonetic alphabet		00:00; often spoken "Zulu" from the ICAO phonetic alphabet
	representation of the letter "Z". (Definition from Section 2 of		representation of the letter "Z". (The definition is from
	[RFC3339]; see [ICAO-PA] for the phonetic alphabet.)		Section 2 of [RFC3339]; see [ICAO-PA] for the phonetic alphabet.)
	Time Zone: A set of rules representing the relationship of local		Time Zone: A set of rules representing the relationship of local
	time to UTC for a particular place or region. Mathematically, a		time to UTC for a particular place or region. Mathematically, a
	time zone can be thought of as a function that maps timestamps to		time zone can be thought of as a function that maps timestamps to
	UTC offsets. Time zones can deterministically convert a timestamp		UTC offsets. Time zones can deterministically convert a timestamp
	to local time. They can also be used in the reverse direction to		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		convert local time to a timestamp, with the caveat that some local
	times may have zero or multiple possible timestamps due to nearby		times may have zero or multiple possible timestamps due to nearby
	daylight saving time changes or other changes to the UTC offset of		daylight saving time changes or other changes to the UTC offset of
	that time zone. Unlike the UTC offset of a timestamp which makes		that time zone. Unlike the UTC offset of a timestamp, which makes
	no claims about the UTC offset of other related timestamps (and		no claims about the UTC offset of other related timestamps (and
	which is therefore unsuitable for performing local-time operations		which is therefore unsuitable for performing local-time
	such as "one day later"), a time zone also defines how to derive		operations, such as "one day later"), a time zone also defines how
	new timestamps based on differences in local time. For example,		to derive new timestamps based on differences in local time. For
	to calculate "one day later than this timestamp in San Francisco,		example, to calculate "one day later than this timestamp in San
	California", a time zone is required because the UTC offset of		Francisco, California", a time zone is required because the UTC
	local time in San Francisco can change from one day to the next.		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		IANA Time Zone: A named time zone that is included in the Time Zone
	Database (often called tz or zoneinfo) maintained by IANA		Database (often called tz or zoneinfo) maintained by IANA [TZDB]
	[TZDB][BCP175]. Most IANA time zones are named for the largest		[BCP175]. Most IANA time zones are named for the largest city in
	city in a particular region that shares the same time zone rules,		a particular region that shares the same time zone rules, e.g.,
	e.g., Europe/Paris or Asia/Tokyo [TZDB-NAMING].		Europe/Paris or Asia/Tokyo [TZDB-NAMING].
	The rules defined for a named IANA time zone can change over time.		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 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 rules that are current at the time of interpretation to apply;
	the additional information conveyed by using that time zone name		the additional information conveyed by using that time zone name
	is to change with any rule changes as recorded in the IANA time		is to change with any rule changes as recorded in the IANA time
	zone database.		zone database.
	Offset Time Zone: A time zone defined by a specific UTC offset, e.g.		Offset Time Zone: A time zone defined by a specific UTC offset,
	+08:45, and serialized using as its name the same numeric UTC		e.g., +08:45, and serialized using as its name the same numeric
	offset format used in an RFC 3339 timestamp, for example:		UTC offset format used in a timestamp as described in [RFC3339],
			for example:
	2022-07-08T00:14:07+08:45[+08:45]		2022-07-08T00:14:07+08:45[+08:45]
	An offset in the suffix that does not repeat the offset of the		An offset in the suffix that does not repeat the offset of the
	timestamp is inconsistent (see Section 3.4).		timestamp is inconsistent (see Section 3.4).
	Although serialization with offset time zones is supported in this		Although serialization with offset time zones is supported in this
	document for backwards compatibility with java.time.ZonedDateTime		document for backwards compatibility with java.time.ZonedDateTime
	[JAVAZDT], use of offset time zones is strongly discouraged. In		[JAVAZDT], use of offset time zones is strongly discouraged. In
	particular, programs MUST NOT copy the UTC offset from a timestamp		particular, programs MUST NOT copy the UTC offset from a timestamp
	into an offset time zone in order to satisfy another program which		into an offset time zone in order to satisfy another program that
	requires a time zone suffix in its input. Doing this will		requires a time zone suffix in its input. Doing this will
	improperly assert that the UTC offset of timestamps in that		improperly assert that the UTC offset of timestamps in that
	location will never change, which can result in incorrect		location will never change, which can result in incorrect
	calculations in programs that add, subtract, or otherwise derive		calculations in programs that add, subtract, or otherwise derive
	new timestamps from the one provided. For example, 2020-01-		new timestamps from the one provided. For example, 2020-01-
	01T00:00+01:00[Europe/Paris] will let programs add six months to		01T00:00+01:00[Europe/Paris] will let programs add six months to
	the timestamp while adjusting for Summer Time (daylight saving		the timestamp while adjusting for summer time (daylight saving
	time). But the same calculation applied to		time). However, the same calculation applied to
	2020-01-01T00:00+01:00[+01:00] will produce an incorrect result		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.		that will be off by one hour in the time zone Europe/Paris.
	CLDR: Common locale data repository [CLDR], a project of the Unicode		CLDR: Common Locale Data Repository [CLDR], a project of the Unicode
	Consortium to provide locale data to applications.		Consortium to provide locale data to applications.
	For more information about timescales, see Appendix E of [RFC1305],		For more information about timescales, see Appendix E of [RFC1305],
	Section 3 of [ISO8601:1988], and the appropriate ITU documents		Section 3 of [ISO8601:1988], and the appropriate ITU documents
	[ITU-R-TF.460-6].		[ITU-R-TF.460-6].
	2. Updating RFC 3339		2. Updating RFC 3339
	2.1. Background		2.1. Background
	Section 4.3 of [RFC3339] states that an offset given as Z or +00:00		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		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". 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".		time in UTC is known, but the offset to local time is unknown".
	This convention mirrors a similar convention for date/time		This convention mirrors a similar convention for date/time
	information in email headers, described in Section 3.3 of [RFC5322]		information in email headers that is described in Section 3.3 of
	and introduced earlier in Section 3.3 of [RFC2822]. This email		[RFC5322] and introduced earlier in Section 3.3 of [RFC2822]. This
	header convention is in actual use, while its adaptation into		email header convention is in actual use, while its adaptation into
	[RFC3339] was always compromised by the fact that [ISO8601:2000] and		[RFC3339] was always compromised by the fact that [ISO8601:2000] and
	later versions do not actually allow -00:00.		later versions do not actually allow -00:00.
	Implementations that needed to express the semantics of -00:00		Implementations that needed to express the semantics of -00:00
	therefore tended to use Z instead.		therefore tended to use Z instead.
	2.2. Update to RFC 3339		2.2. Update to RFC 3339
	This specification updates Section 4.3 of [RFC3339], aligning it with		This specification updates Section 4.3 of [RFC3339], aligning it with
	the actual practice of interpreting the offset Z to mean the same as-		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		-00:00: "the time in UTC is known, but the offset to local time is
	unknown".		unknown".
	Section 4.3 of [RFC3339] is revised to read as follows:		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		| 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		| unknown, this can be represented with an offset of "Z". (The
	| original version of this specification provided "-00:00" for this		| original version of this specification provided "-00:00" for this
	| purpose, which is not allowed by [ISO8601:2000] and therefore is		| purpose, which is not allowed by [ISO8601:2000] and therefore is
	| less interoperable; Section 3.3 of [RFC5322] describes a related		| less interoperable; Section 3.3 of [RFC5322] describes a related
	| convention for email which does not have this problem). This		| convention for email, which does not have this problem). This
	| differs semantically from an offset of "+00:00", which implies		| differs semantically from an offset of "+00:00", which implies
	| that UTC is the preferred reference point for the specified time.		| that UTC is the preferred reference point for the specified time.
	2.3. Notes		2.3. Notes
	Note that the semantics of the local offset +00:00 is not updated;		Note that the semantics of the local offset +00:00 is not updated;
	this retains the implication that UTC is the preferred reference		this retains the implication that UTC is the preferred reference
	point for the specified time.		point for the specified time.
	Note also that the fact that [ISO8601:2000] and later do not allow		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		-00:00 as a local offset reduces the level of interoperability that
	can be achieved in using this feature; the present specification		can be achieved in using this feature; however, the present
	however does not formally deprecate this syntax. With the update to		specification does not formally deprecate this syntax. With the
	RFC 3339, the local offset Z should now be used in its place.		update to [RFC3339], the local offset Z should now be used in its
			place.
	3. Internet Extended Date/Time format (IXDTF)		3. Internet Extended Date/Time Format (IXDTF)
	This section discusses desirable qualities of formats for the		This section discusses desirable qualities of formats for the
	timestamp extension suffix and defines the IXDTF format, which		timestamp extension suffix and defines the IXDTF format, which
	extends [RFC3339] for use in Internet protocols.		extends [RFC3339] for use in Internet protocols.
	3.1. Format of Extended Information		3.1. Format of Extended Information
	The format allows applications to specify additional important		The format allows applications to specify additional important
	information in addition to a bare [RFC3339] timestamp.		information in addition to a bare timestamp as described in
			[RFC3339].
	This is done by defining _tags_, each with a _key_ and a _value_		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		separated by an equals sign. The value of a tag can be one or more
	items delimited by hyphen/minus signs.		items delimited by hyphen/minus signs.
	Applications can build an informative timestamp _suffix_ using any		Applications can build an informative timestamp _suffix_ using any
	number of these tags.		number of these tags.
	Keys are lower-case only. Values are case-sensitive unless otherwise		Keys are lowercase only. Values are case-sensitive unless otherwise
	specified.		specified.
	See Section 3.3 for the handling of inconsistent information in a		See Section 3.3 for the handling of inconsistent information in a
	suffix.		suffix.
	3.2. Registering Keys for Extended Information Tags		3.2. Registering Keys for Extended Information Tags
	Suffix tag keys are registered by supplying the information specified		Suffix tag keys are registered by supplying the information specified
	in this section. This information is modeled after that specified		in this section. This information is modeled after that specified
	for the media type registry [RFC6838]; if in doubt, the provisions of		for the "Media Types" registry [RFC6838]; if in doubt, the provisions
	this registry should be applied analogously.		of this registry should be applied analogously.
	Key Identifier: The key (conforming to suffix-key in Section 4.1)		Key Identifier: The key (conforming to suffix-key in Section 4.1)
	Registration status: "Provisional" or "Permanent"		Registration Status: "Provisional" or "Permanent"
	Description: A very brief description of the key.		Description: A very brief description of the key
	Change controller: Who is in control of evolving the specification		Change Controller: Who is in control of evolving the specification
	governing values for this key. This information can include email		governing values for this key. This information can include email
	addresses of contact points and discussion lists, and references		addresses of contact points, discussion lists, and references to
	to relevant web pages (URLs).		relevant web pages (URLs).
	Reference: A reference. For permanent tag keys, this includes a		Reference: A reference. For permanent tag keys, this includes a
	full specification. For provisional tag keys, there is an		full specification. For provisional tag keys, there is an
	expectation that some information is available even if that does		expectation that some information is available even if that does
	not amount to a full specification; in this case, the registrant		not amount to a full specification; in this case, the registrant
	is expected to improve this information over time.		is expected to improve this information over time.
	Key names that start with an underscore are intended for experiments		Key names that start with an underscore are intended for experiments
	in controlled environments and cannot be registered; such keys MUST		in controlled environments and cannot be registered; such keys MUST
	NOT be used for interchange and MUST be rejected by implementations		NOT be used for interchange and MUST be rejected by implementations
	not specifically configured to take part in such an experiment. See		not specifically configured to take part in such an experiment. See
	[BCP178] for a discussion about the danger of experimental keys		[BCP178] for a discussion about the danger of experimental keys
	leaking out to general production and why that must be prevented.		leaking out to general production and why that must be prevented.
	3.3. Optional Generation, Elective vs. Critical Consumption		3.3. Optional Generation and Elective vs. Critical Consumption
	For the IXDTF format, suffix tags are always _optional_: They can be		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		added or left out as desired by the generator of the string. (An
	application might require the presence of specific suffix tags,		application might require the presence of specific suffix tags,
	though.)		though.)
	Without further indication, suffix tags are also _elective_: The		Without further indication, suffix tags are also _elective_. The
	recipient is free to ignore any suffix tag included in an IXDTF		recipient is free to ignore any suffix tag included in an IXDTF
	string. Reasons might include that the recipient does not implement		string. Reasons might include that the recipient does not implement
	(or know about) the specific suffix key, or that it does recognize		(or know about) the specific suffix key or that it does recognize the
	the key but cannot act on the value provided.		key but cannot act on the value provided.
	A suffix tag may also indicate that it is _critical_: The recipient		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		is advised that it MUST NOT act on the IXDTF string unless it can
	Format (IXDTF) string unless it can process the suffix tag as		process the suffix tag as specified. A critical suffix tag is
	specified. A critical suffix tag is indicated by following its		indicated by following its opening bracket with an exclamation mark
	opening bracket with an exclamation mark (see critical-flag in		(see critical-flag in Section 4.1).
	Section 4.1).
	For example, IXDTF strings such as:		For example, IXDTF strings such as:
	2022-07-08T00:14:07+01:00[Europe/Paris]		2022-07-08T00:14:07+01:00[Europe/Paris]
	are internally inconsistent (see Section 3.4), because 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		did not use a time zone offset of +01:00 in July 2022. However, the
	hint given in the suffix tag is elective, though, so the recipient is		time zone hint given in the suffix tag is elective, so the recipient
	not required to act on the inconsistency; it can treat the Internet		is not required to act on the inconsistency; it can treat the
	Date/Time Format string as if it were:		Internet Date/Time Format string as if it were:
	2022-07-08T00:14:07+01:00		2022-07-08T00:14:07+01:00
	| Note that as per Section 2 (see also Section 3.4), the IXDTF		| Note that, as per Section 2 (see also Section 3.4), the IXDTF
	| string:		| string:
	|		|
	| 2022-07-08T00:14:07Z[Europe/Paris]		| 2022-07-08T00:14:07Z[Europe/Paris]
	|		|
	| does not exhibit such an inconsistency, as the local offset of		| does not exhibit such an inconsistency, as the local offset of
	| Z does not imply a specific preferred time zone of		| Z does not imply a specific preferred time zone of
	| interpretation. Using the Time Zone Database rules for Europe/		| interpretation. Using the Time Zone Database rules for Europe/
	| Paris in the summer of 2022, it is equivalent to:		| Paris in the summer of 2022, it is equivalent to:
	|		|
	| 2022-07-08T02:14:07+02:00[Europe/Paris]		| 2022-07-08T02:14:07+02:00[Europe/Paris]
	skipping to change at page 11, line 4 ¶		skipping to change at line 428 ¶
	(assuming that the recipient does not understand the suffix key		(assuming that the recipient does not understand the suffix key
	knort).		knort).
	In contrast to this elective use of a suffix tag,		In contrast to this elective use of a suffix tag,
	2022-07-08T00:14:07+01:00[!Europe/Paris]		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[u-ca=chinese][!u-ca=japanese]		2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese]
	2022-07-08T00:14:07Z[!knort=blargel]		2022-07-08T00:14:07Z[!knort=blargel]
	each have an internal inconsistency or an unrecognized suffix key/		each have an internal inconsistency or an unrecognized suffix key/
	value that are marked as critical, so a recipient MUST treat these		value that is marked as critical, so a recipient MUST treat these
	IXDTF strings as erroneous. This means that the application MUST		IXDTF strings as erroneous. This means that the application MUST
	reject the data, or perform some other error handling, such as asking		reject the data or perform some other error handling, such as asking
	the user how to resolve the inconsistency (see Section 3.4).		the user how to resolve the inconsistency (see Section 3.4).
	Note that applications MAY also perform additional processing on		Note that applications MAY also perform additional processing on
	inconsistent or unrecognized elective suffix tags, such as asking the		inconsistent or unrecognized elective suffix tags, such as asking the
	user how to resolve the inconsistency. While they are not required		user how to resolve the inconsistency. While they are not required
	to do so with elective suffix tags, they are required to reject or		to do so with elective suffix tags, they are required to reject or
	perform some other error handling when encountering inconsistent or		perform some other error handling when encountering inconsistent or
	unrecognized suffix tags marked as critical.		unrecognized suffix tags marked as critical.
	An application that encounters duplicate use of a suffix key in		An application that encounters duplicate use of a suffix key in
	elective suffixes and does not want to perform additional processing		elective suffixes and does not want to perform additional processing
	on this inconsistency MUST choose the first suffix that has that key,		on this inconsistency MUST choose the first suffix that has that key,
	i.e.,		that is,
	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[u-ca=chinese]		2022-07-08T00:14:07Z[u-ca=chinese]
	are then treated the same.		are then treated the same.
	3.4. Inconsistent time-offset/Time-Zone Information		3.4. Inconsistent time-offset and Time Zone Information
	An RFC 3339 timestamp can contain a time-offset value that indicates		A timestamp as described in [RFC3339] can contain a time-offset value
	the offset between local time and UTC (see Section 4 of [RFC3339],		that indicates the offset between local time and UTC (see Section 4
	noting that Section 2 of the present specification updates		of [RFC3339], noting that Section 2 of the present specification
	Section 4.3 of [RFC3339]).		updates Section 4.3 of [RFC3339]).
	The information given in such a time-offset value can be inconsistent		The information given in such a time-offset value can be inconsistent
	with the information provided in a time zone suffix for an IXDTF		with the information provided in a time zone suffix for an IXDTF
	timestamp.		timestamp.
	For example, a calendar application could store an IXDTF string		For example, a calendar application could store an IXDTF string
	representing a far-future meeting in a particular time zone. If that		representing a far-future meeting in a particular time zone. If that
	time zone's definition is subsequently changed to abolish daylight		time zone's definition is subsequently changed to abolish daylight
	saving time, IXDTF strings that were originally consistent may now be		saving time, IXDTF strings that were originally consistent may now be
	inconsistent.		inconsistent.
	In case of inconsistent time-offset and time zone suffix, if the		In case of an inconsistent time-offset and time zone suffix, if the
	critical flag is used on the time zone suffix, an application MUST		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. If the critical flag is not used, it MAY
	act on the inconsistency. Acting on the inconsistency may involve		act on the inconsistency. Acting on the inconsistency may involve
	rejecting the timestamp, or resolving the inconsistency via		rejecting the timestamp or resolving the inconsistency via additional
	additional information such as user input and/or programmed behavior.		information, such as user input and/or programmed behavior.
	For example, the IXDTF timestamps in Figure 1 represent 00:14:07 UTC,		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,		indicating a local time with a time-offset of +00:00. However,
	because Europe/London used offset +01:00 in July 2022, the timestamps		because Europe/London used offset +01:00 in July 2022, the timestamps
	are inconsistent in Figure 1, where the first case is one where the		are inconsistent in Figure 1, where the first case is one where the
	application MUST act on the inconsistency (the time zone suffix is		application MUST act on the inconsistency (the time zone suffix is
	marked critical), and the second case is one where it MAY act on it		marked critical) and the second case is one where it MAY act on the
	(time zone suffix is elective).		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]
	2022-07-08T00:14:07+00:00[Europe/London]		2022-07-08T00:14:07+00:00[Europe/London]
	Figure 1: Inconsistent IXDTF timestamps		Figure 1: Inconsistent IXDTF Timestamps
	As per Section 4.3 of [RFC3339] as updated by Section 2, IXDTF		As per Section 4.3 of [RFC3339] as updated by Section 2, IXDTF
	timestamps may also forego indicating local time information in their		timestamps may also forego indicating local time information in the
	[RFC3339] part by using Z instead of a numeric time zone offset. The		part described by [RFC3339] by using Z instead of a numeric time zone
	IXDTF timestamps in Figure 2 (which represent the same instant in		offset. The IXDTF timestamps in Figure 2 (which represent the same
	time as the strings in Figure 1) are not inconsistent because they do		instant in time as the strings in Figure 1) are not inconsistent
	not assert any particular local time nor local offset in their		because they do not assert any particular local time nor local offset
	[RFC3339] part. Instead, applications that receive these strings can		in the part described by [RFC3339]. Instead, applications that
	calculate the local offset and local time using the rules of the time		receive these strings can calculate the local offset and local time
	zone suffix, such as Europe/London in the example in Figure 2, which		using the rules of the time zone suffix, such as Europe/London in the
	like Figure 1 has a case with a time zone suffix marked critical,		example in Figure 2, which like Figure 1 has a case with a time zone
	i.e., the intention is that the application must understand the time		suffix marked critical (i.e., the intention is that the application
	zone information, and one marked elective, which then only is		must understand the time zone information) and one marked elective,
	provided as additional information.		which then only is provided as additional information.
	2022-07-08T00:14:07Z[!Europe/London]		2022-07-08T00:14:07Z[!Europe/London]
	2022-07-08T00:14:07Z[Europe/London]		2022-07-08T00:14:07Z[Europe/London]
	Figure 2: No inconsistency in IXDTF timestamps		Figure 2: No Inconsistency in IXDTF Timestamps
	Note that -00:00 may be used instead of Z, because they have the same		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		meaning according to Section 2, but -00:00 is not allowed by
	[ISO8601:2000] and later so Z is preferred.		[ISO8601:2000] and later so Z is preferred.
	4. Syntax Extensions to RFC 3339		4. Syntax Extensions to RFC 3339
	4.1. ABNF		4.1. ABNF
	The following rules extend the ABNF syntax defined in [RFC3339] in		The following rules extend the ABNF syntax defined in [RFC3339] in
	order to allow the inclusion of an optional suffix.		order to allow the inclusion of an optional suffix.
	The Internet Extended Date/Time Format (IXDTF) is described by the		The Internet Extended Date/Time Format (IXDTF) is described by the
	rule date-time-ext.		rule date-time-ext.
	date-time and time-numoffset are imported from Section 5.6 of		date-time and time-numoffset are imported from Section 5.6 of
	[RFC3339], ALPHA and DIGIT from Appendix B.1 of [RFC5234].		[RFC3339], and ALPHA and DIGIT are imported from Appendix B.1 of
			[RFC5234].
	time-zone-initial = ALPHA / "." / "_"		time-zone-initial = ALPHA / "." / "_"
	time-zone-char = time-zone-initial / DIGIT / "-" / "+"		time-zone-char = time-zone-initial / DIGIT / "-" / "+"
	time-zone-part = time-zone-initial *time-zone-char		time-zone-part = time-zone-initial *time-zone-char
	; but not "." or ".."		; but not "." or ".."
	time-zone-name = time-zone-part *("/" time-zone-part)		time-zone-name = time-zone-part *("/" time-zone-part)
	time-zone = "[" critical-flag		time-zone = "[" critical-flag
	time-zone-name / time-numoffset "]"		time-zone-name / time-numoffset "]"
	key-initial = lcalpha / "_"		key-initial = lcalpha / "_"
	skipping to change at page 13, line 30 ¶		skipping to change at line 551 ¶
	suffix-key "=" suffix-values "]"		suffix-key "=" suffix-values "]"
	suffix = [time-zone] *suffix-tag		suffix = [time-zone] *suffix-tag
	date-time-ext = date-time suffix		date-time-ext = date-time suffix
	critical-flag = [ "!" ]		critical-flag = [ "!" ]
	alphanum = ALPHA / DIGIT		alphanum = ALPHA / DIGIT
	lcalpha = %x61-7A		lcalpha = %x61-7A
	Figure 3: ABNF grammar of extensions to RFC 3339		Figure 3: ABNF Grammar of Extensions to RFC 3339
	Note that a time-zone is syntactically similar to a suffix-tag, but		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		does not include an equals sign. This special case is only available
	for time zone tags.		for time zone tags.
	The ABNF definition of time-zone-part matches "." and "..", which		The ABNF definition of time-zone-part matches "." and "..", which
	however both are explicitly excluded (see also comment on time-zone-		both are explicitly excluded (see the note below on time-zone-part).
	part).
	time-zone-name is intended to be the name of an IANA Time Zone. As		time-zone-name is intended to be the name of an IANA Time Zone. As a
	generator and recipient may be using different revisions of the Time		generator and recipient may be using different revisions of the Time
	Zone Database, recipients may not be aware of such an IANA Time Zone		Zone Database, recipients may not be aware of such an IANA Time Zone
	name and should treat such a situation as any other inconsistency.		name and should treat such a situation as any other inconsistency.
	| Note: At the time of writing, the length of each time-zone-part		| 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		| is limited to a maximum of 14 characters by the rules in
	| [TZDB-NAMING]. One platform is known to enforce this limit, an		| [TZDB-NAMING]. One platform is known to enforce this limit,
	| entry in a timezone database on another platform is known to		| and an entry in a time zone database on another platform is
	| exceed this limit. As the time-zone-name will ultimately have		| known to exceed this limit. As the time-zone-name will
	| to be looked up in the database, which therefore has control		| ultimately have to be looked up in the database, which
	| over the length, the time-zone-part production in Figure 3 is		| therefore has control over the length, the time-zone-part
	| deliberately permissive.		| production in Figure 3 is deliberately permissive.
	4.2. Examples		4.2. Examples
	Here are some examples of Internet Extended Date/Time Format (IXDTF).		This section contains some examples of Internet Extended Date/Time
			Format (IXDTF).
	1996-12-19T16:39:57-08:00		1996-12-19T16:39:57-08:00
	Figure 4: RFC 3339 date-time with time zone offset		Figure 4: date-time per RFC 3339 with Time Zone Offset
	Figure 4 represents 39 minutes and 57 seconds after the 16th hour of		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		December 19, 1996, with an offset of -08:00 from UTC. Note that this
	this is the same instant in time as 1996-12-20T00:39:57Z, expressed		is the same instant in time as 1996-12-20T00:39:57Z, expressed in
	in UTC.		UTC.
	1996-12-19T16:39:57-08:00[America/Los_Angeles]		1996-12-19T16:39:57-08:00[America/Los_Angeles]
	Figure 5: Adding a time zone name		Figure 5: Adding a Time Zone Name
	Figure 5 represents the exact same instant in time as the previous		Figure 5 represents the exact same instant in time as the previous
	example but additionally specifies the human time zone associated		example but additionally specifies the human time zone associated
	with it ("Pacific Time") for time-zone-aware applications to take		with it ("Pacific Time") for time-zone-aware applications to take
	into account.		into account.
	1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]		1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
	Figure 6: Projecting to the Hebrew calendar		Figure 6: Projecting to the Hebrew Calendar
	Figure 6 represents the exact same instant in time, but it informs		Figure 6 represents the exact same instant in time, but it informs
	calendar-aware applications (see Section 5) that they should project		calendar-aware applications (see Section 5) that they should project
	it to the Hebrew calendar.		it to the Hebrew calendar.
	1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]		1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]
	Figure 7: Adding experimental tags		Figure 7: Adding Experimental Tags
	Figure 7, based on Figure 4, utilizes keys identified as experimental		Figure 7, based on Figure 4, utilizes keys identified as experimental
	by a leading underscore to declare two additional pieces of		by a leading underscore to declare two additional pieces of
	information in the suffix; these can be interpreted by		information in the suffix; these can be interpreted by
	implementations that take part in the controlled experiment making		implementations that take part in the controlled experiment making
	use of these tag keys.		use of these tag keys.
	5. The u-ca Suffix Key: Calendar Awareness		5. The u-ca Suffix Key: Calendar Awareness
	Out of the possible suffix keys, the suffix key u-ca is allocated to		Out of the possible suffix keys, the suffix key u-ca is allocated to
	skipping to change at page 15, line 10 ¶		skipping to change at line 629 ¶
	A calendar is a set of rules defining how dates are counted and		A calendar is a set of rules defining how dates are counted and
	consumed by implementations. The set of suffix values allowed for		consumed by implementations. The set of suffix values allowed for
	this suffix key is the set of values defined for the Unicode Calendar		this suffix key is the set of values defined for the Unicode Calendar
	Identifier [TR35]. A resource that has been built to provide links		Identifier [TR35]. A resource that has been built to provide links
	into the most recent stable and development [CLDR] information about		into the most recent stable and development [CLDR] information about
	that is provided by [CLDR-LINKS].		that is provided by [CLDR-LINKS].
	6. IANA Considerations		6. IANA Considerations
	// RFC Editor: please replace RFCthis with the RFC number of this RFC		IANA has created a registry called "Timestamp Suffix Tag Keys" in a
	// and remove this note.		new registry group titled "Internet Date/Time Format". Each entry in
			the registry shall consist of the information described in
	IANA is requested to establish a registry called "Timestamp Suffix		Section 3.2. The initial contents of the registry are specified in
	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.		Table 1.
	+============+==============+==============+============+=========+		+============+==============+==============+============+=========+
	| Key | Registration | Description: | Change |Reference|		| Key | Registration | Description | Change |Reference|
	| Identifier | status | | controller | |		| Identifier | Status | | Controller | |
	+============+==============+==============+============+=========+		+============+==============+==============+============+=========+
	| u-ca | Permanent | Preferred | IESG |Section 5|		| u-ca | Permanent | Preferred | IETF |Section 5|
	| | | Calendar for | |of |		| | | Calendar for | |of RFC |
	| | | Presentation | |RFCthis |		| | | Presentation | |9557 |
	+------------+--------------+--------------+------------+---------+		+------------+--------------+--------------+------------+---------+
	Table 1: Initial Content of Timestamp Suffix Tag Keys registry		Table 1: Initial Contents of Timestamp Suffix Tag Keys Registry
	The registration policy [BCP26] is "Specification Required" for		The registration policy [BCP26] is "Specification Required" for
	permanent entries, and "Expert Review" for provisional ones. In the		permanent entries and "Expert Review" for provisional ones. In the
	second case, the expert is instructed to ascertain that a basic		second case, the experts are instructed to ascertain that a basic
	specification does exist, even if not complete or published yet.		specification does exist, even if not complete or published yet.
	The experts also are instructed to be frugal in the allocation of key		The experts are also instructed to be frugal in the allocation of key
	identifiers that are suggestive of generally applicable semantics,		identifiers that are suggestive of generally applicable semantics,
	keeping them in reserve for suffix keys that are likely to enjoy wide		keeping them in reserve for suffix keys that are likely to enjoy wide
	use and can make good use of the key identifier's conciseness. If		use and can make good use of the key identifier's conciseness. If
	the experts become aware of key identifiers that are deployed and in		the experts become aware of key identifiers that are deployed and in
	use, they may also initiate a registration on their own if they deem		use, they may also initiate a registration on their own if they deem
	such a registration can avert potential future collisions.		such a registration can avert potential future collisions.
	7. Security Considerations		7. Security Considerations
	7.1. Excessive Disclosure		7.1. Excessive Disclosure
	The ability to include various pieces of ancillary information with a		The ability to include various pieces of ancillary information with a
	timestamp might lead to excessive disclosure. An example for		timestamp might lead to excessive disclosure. An example for
	possibly excessive disclosure is given in Section 7 of [RFC3339].		possibly excessive disclosure is given in Section 7 of [RFC3339].
	Similarly, divulging information about the calendar system or the		Similarly, divulging information about the calendar system or the
	language of choice may provide more information about the originator		language of choice may provide more information about the originator
	of a timestamp than the data minimization principle would permit		of a timestamp than the data minimization principle would permit
	[DATA-MINIMIZATION]. More generally speaking, generators of IXDTF		[DATA-MINIMIZATION]. More generally speaking, generators of IXDTF
	timestamps need to consider whether information to be added to the		timestamps need to consider whether information to be added to the
	timestamp is appropriate to divulge to the recipients of this		timestamp is appropriate to divulge to the recipients of this
	information, and need to err on the side of minimizing such		information and need to err on the side of minimizing such disclosure
	disclosure if the set of recipients is not under control of the		if the set of recipients is not under control of the originator.
	originator.
	7.2. Data Format Implementation Vulnerabilities		7.2. Data Format Implementation Vulnerabilities
	As usual when extending the syntax of a data format, this can lead to		As usual when extending the syntax of a data format, this can lead to
	new vulnerabilities in implementations parsing and processing the		new vulnerabilities in implementations parsing and processing the
	format. No considerations are known for the IXDTF syntax that would		format. No considerations are known for the IXDTF syntax that would
	pose concerns that are out of the ordinary.		pose concerns that are out of the ordinary.
	7.3. Operating with Inconsistent Data		7.3. Operating with Inconsistent Data
	Information provided in the various parts of an IXDTF string may be		Information provided in the various parts of an IXDTF string may be
	inconsistent in interesting ways, both with the extensions defined in		inconsistent in interesting ways, both with the extensions defined in
	this specification (see for instance Section 3.4) and with future		this specification (for instance, see Section 3.4) and with future
	extensions still to be defined. Where consistent interpretation		extensions still to be defined. Where consistent interpretation
	between multiple actors is required for security purposes (e.g.,		between multiple actors is required for security purposes (e.g.,
	where timestamps are embedded as parameters in access control		where timestamps are embedded as parameters in access control
	information), only those extensions can be employed that have a well-		information), only extensions that have a well-understood and shared
	understood and shared resolution of such inconsistent data.		resolution of such inconsistent data can be employed.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[BCP175] Lear, E. and P. Eggert, "Procedures for Maintaining the		[BCP175] Best Current Practice 175,
			<https://www.rfc-editor.org/info/bcp175>.
			At the time of writing, this BCP comprises the following:
			Lear, E. and P. Eggert, "Procedures for Maintaining the
	Time Zone Database", BCP 175, RFC 6557,		Time Zone Database", BCP 175, RFC 6557,
	DOI 10.17487/RFC6557, February 2012,		DOI 10.17487/RFC6557, February 2012,
	<https://www.rfc-editor.org/rfc/rfc6557>.		<https://www.rfc-editor.org/info/rfc6557>.
	[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,		[BCP178] Best Current Practice 178,
			<https://www.rfc-editor.org/info/bcp178>.
			At the time of writing, this BCP comprises the following:
			Saint-Andre, P., Crocker, D., and M. Nottingham,
	"Deprecating the "X-" Prefix and Similar Constructs in		"Deprecating the "X-" Prefix and Similar Constructs in
	Application Protocols", BCP 178, RFC 6648,		Application Protocols", BCP 178, RFC 6648,
	DOI 10.17487/RFC6648, June 2012,		DOI 10.17487/RFC6648, June 2012,
	<https://www.rfc-editor.org/rfc/rfc6648>.		<https://www.rfc-editor.org/info/rfc6648>.
	[BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[BCP26] Best Current Practice 26,
			<https://www.rfc-editor.org/info/bcp26>.
			At the time of writing, this BCP comprises the following:
			Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/rfc/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<https://www.rfc-editor.org/rfc/rfc3339>.		<https://www.rfc-editor.org/info/rfc3339>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/rfc/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<https://www.rfc-editor.org/rfc/rfc6838>.		<https://www.rfc-editor.org/info/rfc6838>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		8.2. Informative References
	[CLDR] "Unicode CLDR Project", <https://cldr.unicode.org>.		[CLDR] Unicode CLDR, "Unicode CLDR Project",
			<https://cldr.unicode.org>.
	[CLDR-LINKS]		[CLDR-LINKS]
	Unicode CLDR, "Stable Links Info",		Unicode CLDR, "Stable Links Info",
	<https://cldr.unicode.org/stable-links-info>.		<https://cldr.unicode.org/stable-links-info>.
	[DATA-MINIMIZATION]		[DATA-MINIMIZATION]
	Arkko, J., "Emphasizing data minimization among protocol		Arkko, J., "Emphasizing data minimization among protocol
	participants", Work in Progress, Internet-Draft, draft-		participants", Work in Progress, Internet-Draft, draft-
	arkko-iab-data-minimization-principle-05, 10 July 2023,		arkko-iab-data-minimization-principle-05, 10 July 2023,
	<https://datatracker.ietf.org/doc/html/draft-arkko-iab-		<https://datatracker.ietf.org/doc/html/draft-arkko-iab-
	data-minimization-principle-05>.		data-minimization-principle-05>.
	[ICAO-PA] International Civil Aviation Organization, "Annex 10 to		[ICAO-PA] International Civil Aviation Organization, "Annex 10 to
	the Convention on International Civil Aviation:		the Convention on International Civil Aviation:
	Aeronautical Telecommunications; Volume II Communication		Aeronautical Telecommunications; Volume II Communication
	Procedures including those with PANS status (7th ed.)",		Procedures including those with PANS status", 7th ed.,
	July 2016, <https://store.icao.int/annex-10-aeronautical-		July 2016, <https://store.icao.int/annex-10-aeronautical-
	telecommunications-volume-ii-communication-procedures-		telecommunications-volume-ii-communication-procedures-
	including-those-with-pans-status>.		including-those-with-pans-status>.
	[IERS] "International Earth Rotation Service Bulletins",		[IERS] IERS, "International Earth Rotation Service Bulletins",
	<https://www.iers.org/IERS/EN/Publications/Bulletins/		<https://www.iers.org/IERS/EN/Publications/Bulletins/
	bulletins.html>.		bulletins.html>.
	[ISO8601-1:2019]		[ISO8601-1:2019]
	ISO, "Date and time — Representations for information		ISO, "Date and time - Representations for information
	interchange — Part 1: Basic rules", ISO 8601-1:2019,		interchange - Part 1: Basic rules", ISO 8601-1:2019,
	February 2019, <https://www.iso.org/standard/70907.html>.		February 2019, <https://www.iso.org/standard/70907.html>.
	[ISO8601:1988]		[ISO8601:1988]
	ISO, "Data elements and interchange formats — Information		ISO, "Data elements and interchange formats - Information
	interchange — Representation of dates and times",		interchange - Representation of dates and times",
	ISO 8601:1988, June 1988,		ISO 8601:1988, June 1988,
	<https://www.iso.org/standard/15903.html>. Also available		<https://www.iso.org/standard/15903.html>. Also available
	from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/		from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/
	fipspub4-1-1991.pdf		fipspub4-1-1991.pdf>.
	(https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/
	fipspub4-1-1991.pdf)>.
	[ISO8601:2000]		[ISO8601:2000]
	ISO, "Data elements and interchange formats — Information		ISO, "Data elements and interchange formats - Information
	interchange — Representation of dates and times",		interchange - Representation of dates and times",
	ISO 8601:2000, December 2000,		ISO 8601:2000, December 2000,
	<https://www.iso.org/standard/26780.html>.		<https://www.iso.org/standard/26780.html>.
	[ITU-R-TF.460-6]		[ITU-R-TF.460-6]
	"ITU-R TF.460-6. Standard-frequency and time-signal		ITU-R, "Standard-frequency and time-signal emissions",
	emissions", February 2002,		ITU-R Recommendation TF.460-6, February 2002,
	<https://www.itu.int/rec/R-REC-TF.460/en>.		<https://www.itu.int/rec/R-REC-TF.460/en>.
	[JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter:		[JAVAZDT] Oracle, "Class DateTimeFormatter: ISO_ZONED_DATE_TIME",
	ISO_ZONED_DATE_TIME",
	<https://docs.oracle.com/javase/8/docs/api/java/time/		<https://docs.oracle.com/javase/8/docs/api/java/time/
	format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.		format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation and Analysis", RFC 1305,		Specification, Implementation and Analysis", RFC 1305,
	DOI 10.17487/RFC1305, March 1992,		DOI 10.17487/RFC1305, March 1992,
	<https://www.rfc-editor.org/rfc/rfc1305>.		<https://www.rfc-editor.org/info/rfc1305>.
	[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,		[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
	DOI 10.17487/RFC2822, April 2001,		DOI 10.17487/RFC2822, April 2001,
	<https://www.rfc-editor.org/rfc/rfc2822>.		<https://www.rfc-editor.org/info/rfc2822>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<https://www.rfc-editor.org/rfc/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
	[TR35] "Unicode Technical Standard #35: Unicode Locale Data		[TR35] Davis, M., Ed., "Unicode Technical Standard #35: Unicode
	Markup Language (LDML)", <https://www.unicode.org/reports/		Locale Data Markup Language (LDML)",
			<https://www.unicode.org/reports/
	tr35/#UnicodeCalendarIdentifier>.		tr35/#UnicodeCalendarIdentifier>.
	[TZDB] "Sources for time zone and daylight saving time data",		[TZDB] IANA, "Time zone and daylight saving time data",
	<https://data.iana.org/time-zones/tz-link.html>.		<https://data.iana.org/time-zones/tz-link.html>.
	[TZDB-NAMING]		[TZDB-NAMING]
	"Theory and pragmatics of the tz code and data",		IANA, "Theory and pragmatics of the tz code and data",
	<https://data.iana.org/time-zones/theory.html>.		<https://data.iana.org/time-zones/theory.html>.
	Acknowledgements		Acknowledgements
			This specification benefits from work prepared by ECMA TC39,
			specifically in the Temporal proposal.
	Richard Gibson and Justin Grant provided editorial improvements. The		Richard Gibson and Justin Grant provided editorial improvements. The
	authors would like to thank Francesca Palombini for her AD review.		SEDATE WG Chairs Mark McFadden and Bron Gondwana, the latter also in
			his role as CALEXT WG Chair, helped set up the structures needed to
			navigate the multi-SDO environment. John Klensin critically
			accompanied the development of this specification, which led to
			significant improvements. The authors would also like to especially
			thank Francesca Palombini for her AD review and for her overall
			guidance during the development process.
	Contributors		Contributors
	Justin Grant		Justin Grant
	Email: justingrant.ietf.public@gmail.com		Email: justingrant.ietf.public@gmail.com
	Authors' Addresses		Authors' Addresses
	Ujjwal Sharma		Ujjwal Sharma
	Igalia, S.L.		Igalia, S.L.
End of changes. 121 change blocks.
	278 lines changed or deleted		276 lines changed or added
This html diff was produced by rfcdiff 1.48.