rfc9557.original.xml		rfc9557.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.2.2 ) -->		<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.2.2 ) -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<?rfc subcompact="no"?>		-ietf-sedate-datetime-extended-11" number="9557" submissionType="IETF" category=
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		"std" consensus="true" xml:lang="en" updates="3339" obsoletes="" tocDepth="4" to
	-ietf-sedate-datetime-extended-11" category="std" consensus="true" submissionTyp		cInclude="true" sortRefs="true" symRefs="true" version="3">
	e="IETF" xml:lang="en" updates="3339" tocDepth="4" sortRefs="true" symRefs="true
	" version="3">
	<!-- xml2rfc v2v3 conversion 3.18.1 -->		<!-- xml2rfc v2v3 conversion 3.18.1 -->
	<front>		<front>
	<title abbrev="Internet Extended Date/Time Fmt (IXDTF)">Date and Time on the		<title abbrev="Internet Extended Date/Time Format (IXDTF)">Date and Time on
	Internet: Timestamps with additional information</title>		the Internet: Timestamps with Additional Information</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-sedate-datetime-extended		<seriesInfo name="RFC" value="9557"/>
	-11"/>
	<author initials="U." surname="Sharma" fullname="Ujjwal Sharma">		<author initials="U." surname="Sharma" fullname="Ujjwal Sharma">
	<organization>Igalia, S.L.</organization>		<organization>Igalia, S.L.</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Bugallal Marchesi, 22, 1º</street>		<street>Bugallal Marchesi, 22, 1º</street>
	<city>A Coruña</city>		<city>A Coruña</city>
	<code>15008</code>		<code>15008</code>
	<country>Spain</country>		<country>Spain</country>
	</postal>		</postal>
	<email>ryzokuken@igalia.com</email>		<email>ryzokuken@igalia.com</email>
	skipping to change at line 43 ¶		skipping to change at line 42 ¶
	<postal>		<postal>
	<street>Postfach 330440</street>		<street>Postfach 330440</street>
	<city>Bremen</city>		<city>Bremen</city>
	<code>D-28359</code>		<code>D-28359</code>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<phone>+49-421-218-63921</phone>		<phone>+49-421-218-63921</phone>
	<email>cabo@tzi.org</email>		<email>cabo@tzi.org</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="October" day="23"/>		<date year="2024" month="March"/>
	<workgroup>Serialising Extended Data About Times and Events</workgroup>		<area>art</area>
			<workgroup>sedate</workgroup>
			<keyword>Gregorian calendar</keyword>
			<keyword>Calendar awareness</keyword>
			<keyword>Time zone</keyword>
			<keyword>ISO 8601</keyword>
			<keyword>Temporal</keyword>
			<keyword>RFC 3339</keyword>
			<keyword>Extension</keyword>
			<keyword>Internet Extended Date/Time Format</keyword>
			<keyword>IXDTF</keyword>
	<abstract>		<abstract>
	<?line 158?>
	<t>This document defines an extension to the timestamp format defined in		<t>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.</t>		zone.</t>
	<t>It updates RFC3339 in the specific interpretation of the local offset		<t>It updates RFC 3339 in the specific interpretation of the local offset
	<tt>Z</tt>, which is no longer understood to "imply that UTC is the preferred		<tt>Z</tt>, which is no longer understood to "imply that UTC is the preferred
	reference point for the specified time"; see <xref target="update"/>.</t>		reference point for the specified time".</t>
	<t><cref anchor="status">(This "cref" paragraph will be removed by the RFC
	editor:)<br/>
	The present version (-11) addresses comments received during IESG review.</cref>
	</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Serialising Extended Data About Times and Events (SEDATE) Working Group
	mailing list (<eref target="mailto:sedate@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/sedate/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/sedate/
	"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-wg-sedate/draft-ietf-sedate-dateti
	me-extended"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<?line 175?>
	<section anchor="intro">		<section anchor="intro">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Dates and times are used in a very diverse set of internet		<t>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.</t>		scheduling.</t>
	<t>Each distinct instant in time can be represented in a descriptive text		<t>Each distinct instant in time can be represented in a descriptive text
	format using a timestamp.		format using a timestamp.
	<xref target="ISO8601-2019"/> standardizes a widely-adopted		<xref target="ISO8601-2019"/> standardizes a widely adopted
	timestamp format, an earlier version of which <xref target="ISO8601"/> formed th e		timestamp format, an earlier version of which <xref target="ISO8601"/> formed th e
	basis of the Internet Date/Time Format <xref target="RFC3339"/>.		basis of the Internet Date/Time Format <xref target="RFC3339"/>.
	However, this format allows timestamps to contain only very little		However, this format allows timestamps to contain very little
	additional relevant information.		additional relevant information.
	Beyond that, any contextual		Beyond that, any contextual
	information related to a given timestamp needs to be either handled		information related to a given timestamp needs to be either handled
	separately or attached to it in a non-standard manner.</t>		separately or attached to it in a non-standard manner.</t>
	<t>This is a pressing issue for applications that handle each		<t>This is a pressing issue for applications that handle each
	such instant in time with an associated time zone name, in order to take into ac count events		such instant in time with an associated time zone name in order to take into acc ount events
	such as daylight saving time transitions.		such as daylight saving time transitions.
	Many of these applications attach the time zone to the timestamp in a		Many of these applications attach the time zone to the timestamp in a
	non-standard format, at least one of which is fairly well-adopted <xref target=" JAVAZDT"/>.		non-standard format, at least one of which is fairly well-adopted <xref target=" JAVAZDT"/>.
	Furthermore, applications might want to attach even more information to the		Furthermore, applications might want to attach even more information to the
	timestamp, including but not limited to the calendar system in which		timestamp, including but not limited to the calendar system in which
	it should be represented.</t>		it should be represented.</t>
			<t>This document defines an extension to the timestamp format defined in
			<xref target="RFC3339"/> for representing additional information, including a
			time
			zone.</t>
			<t>It updates <xref target="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 <xref target="update"/>8.</t>
	<section anchor="scope">		<section anchor="scope">
	<name>Scope</name>		<name>Scope</name>
	<t>This document defines an extension syntax for timestamps as specified		<t><xref target="RFC3339"/> defines a syntax for timestamps to represent
	in <xref target="RFC3339"/> that has the following properties:</t>		date and time in the Internet. For this, the present document defines an exten
			sion syntax that achieves the following properties:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>The extension suffix is completely optional, making existing		<t>The extension suffix is completely optional, making existing
	<xref target="RFC3339"/> timestamps compatible with this format.</t>		<xref target="RFC3339"/> timestamps compatible with this format.</t>
	</li>		</li>
	<li>		<li>
	<t>The format is compatible with the pre-existing popular syntax for attaching		<t>The format is compatible with the pre-existing popular syntax for attaching
	time zone names to timestamps <xref target="JAVAZDT"/>.</t>		time zone names to timestamps <xref target="JAVAZDT"/>.</t>
	</li>		</li>
	<li>		<li>
	skipping to change at line 123 ¶		skipping to change at line 118 ¶
	information to the timestamp.</t>		information to the timestamp.</t>
	</li>		</li>
	</ul>		</ul>
	<t>We refer to this format as the Internet Extended Date/Time Format (IX DTF).</t>		<t>We refer to this format as the Internet Extended Date/Time Format (IX DTF).</t>
	<t>This document does not address extensions to the format where the		<t>This document does not address extensions to the format where the
	semantic result is no longer a fixed timestamp that is referenced to a		semantic result is no longer a fixed timestamp that is referenced to a
	(past or future) UTC time.		(past or future) UTC time.
	For instance, it does not address:</t>		For instance, it does not address:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Future time given as a local time in some specified time zone, wh ere		<t>future time given as a local time in some specified time zone, wh ere
	changes to the definition of that time zone (such as a political		changes to the definition of that time zone (such as a political
	decision to enact or rescind daylight saving time) affect the		decision to enact or rescind daylight saving time) affect the
	instant in time represented by the timestamp.</t>		instant in time represented by the timestamp;</t>
	</li>		</li>
	<li>		<li>
	<t>"Floating time", i.e., a local time without information describin		<t>"floating time", i.e., a local time without information describin
	g		g
	the UTC offset or time zone in which it should be interpreted.</t>		the UTC offset or time zone in which it should be interpreted; and</t>
	</li>		</li>
	<li>		<li>
	<t>The use of timescales different from UTC, such as International A tomic		<t>the use of timescales different from UTC, such as International A tomic
	Time (TAI).</t>		Time (TAI).</t>
	</li>		</li>
	</ul>		</ul>
	<t>However, additional information augmenting a fixed timestamp may be		<t>However, additional information augmenting a fixed timestamp may be
	sufficient to detect an inconsistency between intention and the actual		sufficient to detect an inconsistency between the intention and the actual
	information in the timestamp, such as between the UTC offset and time zone		information in the timestamp, such as between the UTC offset and time zone
	name.		name.
	For instance, inconsistencies might arise because of:</t>		For instance, inconsistencies might arise because of:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>political decisions as discussed above, or</t>		<t>political decisions, as discussed above,</t>
	</li>		</li>
	<li>		<li>
	<t>updates to time zone definitions being applied at different times		<t>updates to time zone definitions being applied at different times
	by timestamp producers and receivers, or</t>		by timestamp producers and receivers, or</t>
	</li>		</li>
	<li>		<li>
	<t>errors in programs producing and consuming timestamps.</t>		<t>errors in programs producing and consuming timestamps.</t>
	</li>		</li>
	</ul>		</ul>
	<t>While the information available in an IXDTF string is not generally s ufficient to resolve		<t>While the information available in an IXDTF string is not generally s ufficient to resolve
	an inconsistency, it may be used to initiate some out of band		an inconsistency, it may be used to initiate some out-of-band
	processing to obtain sufficient information for such a resolution.</t>		processing to obtain sufficient information for such a resolution.</t>
	<t>In order to address some of the requirements implied here, future		<t>In order to address some of the requirements implied here,
	related specifications might define syntax and semantics of strings		related specifications in the future might define syntax and semantics of string
	similar to <xref target="RFC3339"/>.		s
			similar to those described in <xref target="RFC3339"/>.
	Note that the extension syntax defined in the present document is		Note that the extension syntax defined in the present document is
	designed in such a way that it can be useful for such specifications		designed in such a way that it can be useful for such specifications
	as well.</t>		as well.</t>
	</section>		</section>
	<section anchor="definitions">		<section anchor="definitions">
	<name>Definitions</name>		<name>Definitions</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp		<t>
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		be interpreted as
	only when, they		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>		when, and only when, they appear in all capitals, as shown here.
	<?line -18?>		</t>
	<dl>		<dl>
	<dt>UTC:</dt>		<dt>UTC:</dt>
	<dd>		<dd>
	<t>Coordinated Universal Time, as maintained since 1988 by the Burea u		<t>Coordinated Universal Time, as maintained since 1988 by the Burea u
	International des Poids et Mesures (BIPM) in conjunction with leap		International des Poids et Mesures (BIPM) in conjunction with leap
	seconds as announced by the International Earth Rotation and		seconds, as announced by the International Earth Rotation and
	Reference Frames Service <xref target="IERS"/>.		Reference Systems Service <xref target="IERS"/>.
	From 1972 through 1987, UTC was maintained entirely by Bureau		From 1972 through 1987, UTC was maintained entirely by the Bureau
	International de l'Heure (BIH).		International de l'Heure (BIH).
	Before 1972, UTC was not generally recognized and civil time was		Before 1972, UTC was not generally recognized, and civil time was
	determined by individual jurisdictions using different techniques		determined by individual jurisdictions using different techniques
	for attempting to follow Universal Time based on measuring the		for attempting to follow Universal Time based on measuring the
	rotation of the earth.		rotation of the earth.
	</t>		</t>
	<t>UTC is often mistakenly referred to as GMT, an earlier timescale		<t>UTC is often mistakenly referred to as GMT (Greenwich Mean Time), an earlier timescale
	for which UTC was designed to be a useful successor.</t>		for which UTC was designed to be a useful successor.</t>
	</dd>		</dd>
	<dt>ABNF:</dt>		<dt>ABNF:</dt>
	<dd>		<dd>
	<t>Augmented Backus-Naur Form, a format used to represent permissibl e		<t>Augmented Backus-Naur Form, a format used to represent permissibl e
	strings in a protocol or language, as defined in <xref target="RFC5234"/>.		strings in a protocol or language, as defined in <xref target="RFC5234"/>.
	The rules defined in <xref section="B" sectionFormat="of" target="RFC5234"/> are imported implicitly.</t>		The rules defined in <xref section="B" sectionFormat="of" target="RFC5234"/> are imported implicitly.</t>
	</dd>		</dd>
	<dt>Internet Extended Date/Time Format (IXDTF):</dt>		<dt>IXDTF:</dt>
	<dd>		<dd>
	<t>The date/time format defined in <xref target="extended-format"/> of this document.</t>		<t>Internet Extended Date/Time Format, the date/time format defined in <xref target="extended-format"/> of this document.</t>
	</dd>		</dd>
	<dt>Timestamp:</dt>		<dt>Timestamp:</dt>
	<dd>		<dd>
	<t>An unambiguous representation of a particular instant in time.</t >		<t>An unambiguous representation of a particular instant in time.</t >
	</dd>		</dd>
	<dt>UTC Offset:</dt>		<dt>UTC Offset:</dt>
	<dd>		<dd>
	<t>Difference between a given local time and UTC, usually given in		<t>Difference between a given local time and UTC, usually given in
	negative or positive hours and minutes. For example, local time in		negative or positive hours and minutes. For example, local time in
	the city of New York, NY, USA, in the wintertime in 2023, is 5 hours		the city of New York, NY, USA in the wintertime in 2023 is 5 hours
	behind UTC, so its UTC offset is "-05:00".</t>		behind UTC, so its UTC offset is <tt>-05:00</tt>.</t>
	</dd>		</dd>
	<dt>Z:</dt>		<dt>Z:</dt>
	<dd>		<dd>
	<t>A suffix which, when applied to a time, denotes a UTC offset of		<t>A suffix that, when applied to a time, denotes a UTC offset of
	00:00; often spoken "Zulu" from the ICAO phonetic alphabet		<tt>00:00</tt>; often pronounced "Zulu" from the ICAO phonetic alphabet
	representation of the letter "Z".		representation of the letter "Z".
	(Definition from <xref section="2" sectionFormat="of" target="RFC3339"/>; see <x		(The definition is from <xref section="2" sectionFormat="of" target="RFC3339"/>;
	ref target="ICAO-PA"/> for the		see the International Civil Aviation Organization (ICAO) document <xref target=
	phonetic alphabet.)</t>		"ICAO-PA"/> for the
			phonetic alphabet mentioned.)</t>
	</dd>		</dd>
	<dt>Time Zone:</dt>		<dt>Time Zone:</dt>
	<dd>		<dd>
	<t>A set of rules representing the relationship of local time to UTC		<t>A set of rules representing the relationship of local time to UTC
	for a particular place or region. Mathematically, a time zone can		for a particular place or region. Mathematically, a time zone can
	be thought of as a function that maps timestamps to UTC offsets.		be thought of as a function that maps timestamps to UTC offsets.
	Time zones can deterministically convert a timestamp to local time.		Time zones can deterministically convert a timestamp to local time.
	They can also be used in the reverse direction to convert 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		to a timestamp, with the caveat that some local times may have zero
	or multiple possible timestamps due to nearby daylight saving time		or multiple possible timestamps due to nearby daylight saving time
	changes or other changes to the UTC offset of that time zone.		changes or other changes to the UTC offset of that time zone.
	Unlike the UTC offset of a timestamp which makes no claims about		Unlike the UTC offset of a timestamp, which makes no claims about
	the UTC offset of other related timestamps (and which is therefore		the UTC offset of other related timestamps (and which is therefore
	unsuitable for performing local-time operations such as		unsuitable for performing local-time operations, such as
	"one day later"), a time zone also defines how to derive new		"one day later"), a time zone also defines how to derive new
	timestamps based on differences in local time.		timestamps based on differences in local time.
	For example, to calculate "one day later than this		For example, to calculate "one day later than this
	timestamp in San Francisco, California", a time zone is required because the		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		UTC offset of local time in San Francisco can change from one day
	to the next.</t>		to the next.</t>
	</dd>		</dd>
	<dt>IANA Time Zone:</dt>		<dt>IANA Time Zone:</dt>
	<dd>		<dd>
	<t>A named time zone that is included in the Time Zone Database (oft en		<t>A named time zone that is included in the Time Zone Database (oft en
	called <tt>tz</tt> or <tt>zoneinfo</tt>) maintained by IANA <xref target="TZDB"/		called <tt>tz</tt> or <tt>zoneinfo</tt>) maintained by IANA <xref target="TZDB"/
	><xref target="BCP175"/>.		> <xref target="BCP175"/>.
	Most IANA time zones		Most IANA Time Zones
	are named for the largest city in a particular region that shares		are named for the largest city in a particular region that shares
	the same time zone rules, e.g., <tt>Europe/Paris</tt> or <tt>Asia/Tokyo</tt> <xr ef target="TZDB-NAMING"/>.		the same time zone rules, e.g., <tt>Europe/Paris</tt> or <tt>Asia/Tokyo</tt> <xr ef target="TZDB-NAMING"/>.
	</t>		</t>
	<t>The rules defined for a named IANA time zone can change		<t>The rules defined for a named IANA Time Zone can change
	over time.		over time.
	The use of a named IANA time zone implies that the intent is for the		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:		rules that are current at the time of interpretation to apply:
	the additional information conveyed by using that time zone name is		the additional information conveyed by using that time zone name is
	to change with any rule changes as recorded in the IANA time zone		to change with any rule changes as recorded in the IANA Time Zone
	database.</t>		Database.</t>
	</dd>		</dd>
	<dt>Offset Time Zone:</dt>		<dt>Offset Time Zone:</dt>
	<dd>		<dd>
	<t>A time zone defined by a specific UTC offset, e.g. <tt>+08:45</tt		<t>A time zone defined by a specific UTC offset, e.g., <tt>+08:45</t
	>, and		t>, and
	serialized using as its name the same numeric UTC offset format used in an		serialized using as its name the same numeric UTC offset format used in an <xref
	RFC 3339 timestamp, for example:		target="RFC3339"/>
			timestamp, for example:
	</t>		</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	2022-07-08T00:14:07+08:45[+08:45]		2022-07-08T00:14:07+08:45[+08:45]
	]]></artwork>		]]></artwork>
	<t>An offset in the suffix that does not repeat the offset of the		<t>An offset in the suffix that does not repeat the offset of the
	timestamp is inconsistent (see <xref target="inconsistent"/>).</t>		timestamp is inconsistent (see <xref target="inconsistent"/>).</t>
	<t>Although serialization with offset time zones is		<t>Although serialization with offset time zones is
	supported in this document for backwards compatibility with		supported in this document for backwards compatibility with
	<tt>java.time.ZonedDateTime</tt> <xref target="JAVAZDT"/>, use of offset time zo nes is		<tt>java.time.ZonedDateTime</tt> <xref target="JAVAZDT"/>, use of offset time zo nes is
	strongly discouraged.		strongly discouraged.
	In particular, programs <bcp14>MUST NOT</bcp14> copy the UTC		In particular, programs <bcp14>MUST NOT</bcp14> copy the UTC
	offset from a timestamp into an offset time zone in order to satisfy		offset from a timestamp into an offset time zone in order to satisfy
	another program which requires a time zone suffix in its input.		another program that requires a time zone suffix in its input.
	Doing this will improperly assert that the UTC offset of timestamps		Doing this will improperly assert that the UTC offset of timestamps
	in that location will never change, which can result in incorrect		in that location will never change, which can result in incorrect
	calculations in programs that add, subtract, or otherwise derive new		calculations in programs that add, subtract, or otherwise derive new
	timestamps from the one provided. For example,		timestamps from the one provided. For example,
	<tt>2020-01-01T00:00+01:00[Europe/Paris]</tt> will let programs add six		<tt>2020-01-01T00:00+01:00[Europe/Paris]</tt> will let programs add six
	months to the timestamp while adjusting for Summer Time (daylight saving time).		months to the timestamp while adjusting for summer time (daylight saving time).
	But the same calculation applied to <tt>2020-01-01T00:00+01:00[+01:00]</tt>		However, the same calculation applied to <tt>2020-01-01T00:00+01:00[+01:00]</tt>
	will produce an incorrect result that will be off by one hour in the		will produce an incorrect result that will be off by one hour in the
	timezone <tt>Europe/Paris</tt>.</t>		time zone <tt>Europe/Paris</tt>.</t>
	</dd>		</dd>
	<dt>CLDR:</dt>		<dt>CLDR:</dt>
	<dd>		<dd>
	<t>Common locale data repository <xref target="CLDR"/>, a project of the Unicode		<t>Common Locale Data Repository <xref target="CLDR"/>, a project of the Unicode
	Consortium to provide locale data to applications.</t>		Consortium to provide locale data to applications.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>For more information about timescales, see <xref section="E" sectionF ormat="of" target="RFC1305"/>,		<t>For more information about timescales, see <xref section="E" sectionF ormat="of" target="RFC1305"/>,
	Section 3 of <xref target="ISO8601"/>, and the appropriate ITU documents		Section 3 of <xref target="ISO8601"/>, and the appropriate ITU documents
	<xref target="ITU-R-TF.460-6"/>.</t>		<xref target="ITU-R-TF.460-6"/>. (Note: <xref target="RFC1305"/> was obsoleted b
			y <xref target="RFC5905"/>,
			which no longer contains the Appendix <xref target="RFC1305" section="E" section
			Format="bare"/> referenced here.)</t>
	</section>		</section>
	</section>		</section>
	<section anchor="update">		<section anchor="update">
	<name>Updating RFC 3339</name>		<name>Updating RFC 3339</name>
	<section anchor="background">		<section anchor="background">
	<name>Background</name>		<name>Background</name>
	<t><xref section="4.3" sectionFormat="of" target="RFC3339"/> states that an offset given as <tt>Z</tt> or		<t><xref section="4.3" sectionFormat="of" target="RFC3339"/> states that an offset given as <tt>Z</tt> or
	<tt>+00:00</tt> implies that "UTC is the preferred reference point for the		<tt>+00:00</tt> implies that "UTC is the preferred reference point for the
	specified time". The offset <tt>-00:00</tt> is provided as a way to express		specified time". The offset <tt>-00:00</tt> is provided as a way to express
	that "the time in UTC is known, but the offset to local time is		that "the time in UTC is known, but the offset to local time is
	unknown".</t>		unknown".</t>
	<t>This convention mirrors a similar convention for date/time informatio n		<t>This convention mirrors a similar convention for date/time informatio n
	in email headers, described in <xref section="3.3" sectionFormat="of" target="RF C5322"/> and introduced		in email headers that is described in <xref section="3.3" sectionFormat="of" tar get="RFC5322"/> and introduced
	earlier in <xref section="3.3" sectionFormat="of" target="RFC2822"/>.		earlier in <xref section="3.3" sectionFormat="of" target="RFC2822"/>.
	This email header convention is in actual use, while its adaptation into		This email header convention is in actual use, while its adaptation into
	<xref target="RFC3339"/> was always		<xref target="RFC3339"/> was always
	compromised by the fact that <xref target="ISO8601-2000"/> and later versions do not actually allow <tt>-00:00</tt>.</t>		compromised by the fact that <xref target="ISO8601-2000"/> and later versions do not actually allow <tt>-00:00</tt>.</t>
	<t>Implementations that needed to express the semantics of <tt>-00:00</t t>		<t>Implementations that needed to express the semantics of <tt>-00:00</t t>
	therefore tended to use <tt>Z</tt> instead.</t>		therefore tended to use <tt>Z</tt> instead.</t>
	</section>		</section>
	<section anchor="update-to-rfc-3339">		<section anchor="update-to-rfc-3339">
	<name>Update to RFC 3339</name>		<name>Update to RFC 3339</name>
	<t>This specification updates <xref section="4.3" sectionFormat="of" tar get="RFC3339"/>, aligning it with the actual		<t>This specification updates <xref section="4.3" sectionFormat="of" tar get="RFC3339"/>, aligning it with the actual
	practice of interpreting the offset <tt>Z</tt> to mean the same as<tt>-00:00</tt >:		practice of interpreting the offset <tt>Z</tt> to mean the same as <tt>-00:00</t t>:
	"the time in UTC is known, but the offset to local time is unknown".</t>		"the time in UTC is known, but the offset to local time is unknown".</t>
	<t><xref section="4.3" sectionFormat="of" target="RFC3339"/> is revised
	to read as follows:</t>		<!-- [rfced] For clarity, would it be helpful to update "The original version
			of this specification" to "[RFC3339]"?
			Original:
			| 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).
			Perhaps:
			| If the time in UTC is known, but the offset to local time is
			| unknown, this can be represented with an offset of "Z".
			| ([RFC3339] 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).
			-->
			<t><xref section="4.3" sectionFormat="of" target="RFC3339"/> is revised to read
			as follows:</t>
	<blockquote>		<blockquote>
	<t>If the time in UTC is known, but the offset to local time is unknow n,		<t>If the time in UTC is known, but the offset to local time is unknow n,
	this can be represented with an offset of "Z".		this can be represented with an offset of "Z".
	(The original version of this specification provided "-00:00" for		(The original version of this specification provided <tt>-00:00</tt> for
	this purpose, which is not allowed by <xref target="ISO8601-2000"/> and there fore		this purpose, which is not allowed by <xref target="ISO8601-2000"/> and there fore
	is less interoperable; <xref section="3.3" sectionFormat="of" target="RFC5322 "/> describes a related		is less interoperable; <xref section="3.3" sectionFormat="of" target="RFC5322 "/> describes a related
	convention for email which does not have this problem).		convention for email, which does not have this problem).
	This differs semantically from an offset of "+00:00", which implies		This differs semantically from an offset of <tt>+00:00</tt>, which implies
	that UTC is the preferred reference point for the specified time.</t>		that UTC is the preferred reference point for the specified time.</t>
	</blockquote>		</blockquote>
	</section>		</section>
	<section anchor="notes">		<section anchor="notes">
	<name>Notes</name>		<name>Notes</name>
	<t>Note that the semantics of the local offset <tt>+00:00</tt> is not up dated;		<t>Note that the semantics of the local offset <tt>+00:00</tt> is not up dated;
	this retains the implication that UTC is the preferred reference point		this retains the implication that UTC is the preferred reference point
	for the specified time.</t>		for the specified time.</t>
	<t>Note also that the fact that <xref target="ISO8601-2000"/> and later do not allow <tt>-00:00</tt> as a		<t>Also note that the fact that <xref target="ISO8601-2000"/> and later do not allow <tt>-00:00</tt> as a
	local offset reduces the level of interoperability that can be		local offset reduces the level of interoperability that can be
	achieved in using this feature; the present specification however does		achieved in using this feature; however, the present specification does
	not formally deprecate this syntax.		not formally deprecate this syntax.
	With the update to RFC 3339, the local offset <tt>Z</tt> should now be used in i ts		With the update to <xref target="RFC3339"/>, the local offset <tt>Z</tt> should now be used in its
	place.</t>		place.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="date-time-format">		<section anchor="date-time-format">
	<name>Internet Extended Date/Time format (IXDTF)</name>		<name>Internet Extended Date/Time Format (IXDTF)</name>
	<t>This section discusses desirable qualities of formats for the		<t>This section discusses desirable qualities of formats for the
	timestamp extension suffix and defines the IXDTF format, which extends		timestamp extension suffix and defines the IXDTF format, which extends
	<xref target="RFC3339"/> for use in Internet protocols.</t>		<xref target="RFC3339"/> for use in Internet protocols.</t>
	<section anchor="format-of-extended-information">		<section anchor="format-of-extended-information">
	<name>Format of Extended Information</name>		<name>Format of Extended Information</name>
	<t>The format allows applications to specify additional		<t>The format allows applications to specify additional
	important information in addition to a bare <xref target="RFC3339"/> timestamp.<		important information in addition to a bare <xref target="RFC3339"/> time
	/t>		stamp.</t>
	<t>This is done by defining <em>tags</em>, each with a <em>key</em> and		<t>This is done by defining <em>tags</em>, each with a <em>key</em> and a
	a <em>value</em> separated by an equals sign.		<em>value</em>
	The value of a tag can be one or more items delimited by hyphen/minus signs.</t>		separated by an equals sign. The value of a tag can be one or more
	<t>Applications can build an informative timestamp <em>suffix</em> using		items delimited by hyphen/minus signs.</t>
	any number of		<t>Applications can build an informative timestamp <em>suffix</em> using any
	these tags.</t>		number of these tags.</t>
	<t>Keys are lower-case only. Values are case-sensitive unless otherwise		<t>Keys are lowercase only. Values are case-sensitive unless otherwise
	specified.</t>		specified.</t>
	<t>See <xref target="optionally-critical"/> for the handling of inconsis		<t>See <xref target="optionally-critical"/> for the handling of inconsist
	tent information		ent information
	in a suffix.</t>		in a suffix.</t>
	</section>		</section>
	<section anchor="registered">		<section anchor="registered">
	<name>Registering Keys for Extended Information Tags</name>		<name>Registering Keys for Extended Information Tags</name>
	<t>Suffix tag keys are registered by supplying the information		<t>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 <xref target="RFC6838"/>; if in doubt, the		specified for the "Media Types" registry <xref target="RFC6838"/>; if in doubt,
	provisions of this registry should be applied analogously.</t>		the
			provisions of this registry should be applied analogously.</t>
	<dl>		<dl>
	<dt>Key Identifier:</dt>		<dt>Key Identifier:</dt>
	<dd>		<dd>
	<t>The key (conforming to <tt>suffix-key</tt> in <xref target="abnf" />)</t>		<t>The key (conforming to <tt>suffix-key</tt> in <xref target="abnf" />)</t>
	</dd>		</dd>
	<dt>Registration status:</dt>		<dt>Registration Status:</dt>
	<dd>		<dd>
	<t>"Provisional" or "Permanent"</t>		<t>"Provisional" or "Permanent"</t>
	</dd>		</dd>
	<dt>Description:</dt>		<dt>Description:</dt>
	<dd>		<dd>
	<t>A very brief description of the key.</t>		<t>A very brief description of the key</t>
	</dd>		</dd>
	<dt>Change controller:</dt>		<dt>Change Controller:</dt>
	<dd>		<dd>
	<t>Who is in control of evolving the specification governing values for		<t>Who is in control of evolving the specification governing values for
	this key. This information can include email addresses of contact		this key. This information can include email addresses of contact
	points and discussion lists, and references to relevant web pages (URLs).</t>		points, discussion lists, and references to relevant web pages (URLs).</t>
	</dd>		</dd>
	<dt>Reference:</dt>		<dt>Reference:</dt>
	<dd>		<dd>
	<t>A reference.		<t>A reference.
	For permanent tag keys, this includes a full specification.		For permanent tag keys, this includes a full specification.
	For provisional tag keys, there is an expectation that some		For provisional tag keys, there is an expectation that some
	information is available even if that does not amount to a full		information is available even if that does not amount to a full
	specification; in this case, the registrant is expected to improve this		specification; in this case, the registrant is expected to improve this
	information over time.</t>		information over time.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Key names that start with an underscore are intended for experiments		<t>Key names that start with an underscore are intended for experiments
	in controlled environments and cannot be registered; such keys <bcp14>MUST		in controlled environments and cannot be registered; such keys <bcp14>MUST
	NOT</bcp14> be used for interchange and <bcp14>MUST</bcp14> be rejected by imple mentations		NOT</bcp14> be used for interchange and <bcp14>MUST</bcp14> be rejected by imple mentations
	not specifically configured to take part in such an experiment.		not specifically configured to take part in such an experiment.
	See <xref target="BCP178"/> for a discussion about the danger of experimental ke ys		See <xref target="BCP178"/> for a discussion about the danger of experimental ke ys
	leaking out to general production and why that must be prevented.</t>		leaking out to general production and why that must be prevented.</t>
	</section>		</section>
	<section anchor="optionally-critical">		<section anchor="optionally-critical">
	<name>Optional Generation, Elective vs. Critical Consumption</name>		<name>Optional Generation and Elective vs. Critical Consumption</name>
	<t>For the IXDTF format, suffix tags are always <em>optional</em>: They		<t>For the IXDTF format, suffix tags are always <em>optional</em>. They
	can be added or left out as desired by the generator of the string.		can be added or left out as desired by the generator of the string.
	(An application might require the presence		(An application might require the presence
	of specific suffix tags, though.)</t>		of specific suffix tags, though.)</t>
	<t>Without further indication, suffix tags are also <em>elective</em>:		<t>Without further indication, suffix tags are also <em>elective</em>.
	The recipient is free to ignore any suffix tag included in an IXDTF		The recipient is free to ignore any suffix tag included in an IXDTF
	string.		string.
	Reasons might include that the recipient does		Reasons might include that the recipient does
	not implement (or know about) the specific suffix key, or that it does		not implement (or know about) the specific suffix key or that it does
	recognize the key but cannot act on the value provided.</t>		recognize the key but cannot act on the value provided.</t>
	<t>A suffix tag may also indicate that it is <em>critical</em>: The reci pient is		<t>A suffix tag may also indicate that it is <em>critical</em>: The reci pient is
	advised that it <bcp14>MUST NOT</bcp14> act on the Internet Extended Date/Time F ormat (IXDTF) string		advised that it <bcp14>MUST NOT</bcp14> act on the IXDTF string
	unless it can process the suffix tag as specified. A critical suffix		unless it can process the suffix tag as specified. A critical suffix
	tag is indicated by following its opening bracket with an exclamation		tag is indicated by following its opening bracket with an exclamation
	mark (see <tt>critical-flag</tt> in <xref target="abnf"/>).</t>		mark (see <tt>critical-flag</tt> in <xref target="abnf"/>).</t>
	<t>For example, IXDTF strings such as:</t>		<t>For example, IXDTF strings such as:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	2022-07-08T00:14:07+01:00[Europe/Paris]		2022-07-08T00:14:07+01:00[Europe/Paris]
	]]></artwork>		]]></artwork>
	<t>are internally inconsistent (see <xref target="inconsistent"/>), beca use Europe/Paris did not		<t>are internally inconsistent (see <xref target="inconsistent"/>), beca use <tt>Europe/Paris</tt> did not
	use a time zone offset of <tt>+01:00</tt> in July 2022.		use a time zone offset of <tt>+01:00</tt> in July 2022.
	The time zone hint given in the suffix tag is elective, though, so the recipient is not		However, the time zone hint given in the suffix tag is elective, so the recipien t is not
	required to act on the inconsistency; it can treat the Internet		required to act on the inconsistency; it can treat the Internet
	Date/Time Format string as if it were:</t>		Date/Time Format string as if it were:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	2022-07-08T00:14:07+01:00		2022-07-08T00:14:07+01:00
	]]></artwork>		]]></artwork>
	<aside>		<aside>
	<t>Note that as per <xref target="update"/> (see also <xref target="in consistent"/>), the IXDTF string:</t>		<t>Note that, as per <xref target="update"/> (see also <xref target="i nconsistent"/>), the IXDTF string:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	2022-07-08T00:14:07Z[Europe/Paris]		2022-07-08T00:14:07Z[Europe/Paris]
	]]></artwork>		]]></artwork>
	<t>does not exhibit such an inconsistency, as the local offset of <tt> Z</tt>		<t>does not exhibit such an inconsistency, as the local offset of <tt> Z</tt>
	does not imply a specific preferred time zone of interpretation.		does not imply a specific preferred time zone of interpretation.
	Using the Time Zone Database rules for Europe/Paris in		Using the Time Zone Database rules for <tt>Europe/Paris</tt> in
	the summer of 2022, it is equivalent to:</t>		the summer of 2022, it is equivalent to:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	2022-07-08T02:14:07+02:00[Europe/Paris]		2022-07-08T02:14:07+02:00[Europe/Paris]
	]]></artwork>		]]></artwork>
	</aside>		</aside>
	<t>Similarly, an unknown suffix may be entirely ignored:</t>		<t>Similarly, an unknown suffix may be entirely ignored:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	2022-07-08T00:14:07+01:00[knort=blargel]		2022-07-08T00:14:07+01:00[knort=blargel]
	]]></artwork>		]]></artwork>
	<t>(assuming that the recipient does not understand the suffix key <tt>k nort</tt>).</t>		<t>(assuming that the recipient does not understand the suffix key <tt>k nort</tt>).</t>
	<t>In contrast to this elective use of a suffix tag,</t>		<t>In contrast to this elective use of a suffix tag,</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	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]
	]]></artwork>		]]></artwork>
	<t>each have an internal inconsistency or an unrecognized suffix key/val ue		<t>each have an internal inconsistency or an unrecognized suffix key/val ue
	that are marked as critical, so a recipient <bcp14>MUST</bcp14> treat these IXDT F		that is marked as critical, so a recipient <bcp14>MUST</bcp14> treat these IXDTF
	strings as erroneous.		strings as erroneous.
	This means that the application <bcp14>MUST</bcp14> reject the data, or perform some		This means that the application <bcp14>MUST</bcp14> reject the data or perform s ome
	other error handling, such as asking the user how to resolve the		other error handling, such as asking the user how to resolve the
	inconsistency (see <xref target="inconsistent"/>).</t>		inconsistency (see <xref target="inconsistent"/>).</t>
	<t>Note that applications <bcp14>MAY</bcp14> also perform additional pro cessing on		<t>Note that applications <bcp14>MAY</bcp14> also perform additional pro cessing 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.		user how to resolve the inconsistency.
	While they are not required to do so with elective suffix tags, they are		While they are not required to do so with elective suffix tags, they are
	required to reject or perform some other error handling when		required to reject or perform some other error handling when
	encountering inconsistent or unrecognized suffix tags marked as		encountering inconsistent or unrecognized suffix tags marked as
	critical.</t>		critical.</t>
	<t>An application that encounters duplicate use of a suffix key in		<t>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 <bcp14>MUST</bcp14> choose the first suffix that has that key,		on this inconsistency <bcp14>MUST</bcp14> choose the first suffix that has that key,
	i.e.,</t>		that is,</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	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]
	]]></artwork>		]]></artwork>
	<t>are then treated the same.</t>		<t>are then treated the same.</t>
	</section>		</section>
	<section anchor="inconsistent">		<section anchor="inconsistent">
	<name>Inconsistent <tt>time-offset</tt>/Time-Zone Information</name>		<name>Inconsistent <tt>time-offset</tt> and Time Zone Information</name>
	<t>An RFC 3339 timestamp can contain a <tt>time-offset</tt> value that i		<t>An <xref target="RFC3339"/> timestamp can contain a <tt>time-offset</
	ndicates		tt> value that indicates
	the offset between local time and UTC (see <xref section="4" sectionFormat="of" target="RFC3339"/>,		the offset between local time and UTC (see <xref section="4" sectionFormat="of" target="RFC3339"/>,
	noting that <xref target="update"/> of the present specification updates <xref s ection="4.3" sectionFormat="of" target="RFC3339"/>).</t>		noting that <xref target="update"/> of the present specification updates <xref s ection="4.3" sectionFormat="of" target="RFC3339"/>).</t>
	<t>The information given in such a <tt>time-offset</tt> value can be		<t>The information given in such a <tt>time-offset</tt> value can be
	inconsistent with the information provided in a time zone suffix for an		inconsistent with the information provided in a time zone suffix for an
	IXDTF timestamp.</t>		IXDTF timestamp.</t>
	<t>For example, a calendar application could store an IXDTF string repre senting a		<t>For example, a calendar application could store an IXDTF string repre senting a
	far-future meeting in a particular time zone. If that time zone's definition is		far-future meeting in a particular time zone. If that time zone's definition is
	subsequently changed to abolish daylight saving time, IXDTF strings that were		subsequently changed to abolish daylight saving time, IXDTF strings that were
	originally consistent may now be inconsistent.</t>		originally consistent may now be inconsistent.</t>
	<t>In case of inconsistent <tt>time-offset</tt> and time zone suffix, if the		<t>In case of an inconsistency between <tt>time-offset</tt> and time zon e suffix, if the
	critical flag is used on the time zone suffix, an application <bcp14>MUST</bcp14 > act		critical flag is used on the time zone suffix, an application <bcp14>MUST</bcp14 > act
	on the inconsistency.		on the inconsistency.
	If the critical flag is not used, it <bcp14>MAY</bcp14> act on the inconsistency .		If the critical flag is not used, it <bcp14>MAY</bcp14> act on the inconsistency .
	Acting on the inconsistency may involve rejecting the timestamp, or		Acting on the inconsistency may involve rejecting the timestamp or
	resolving the inconsistency via additional information such as user input		resolving the inconsistency via additional information, such as user input
	and/or programmed behavior.</t>		and/or programmed behavior.</t>
	<t>For example, the IXDTF timestamps in <xref target="example-inconsiste nt"/> represent		<t>For example, the IXDTF timestamps in <xref target="example-inconsiste nt"/> represent
	00:14:07 UTC, indicating a local time with a <tt>time-offset</tt> of +00:00.		00:14:07 UTC, indicating a local time with a <tt>time-offset</tt> of <tt>+00:00<
	However, because Europe/London used offset +01:00 in July 2022, the		/tt>.
			However, because <tt>Europe/London</tt> used offset <tt>+01:00</tt> in July 2022
			, the
	timestamps are inconsistent in <xref target="example-inconsistent"/>, where the first		timestamps are inconsistent in <xref target="example-inconsistent"/>, where the first
	case is one where the application <bcp14>MUST</bcp14> act on the inconsistency ( the		case is one where the application <bcp14>MUST</bcp14> act on the inconsistency ( the
	time zone suffix is marked critical), and the second case is one where		time zone suffix is marked critical) and the second case is one where
	it <bcp14>MAY</bcp14> act on it (time zone suffix is elective).</t>		it <bcp14>MAY</bcp14> act on the inconsistency (the time zone suffix is elective
			).</t>
	<figure anchor="example-inconsistent">		<figure anchor="example-inconsistent">
	<name>Inconsistent IXDTF timestamps</name>		<name>Inconsistent IXDTF Timestamps</name>
	<artwork><![CDATA[		<artwork><![CDATA[
	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]
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>As per <xref section="4.3" sectionFormat="of" target="RFC3339"/> as u pdated by <xref target="update"/>, IXDTF		<t>As per <xref section="4.3" sectionFormat="of" target="RFC3339"/> as u pdated by <xref target="update"/>, IXDTF
	timestamps may also forego indicating local time information in their		timestamps may also forego indicating local time information in their
	<xref target="RFC3339"/> part by using <tt>Z</tt> instead of a numeric time zone offset.		<xref target="RFC3339"/> part by using <tt>Z</tt> instead of a numeric time zone offset.
	The IXDTF timestamps in <xref target="example-consistent"/> (which represent the same		The IXDTF timestamps in <xref target="example-consistent"/> (which represent the same
	instant in time as the strings in <xref target="example-inconsistent"/>) are not		instant in time as the strings in <xref target="example-inconsistent"/>) are not
	inconsistent because they do not assert any particular local time nor		inconsistent because they do not assert any particular local time nor
	local offset in their <xref target="RFC3339"/> part.		local offset in their <xref target="RFC3339"/> part.
	Instead, applications that receive these strings can calculate the		Instead, applications that receive these strings can calculate the
	local offset and local time using the rules of the time zone suffix,		local offset and local time using the rules of the time zone suffix,
	such as Europe/London in the example in <xref target="example-consistent"/>, whi ch		such as <tt>Europe/London</tt> in the example in <xref target="example-consisten t"/>, which
	like <xref target="example-inconsistent"/> has a case with a time zone suffix ma rked		like <xref target="example-inconsistent"/> has a case with a time zone suffix ma rked
	critical, i.e., the intention is that the application must understand		critical (i.e., the intention is that the application must understand
	the time zone information, and one marked elective, which then only is		the time zone information) and one marked elective, which then only is
	provided as additional information.</t>		provided as additional information.</t>
	<figure anchor="example-consistent">		<figure anchor="example-consistent">
	<name>No inconsistency in IXDTF timestamps</name>		<name>No Inconsistency in IXDTF Timestamps</name>
	<artwork><![CDATA[		<artwork><![CDATA[
	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]
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Note that <tt>-00:00</tt> may be used instead of <tt>Z</tt>, because they have the		<t>Note that <tt>-00:00</tt> may be used instead of <tt>Z</tt> because t hey have the
	same meaning according to <xref target="update"/>, but <tt>-00:00</tt> is not al lowed by		same meaning according to <xref target="update"/>, but <tt>-00:00</tt> is not al lowed by
	<xref target="ISO8601-2000"/> and later so <tt>Z</tt> is preferred.</t>		<xref target="ISO8601-2000"/> and later so <tt>Z</tt> is preferred.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="extended-format">		<section anchor="extended-format">
	<name>Syntax Extensions to RFC 3339</name>		<name>Syntax Extensions to RFC 3339</name>
	<section anchor="abnf">		<section anchor="abnf">
	<name>ABNF</name>		<name>ABNF</name>
	<t>The following rules extend the ABNF syntax defined in <xref target="R FC3339"/> in		<t>The following rules extend the ABNF syntax defined in <xref target="R FC3339"/> in
	order to allow the inclusion of an optional suffix.</t>		order to allow the inclusion of an optional suffix.</t>
	<t>The Internet Extended Date/Time Format (IXDTF) is described by the		<t>The Internet Extended Date/Time Format (IXDTF) is described by the
	rule <tt>date-time-ext</tt>.</t>		rule <tt>date-time-ext</tt>.</t>
	<t><tt>date-time</tt> and <tt>time-numoffset</tt> are imported from <xre f section="5.6" sectionFormat="of" target="RFC3339"/>, <tt>ALPHA</tt> and <tt>DI GIT</tt> from <xref section="B.1" sectionFormat="of" target="RFC5234"/>.</t>		<t><tt>date-time</tt> and <tt>time-numoffset</tt> are imported from <xre f section="5.6" sectionFormat="of" target="RFC3339"/>, and <tt>ALPHA</tt> and <t t>DIGIT</tt> are imported from <xref section="B.1" sectionFormat="of" target="RF C5234"/>.</t>
	<figure anchor="grammar">		<figure anchor="grammar">
	<name>ABNF grammar of extensions to RFC 3339</name>		<name>ABNF Grammar of Extensions to RFC 3339</name>
	<sourcecode type="abnf" name="date-time-ext.abnf"><![CDATA[		<sourcecode type="abnf" name="date-time-ext.abnf"><![CDATA[
	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 line 576 ¶		skipping to change at line 596 ¶
	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
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>Note that a <tt>time-zone</tt> is syntactically similar to a <tt>suff ix-tag</tt>,		<t>Note that a <tt>time-zone</tt> is syntactically similar to a <tt>suff ix-tag</tt>
	but does not include an equals sign.		but does not include an equals sign.
	This special case is only available for time zone tags.</t>		This special case is only available for time zone tags.</t>
	<t>The ABNF definition of <tt>time-zone-part</tt> matches "." and "..", which		<t>The ABNF definition of <tt>time-zone-part</tt> matches "." and "..", which
	however both are explicitly excluded (see also comment on		both are explicitly excluded (see the note below on
	<tt>time-zone-part</tt>).</t>		<tt>time-zone-part</tt>).</t>
	<t><tt>time-zone-name</tt> is intended to be the name of an IANA Time Zo ne.		<t><tt>time-zone-name</tt> is intended to be the name of an IANA Time Zo ne.
	As generator and recipient may be using different revisions of the		As a generator and recipient may be using different revisions of the
	Time Zone Database, recipients may not be aware of such an IANA Time		Time Zone Database, recipients may not be aware of such an IANA Time
	Zone name and should treat such a situation as any other inconsistency.</t>		Zone name and should treat such a situation as any other inconsistency.</t>
	<aside>		<aside>
	<t>Note: At the time of writing, the length of each <tt>time-zone-part </tt> is		<t>Note: At the time of writing, the length of each <tt>time-zone-part </tt> is
	limited to a maximum of 14 characters by the rules in <xref target="TZDB-NAMING" />.		limited to a maximum of 14 characters by the rules in <xref target="TZDB-NAMING" />.
	One platform is known to enforce this limit, an entry in a timezone		One platform is known to enforce this limit, and an entry in a Time Zone
	database on another platform is known to exceed this limit.		Database on another platform is known to exceed this limit.
	As the <tt>time-zone-name</tt> will ultimately have to be looked up in the		As the <tt>time-zone-name</tt> will ultimately have to be looked up in the
	database, which therefore has control over the length, the		database, which therefore has control over the length, the
	<tt>time-zone-part</tt> production in <xref target="grammar"/> is deliberately p ermissive.</t>		<tt>time-zone-part</tt> production in <xref target="grammar"/> is deliberately p ermissive.</t>
	</aside>		</aside>
	</section>		</section>
	<section anchor="date-time-examples">		<section anchor="date-time-examples">
	<name>Examples</name>		<name>Examples</name>
	<t>Here are some examples of Internet Extended Date/Time Format (IXDTF). </t>		<t>This section contains some examples of Internet Extended Date/Time Fo rmat (IXDTF).</t>
	<figure anchor="rfc3339-datetime">		<figure anchor="rfc3339-datetime">
	<name>RFC 3339 date-time with time zone offset</name>		<name>RFC 3339 date-time with Time Zone Offset</name>
	<sourcecode type="ixdtf"><![CDATA[		<artwork><![CDATA[
	1996-12-19T16:39:57-08:00		1996-12-19T16:39:57-08:00
	]]></sourcecode>		]]></artwork>
	</figure>		</figure>
	<t><xref target="rfc3339-datetime"/> represents 39 minutes and 57 second s after the 16th hour of		<t><xref target="rfc3339-datetime"/> represents 39 minutes and 57 second s after the 16th hour of
	December 19th, 1996 with an offset of -08:00 from UTC.		December 19, 1996, with an offset of <tt>-08:00</tt> from UTC.
	Note that this is the same instant in time as <tt>1996-12-20T00:39:57Z</tt>, exp ressed in UTC.</t>		Note that this is the same instant in time as <tt>1996-12-20T00:39:57Z</tt>, exp ressed in UTC.</t>
	<figure anchor="datetime-tzname">		<figure anchor="datetime-tzname">
	<name>Adding a time zone name</name>		<name>Adding a Time Zone Name</name>
	<sourcecode type="ixdtf"><![CDATA[		<artwork><![CDATA[
	1996-12-19T16:39:57-08:00[America/Los_Angeles]		1996-12-19T16:39:57-08:00[America/Los_Angeles]
	]]></sourcecode>		]]></artwork>
	</figure>		</figure>
	<t><xref target="datetime-tzname"/> represents the exact same instant in time as the previous example but		<t><xref target="datetime-tzname"/> represents the exact same instant in time as the previous example but
	additionally specifies the human time zone associated with it		additionally specifies the human time zone associated with it
	("Pacific Time") for time-zone-aware applications to take into		("Pacific Time") for time-zone-aware applications to take into
	account.</t>		account.</t>
	<figure anchor="date-time-hebrew">		<figure anchor="date-time-hebrew">
	<name>Projecting to the Hebrew calendar</name>		<name>Projecting to the Hebrew Calendar</name>
	<sourcecode type="ixdtf"><![CDATA[		<artwork><![CDATA[
	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]
	]]></sourcecode>		]]></artwork>
	</figure>		</figure>
	<t><xref target="date-time-hebrew"/> represents the exact same instant i n time, but it informs calendar-aware		<t><xref target="date-time-hebrew"/> represents the exact same instant i n time, but it informs calendar-aware
	applications (see <xref target="calendar"/>) that they should project it to the Hebrew calendar.</t>		applications (see <xref target="calendar"/>) that they should project it to the Hebrew calendar.</t>
	<figure anchor="date-time-private">		<figure anchor="date-time-private">
	<name>Adding experimental tags</name>		<name>Adding Experimental Tags</name>
	<sourcecode type="ixdtf"><![CDATA[		<artwork><![CDATA[
	1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]		1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]
	]]></sourcecode>		]]></artwork>
	</figure>		</figure>
	<t><xref target="date-time-private"/>, based on <xref target="rfc3339-da tetime"/>, utilizes keys		<t><xref target="date-time-private"/>, based on <xref target="rfc3339-da tetime"/>, utilizes keys
	identified as experimental by a leading underscore to declare two additional pie ces of		identified as experimental by a leading underscore to declare two additional pie ces of
	information in the suffix; these can be interpreted by implementations		information in the suffix; these can be interpreted by implementations
	that take part in the controlled experiment making use of these tag keys.</t>		that take part in the controlled experiment making use of these tag keys.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="calendar">		<section anchor="calendar">
	<name>The u-ca Suffix Key: Calendar Awareness</name>		<name>The u-ca Suffix Key: Calendar Awareness</name>
	<t>Out of the possible suffix keys, the suffix key <tt>u-ca</tt> is alloca ted to		<t>Out of the possible suffix keys, the suffix key <tt>u-ca</tt> is alloca ted to
	indicate the calendar in which the date/time is preferably presented.</t>		indicate the calendar in which the date/time is preferably presented.</t>
	<t>A calendar is a set of rules defining how dates are counted and		<t>A calendar is a set of rules defining how dates are counted and
	consumed by implementations.		consumed by implementations.
	The set of suffix values allowed for this suffix key is the set of		The set of suffix values allowed for this suffix key is the set of
	values defined for the Unicode Calendar Identifier <xref target="TR35"/>.		values defined for the Unicode Calendar Identifier <xref target="TR35"/>.
	A resource that has been built to provide links into the most recent
	stable and development <xref target="CLDR"/> information about that is provided		<xref target="CLDR-LINKS"/> provides links
	by		to the most recent information about <xref target="CLDR"/>, both stable and spec
	<xref target="CLDR-LINKS"/>.</t>		ific development stages.</t>
	</section>		</section>
	<section anchor="iana-cons">		<section anchor="iana-cons">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with th		<t>IANA has created a registry called "Timestamp Suffix Tag
	e RFC		Keys" in a new registry group titled "Internet Date/Time Format".
	number of this RFC and remove this note.</cref></t>
	<t>IANA is requested to establish a registry called "Timestamp Suffix Tag
	Keys" in a new registry group "Internet Date/Time Format".
	Each entry in the registry shall consist of the information described in <xref t arget="registered"/>.		Each entry in the registry shall consist of the information described in <xref t arget="registered"/>.
	Initial contents of the registry are specified in <xref target="tab-registered"/ >.</t>		The initial contents of the registry are specified in <xref target="tab-register ed"/>.</t>
	<table anchor="tab-registered">		<table anchor="tab-registered">
	<name>Initial Content of Timestamp Suffix Tag Keys registry</name>		<name>Initial Contents of Timestamp Suffix Tag Keys Registry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Key Identifier</th>		<th align="left">Key Identifier</th>
	<th align="left">Registration status</th>		<th align="left">Registration Status</th>
	<th align="left">Description:</th>		<th align="left">Description</th>
	<th align="left">Change controller</th>		<th align="left">Change Controller</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">u-ca</td>		<td align="left">u-ca</td>
	<td align="left">Permanent</td>		<td align="left">Permanent</td>
	<td align="left">Preferred Calendar for Presentation</td>		<td align="left">Preferred Calendar for Presentation</td>
	<td align="left">IESG</td>		<td align="left">IETF</td>
	<td align="left">		<td align="left">
	<xref target="calendar"/> of RFCthis</td>		<xref target="calendar"/> of RFC 9557</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>The registration policy <xref target="BCP26"/> is "Specification Requir ed" for		<t>The registration policy <xref target="BCP26"/> is "Specification Requir ed" for
	permanent entries, and "Expert Review" for provisional ones.		permanent entries and "Expert Review" for provisional ones.
	In the second case, the expert is instructed to ascertain that a basic		In the second case, the experts are instructed to ascertain that a basic
	specification does exist, even if not complete or published yet.</t>		specification does exist, even if not complete or published yet.</t>
	<t anchor="de-instructions">The experts also are instructed to be frugal i n the allocation of		<t anchor="de-instructions">The experts are also instructed to be frugal i n the allocation of
	key identifiers that are suggestive of generally applicable semantics,		key 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.		use and can make good use of the key identifier's conciseness.
	If the experts become aware of key identifiers that are deployed and		If the experts become aware of key identifiers that are deployed and
	in use, they may also initiate a registration on their own if		in use, they may also initiate a registration on their own if
	they deem such a registration can avert potential future collisions.</t>		they deem such a registration can avert potential future collisions.</t>
	</section>		</section>
	<section anchor="security-considerations">		<section anchor="security-considerations">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<section anchor="excessive-disclosure">		<section anchor="excessive-disclosure">
	<name>Excessive Disclosure</name>		<name>Excessive Disclosure</name>
	<t>The ability to include various pieces of ancillary information with a		<t>The ability to include various pieces of ancillary information with a
	timestamp might lead to excessive disclosure.		timestamp might lead to excessive disclosure.
	An example for possibly excessive disclosure is given in <xref section="7" secti onFormat="of" target="RFC3339"/>.		An example for possibly excessive disclosure is given in <xref section="7" secti onFormat="of" target="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
	<xref target="DATA-MINIMIZATION"/>.		<xref target="I-D.arkko-iab-data-minimization-principle"/>.
	More generally speaking, generators of IXDTF timestamps need to		More generally speaking, generators of IXDTF timestamps need to
	consider whether information to be added to the timestamp is		consider whether information to be added to the timestamp is
	appropriate to divulge to the recipients of this information, and need		appropriate to divulge to the recipients of this information and need
	to err on the side of minimizing such disclosure if the set of		to err on the side of minimizing such disclosure if the set of
	recipients is not under control of the originator.</t>		recipients is not under control of the originator.</t>
	</section>		</section>
	<section anchor="data-format-implementation-vulnerabilities">		<section anchor="data-format-implementation-vulnerabilities">
	<name>Data Format Implementation Vulnerabilities</name>		<name>Data Format Implementation Vulnerabilities</name>
	<t>As usual when extending the syntax of a data format, this can lead to		<t>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.		format.
	No considerations are known for the IXDTF syntax that would pose		No considerations are known for the IXDTF syntax that would pose
	concerns that are out of the ordinary.</t>		concerns that are out of the ordinary.</t>
	</section>		</section>
	<section anchor="operating-with-inconsistent-data">		<section anchor="operating-with-inconsistent-data">
	<name>Operating with Inconsistent Data</name>		<name>Operating with Inconsistent Data</name>
	<t>Information provided in the various parts of an IXDTF string may be		<t>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 <xref target="inconsistent"/>) and with fut		this specification (for instance, see <xref target="inconsistent"/>)
	ure		and with future extensions still to be defined. Where consistent
	extensions still to be defined.		interpretation between multiple actors is required for security
	Where consistent interpretation between multiple actors is required		purposes (e.g., where timestamps are embedded as parameters in access
	for security purposes (e.g., where timestamps are embedded as		control information), only extensions that have a well-understood and
	parameters in access control information), only those extensions can be		shared resolution of such inconsistent data can be employed.</t>
	employed that have a well-understood and shared resolution of such
	inconsistent data.</t>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<displayreference target="ISO8601" to="ISO8601:1988"/>		<displayreference target="ISO8601" to="ISO8601:1988"/>
	<displayreference target="ISO8601-2000" to="ISO8601:2000"/>		<displayreference target="ISO8601-2000" to="ISO8601:2000"/>
	<displayreference target="ISO8601-2019" to="ISO8601-1:2019"/>		<displayreference target="ISO8601-2019" to="ISO8601-1:2019"/>
			<displayreference target="I-D.arkko-iab-data-minimization-principle" to="DAT
			A-MINIMIZATION"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC3339">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"
	<title>Date and Time on the Internet: Timestamps</title>		/>
	<author fullname="G. Klyne" initials="G." surname="Klyne"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
	<author fullname="C. Newman" initials="C." surname="Newman"/>		/>
	<date month="July" year="2002"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"
	<abstract>		/>
	<t>This document defines a date and time format for use in Interne
	t protocols that is a profile of the ISO 8601 standard for representation of dat		<referencegroup anchor="BCP26" target="https://www.rfc-editor.org/info/bcp26">
	es and times using the Gregorian calendar.</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xm
	</abstract>		l"/>
	</front>		</referencegroup>
	<seriesInfo name="RFC" value="3339"/>
	<seriesInfo name="DOI" value="10.17487/RFC3339"/>		<referencegroup anchor="BCP178" target="https://www.rfc-editor.org/info/bcp178">
	</reference>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6648.xm
	<reference anchor="RFC5234">		l"/>
	<front>		</referencegroup>
	<title>Augmented BNF for Syntax Specifications: ABNF</title>
	<author fullname="D. Crocker" initials="D." role="editor" surname="C		<referencegroup anchor="BCP175" target="https://www.rfc-editor.org/info/bcp175">
	rocker"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6557.xm
	<author fullname="P. Overell" initials="P." surname="Overell"/>		l"/>
	<date month="January" year="2008"/>		</referencegroup>
	<abstract>
	<t>Internet technical specifications often need to define a formal		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au		/>
	gmented BNF (ABNF), has been popular among many Internet specifications. The cur		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	rent specification documents ABNF. It balances compactness and simplicity with r		/>
	easonable representational power. The differences between standard BNF and ABNF		</references>
	involve naming rules, repetition, alternatives, order-independence, and value ra
	nges. This specification also supplies additional rule definitions and encoding
	for a core lexical analyzer of the type common to several Internet specification
	s. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="68"/>
	<seriesInfo name="RFC" value="5234"/>
	<seriesInfo name="DOI" value="10.17487/RFC5234"/>
	</reference>
	<reference anchor="RFC6838">
	<front>
	<title>Media Type Specifications and Registration Procedures</title>
	<author fullname="N. Freed" initials="N." surname="Freed"/>
	<author fullname="J. Klensin" initials="J." surname="Klensin"/>
	<author fullname="T. Hansen" initials="T." surname="Hansen"/>
	<date month="January" year="2013"/>
	<abstract>
	<t>This document defines procedures for the specification and regi
	stration of media types for use in HTTP, MIME, and other Internet protocols. Thi
	s memo documents an Internet Best Current Practice.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="13"/>
	<seriesInfo name="RFC" value="6838"/>
	<seriesInfo name="DOI" value="10.17487/RFC6838"/>
	</reference>
	<reference anchor="BCP26">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in the
	se fields do not have conflicting uses and to promote interoperability, their al
	locations are often coordinated by a central record keeper. For IETF protocols,
	that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This document
	defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Consideratio
	ns is clear and addresses the various issues that are likely in the operation of
	a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="26"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>
	<reference anchor="BCP178">
	<front>
	<title>Deprecating the "X-" Prefix and Similar Constructs in Applica
	tion Protocols</title>
	<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
	"/>
	<author fullname="D. Crocker" initials="D." surname="Crocker"/>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
	>
	<date month="June" year="2012"/>
	<abstract>
	<t>Historically, designers and implementers of application protoco
	ls have often distinguished between standardized and unstandardized parameters b
	y prefixing the names of unstandardized parameters with the string "X-" or simil
	ar constructs. In practice, that convention causes more problems than it solves.
	Therefore, this document deprecates the convention for newly defined parameters
	with textual (as opposed to numerical) names in application protocols. This mem
	o documents an Internet Best Current Practice.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="178"/>
	<seriesInfo name="RFC" value="6648"/>
	<seriesInfo name="DOI" value="10.17487/RFC6648"/>
	</reference>
	<reference anchor="BCP175">
	<front>
	<title>Procedures for Maintaining the Time Zone Database</title>
	<author fullname="E. Lear" initials="E." surname="Lear"/>
	<author fullname="P. Eggert" initials="P." surname="Eggert"/>
	<date month="February" year="2012"/>
	<abstract>
	<t>Time zone information serves as a basic protocol element in pro
	tocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database spec
	ifies the indices used in various protocols, as well as their semantic meanings,
	for all localities throughout the world. This database has been meticulously ma
	intained and distributed free of charge by a group of volunteers, coordinated by
	a single volunteer who is now planning to retire. This memo specifies procedure
	s involved with maintenance of the TZ database and associated code, including ho
	w to submit proposed updates, how decisions for inclusion of those updates are m
	ade, and the selection of a designated expert by and for the time zone community
	. The intent of this memo is, to the extent possible, to document existing pract
	ice and provide a means to ease succession of the database maintainers. This mem
	o documents an Internet Best Current Practice.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="175"/>
	<seriesInfo name="RFC" value="6557"/>
	<seriesInfo name="DOI" value="10.17487/RFC6557"/>
	</reference>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC2822">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2822.xml"
	<title>Internet Message Format</title>		/>
	<author fullname="P. Resnick" initials="P." role="editor" surname="R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"
	esnick"/>		/>
	<date month="April" year="2001"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1305.xml"
	<abstract>		/>
	<t>This document specifies a syntax for text messages that are sen		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"
	t between computer users, within the framework of "electronic mail" messages. [S		/>
	TANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2822"/>
	<seriesInfo name="DOI" value="10.17487/RFC2822"/>
	</reference>
	<reference anchor="RFC5322">
	<front>
	<title>Internet Message Format</title>
	<author fullname="P. Resnick" initials="P." role="editor" surname="R
	esnick"/>
	<date month="October" year="2008"/>
	<abstract>
	<t>This document specifies the Internet Message Format (IMF), a sy
	ntax for text messages that are sent between computer users, within the framewor
	k of "electronic mail" messages. This specification is a revision of Request For
	Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "S
	tandard for the Format of ARPA Internet Text Messages", updating it to reflect c
	urrent practice and incorporating incremental changes that were specified in oth
	er RFCs. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5322"/>
	<seriesInfo name="DOI" value="10.17487/RFC5322"/>
	</reference>
	<reference anchor="RFC1305">
	<front>
	<title>Network Time Protocol (Version 3) Specification, Implementati
	on and Analysis</title>
	<author fullname="D. Mills" initials="D." surname="Mills"/>
	<date month="March" year="1992"/>
	<abstract>
	<t>This document describes the Network Time Protocol (NTP), specif
	ies its formal structure and summarizes information useful for its implementatio
	n. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="1305"/>
	<seriesInfo name="DOI" value="10.17487/RFC1305"/>
	</reference>
	<reference anchor="ISO8601" target="https://www.iso.org/standard/15903.h tml">		<reference anchor="ISO8601" target="https://www.iso.org/standard/15903.h tml">
	<front>		<front>
	<title>Data elements and interchange formats — Information interchan ge — Representation of dates and times</title>		<title>Data elements and interchange formats -- Information intercha nge -- Representation of dates and times</title>
	<author>		<author>
	<organization abbrev="ISO">International Organization for Standard ization</organization>		<organization abbrev="ISO">International Organization for Standard ization</organization>
	</author>		</author>
	<date year="1988" month="June"/>		<date year="1988" month="June"/>
	</front>		</front>
	<seriesInfo name="ISO" value="8601:1988"/>		<seriesInfo name="ISO" value="8601:1988"/>
	<annotation>Also available from <⁠<eref target="https://nvlpubs.nis t.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf">https://nvlpubs.nist.gov/nistpub s/Legacy/FIPS/fipspub4-1-1991.pdf</eref>&gt;.</annotation>		<annotation>Also available from <eref target="https://nvlpubs.nist.gov /nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf" brackets="angle"/&gt;.</annotation>
	</reference>		</reference>
	<reference anchor="ISO8601-2000" target="https://www.iso.org/standard/26 780.html">		<reference anchor="ISO8601-2000" target="https://www.iso.org/standard/26 780.html">
	<front>		<front>
	<title>Data elements and interchange formats — Information interchan ge — Representation of dates and times</title>		<title>Data elements and interchange formats -- Information intercha nge -- Representation of dates and times</title>
	<author>		<author>
	<organization abbrev="ISO">International Organization for Standard ization</organization>		<organization abbrev="ISO">International Organization for Standard ization</organization>
	</author>		</author>
	<date year="2000" month="December"/>		<date year="2000" month="December"/>
	</front>		</front>
	<seriesInfo name="ISO" value="8601:2000"/>		<seriesInfo name="ISO" value="8601:2000"/>
	</reference>		</reference>
	<reference anchor="ISO8601-2019" target="https://www.iso.org/standard/70 907.html">		<reference anchor="ISO8601-2019" target="https://www.iso.org/standard/70 907.html">
	<front>		<front>
	<title>Date and time — Representations for information interchange — Part 1: Basic rules</title>		<title>Date and time -- Representations for information interchange -- Part 1: Basic rules</title>
	<author>		<author>
	<organization abbrev="ISO">International Organization for Standard ization</organization>		<organization abbrev="ISO">International Organization for Standard ization</organization>
	</author>		</author>
	<date year="2019" month="February"/>		<date year="2019" month="February"/>
	</front>		</front>
	<seriesInfo name="ISO" value="8601-1:2019"/>		<seriesInfo name="ISO" value="8601-1:2019"/>
	</reference>		</reference>
	<reference anchor="ITU-R-TF.460-6" target="https://www.itu.int/rec/R-REC -TF.460/en">		<reference anchor="ITU-R-TF.460-6" target="https://www.itu.int/rec/R-REC -TF.460/en">
	<front>		<front>
	<title>ITU-R TF.460-6. Standard-frequency and time-signal emissions< /title>		<title>Standard-frequency and time-signal emissions</title>
	<author>		<author>
	<organization/>		<organization>ITU-R</organization>
	</author>		</author>
	<date year="2002" month="February"/>		<date year="2002" month="February"/>
	</front>		</front>
			<seriesInfo name="ITU-R Recommendation" value="TF.460-6"/>
	</reference>		</reference>
	<reference anchor="IERS" target="https://www.iers.org/IERS/EN/Publicatio ns/Bulletins/bulletins.html">		<reference anchor="IERS" target="https://www.iers.org/IERS/EN/Publicatio ns/Bulletins/bulletins.html">
	<front>		<front>
	<title>International Earth Rotation Service Bulletins</title>		<title>International Earth Rotation Service Bulletins</title>
	<author>		<author>
	<organization/>		<organization>IERS</organization>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="JAVAZDT" target="https://docs.oracle.com/javase/8/doc s/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME">		<reference anchor="JAVAZDT" target="https://docs.oracle.com/javase/8/doc s/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME">
	<front>		<front>
	<title>Java SE 8, java.time.format, DateTimeFormatter: ISO_ZONED_DAT E_TIME</title>		<title>Class DateTimeFormatter: ISO_ZONED_DATE_TIME</title>
	<author>		<author>
	<organization/>		<organization>Oracle</organization>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="CLDR" target="https://cldr.unicode.org">		<reference anchor="CLDR" target="https://cldr.unicode.org">
	<front>		<front>
	<title>Unicode CLDR Project</title>		<title>Unicode CLDR Project</title>
	<author>		<author>
	<organization/>		<organization>Unicode CLDR</organization>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="CLDR-LINKS" target="https://cldr.unicode.org/stable-l inks-info">		<reference anchor="CLDR-LINKS" target="https://cldr.unicode.org/stable-l inks-info">
	<front>		<front>
	<title>Stable Links Info</title>		<title>Stable Links Info</title>
	<author>		<author>
	<organization>Unicode CLDR</organization>		<organization>Unicode CLDR</organization>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="TZDB" target="https://data.iana.org/time-zones/tz-lin k.html">		<reference anchor="TZDB" target="https://data.iana.org/time-zones/tz-lin k.html">
	<front>		<front>
	<title>Sources for time zone and daylight saving time data</title>		<title>Time zone and daylight saving time data</title>
	<author>		<author>
	<organization/>		<organization>IANA</organization>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="TZDB-NAMING" target="https://data.iana.org/time-zones /theory.html">		<reference anchor="TZDB-NAMING" target="https://data.iana.org/time-zones /theory.html">
	<front>		<front>
	<title>Theory and pragmatics of the tz code and data</title>		<title>Theory and pragmatics of the tz code and data</title>
	<author>		<author>
	<organization/>		<organization>IANA</organization>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="TR35" target="https://www.unicode.org/reports/tr35/#U nicodeCalendarIdentifier">		<reference anchor="TR35" target="https://www.unicode.org/reports/tr35/#U nicodeCalendarIdentifier">
	<front>		<front>
	<title>Unicode Technical Standard #35: Unicode Locale Data Markup La nguage (LDML)</title>		<title>Unicode Technical Standard #35: Unicode Locale Data Markup La nguage (LDML)</title>
	<author>		<author initials="M" surname="Davis" fullname="Mark Davis" role="edi tor">
	<organization/>		<organization/>
	</author>		</author>
	<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="ICAO-PA" target="https://store.icao.int/annex-10-aero nautical-telecommunications-volume-ii-communication-procedures-including-those-w ith-pans-status">		<reference anchor="ICAO-PA" target="https://store.icao.int/annex-10-aero nautical-telecommunications-volume-ii-communication-procedures-including-those-w ith-pans-status">
	<front>		<front>
	<title>Annex 10 to the Convention on International Civil Aviation: A eronautical Telecommunications; Volume II Communication Procedures including tho se with PANS status (7th ed.)</title>		<title>Annex 10 to the Convention on International Civil Aviation: A eronautical Telecommunications; Volume II Communication Procedures including tho se with PANS status</title>
	<author>		<author>
	<organization>International Civil Aviation Organization</organizat ion>		<organization>International Civil Aviation Organization</organizat ion>
	</author>		</author>
	<date year="2016" month="July"/>		<date year="2016" month="July"/>
	</front>		</front>
			<refcontent>7th ed.</refcontent>
	</reference>		</reference>
	<reference anchor="DATA-MINIMIZATION">
	<front>
	<title>Emphasizing data minimization among protocol participants</ti
	tle>
	<author fullname="Jari Arkko" initials="J." surname="Arkko">
	<organization>Ericsson</organization>
	</author>
	<date day="10" month="July" year="2023"/>
	<abstract>
	<t> Data minimization is an important privacy technique, as it c
	an reduce
	the amount information exposed about a user. This document
	emphasizes the need for data minimization among primary protocol
	participants, such as between clients and servers. Avoiding data
	leakage to outside parties is of course very important as well, but
	both need to be considered in minimization.
	This is because is necessary to protect against endpoints that are		<!-- [DATA-MINIMIZATION] [I-D.arkko-iab-data-minimization-principle] IAB state (
	compromised, malicious, or whose interests simply do not align with		None) -->
	the interests of users. It is important to consider the role of a
	participant and limit any data provided to it according to that role.		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.arkko-i
			ab-data-minimization-principle.xml"/>
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-arkko-iab-data-minimiza
	tion-principle-05"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<?line 828?>
	<section numbered="false" anchor="acknowledgements">		<section numbered="false" anchor="acknowledgements">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>Richard Gibson and Justin Grant provided editorial improvements.		<t>This specification benefits from work prepared by ECMA TC39,
	The authors would like to thank Francesca Palombini for her AD review.</t>		specifically in the Temporal proposal.</t>
	</section>
			<t><contact fullname="Richard Gibson"/> and <contact fullname="Justin
			Grant"/> provided editorial improvements. The SEDATE WG Chairs <contact
			fullname="Mark McFadden"/> and <contact fullname="Bron Gondwana"/>, the
			latter also in his role as CALEXT WG Chair, helped set up the structures
			needed to navigate the multi-SDO environment. <contact fullname="John
			Klensin"/> critically accompanied the development of this specification,
			which led to significant improvements. The authors would also like to
			especially thank <contact fullname="Francesca Palombini"/> for her AD
			review and for her overall guidance during the development process.
			</t>
			</section>
	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">		<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
	<name>Contributors</name>		<name>Contributors</name>
	<contact initials="J." surname="Grant" fullname="Justin Grant">		<contact initials="J." surname="Grant" fullname="Justin Grant">
	<organization/>		<organization/>
	<address>		<address>
	<email>justingrant.ietf.public@gmail.com</email>		<email>justingrant.ietf.public@gmail.com</email>
	</address>		</address>
	</contact>		</contact>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+V923IcR5bYe31FqhkOAZy+oEESJEFRO00ClDDDmwlwxqJW
	FrKrs7uLrK7qqawC2ITosP/BH7AP/gG/+nH3T/ZLfG6ZldkXDrXrCD+sQiE1
	6pJ58uS5X7J6vV5ydazuJMmkTAu9MMdqUulp3ctMPe1ZM9G16eF/6mxheuZj
	bYqJmfRyuGLrJNX1sbL1JEnLwprCNvZY1VVjEtuMF5m1WVnUqyWMeXZ68SzJ
	dTE7VqZIltlxouC9Kkvh/W9Xxn4Lf6flYqnDCzBIe60o8VJdphOzrOdw4S49
	slpUZmqDd8qqDq/UWZ3D/N/DrROAWelioi5gKaosVD036qyoTVUYmAGv2lov
	llZdZ/Vc6ckkq2EBOldZMS2rhca/Ej0eVwYw5l5Up4ITGn9AYz9b1Grv7L+c
	XDzbT65hyeemynSe2ayYRY9rNRqXTc1TE2inV6aobdIsEeWwiDt37jxMErjY
	GETZrCqb5e8fT+2dn56MLk73YYiFznLYM9rYP+Im98tqhkPDmpvxsaJ9v57J
	1g++ghiSRDf1vKyOk55iCnr7/v01oO18rgFrMDbMAAibAci6q877z/u8+wbR
	/qSB6zk8/UJX6dzYrKsOD7tq+M//B0kiq1fHaqSellXzL/9bE5E0RV3BxfOl
	zgq6MIEZvx3eOzh4gARgeIHV6lP5oflgij9mNG8fKMnD91RXFmBXT3BXi8JB
	+LbIrkxls/pf/letnlRmAY9cvDsLgH1d2nqq0znsy8HduwceQn7YQ3PSO3xw
	597DENwfDE61gkvLeVnAM3+4+7B393DYOxw+6B3deXg4bGFP9bj8Y/0po51B
	1gJGGTd1iOE/NbbOCvVDpYu6ffE9XZ3hxT5t7bIZ51n6xxneJgwkBRPyFZDT
	LaXePHt6eHB4FPx+gGQGP5Hw5Oe9wzt3j5UeF1N57N7R3aNjdQvYQj15+vru
	fX7s6MGdB8dqYSaZ7iHTW7gMt2F0vPtgeHiEr9MLx3xreP8B3Ts6uvvAXbnH
	V+7du594rrsyAsnhg8NDB9Qd/nlLlWNb5qY2XQU4UoUxyAzwpsqA8EfLJdBo
	9lGdynvDOwcwRVEve2U+gUtn568eHB0M8a5Sk8wucw275a4OHz54QHdqXc2Q
	AOZ1vbTHg8H19XU/syXu0ACERjHR1WQwvPfw4E5/Xi9yfqcVPfgP8afJkVBq
	Zs4MRUg6B6loFC/Vqn/97/8TRIsXN9EzcE/GemOWlQGBW/ND5VSRvKBRkTct
	PefYEn/3hAlJammRa6+qmS6yTzwIouxcliLXZDYv8s5f0RUL4gcYFaA8lifg
	DvCgR9m3jE0A6Vjh372DIwaoKICbc1sqfQUUqcc5LLwqF+q7f/0f//Sdw21x
	lQPd2n6R2bo/K68G+AOvDJ6bmU5Xg2dnr88H02xp4eLd3rA3fPhw2F9Opt9/
	3293tHd4cHCwtq3fun3Fe99+/cYeHt1/cPAffWNbnPHG4t+94WGE8eHDHRjv
	4fvDh78D5/cPHh7c/xLOjUcK4TbGnGUJ8Hfx/VpXtRqCANc2S1XV5P8fMRzh
	yOF4+LB3QDi+eNt707t41r97dNA7Og5xQreUu9X3kPSmlflbY4p05THVs9kM
	oTdinG0u1u/tIc+7Y7fqpg8IHVQmHbzpvTl9KpANSAmenb45P979LqhY2mp8
	bHD6cvCalBRv2+BJk4Mwz+DX2P3aIIJ4J05hC+fqTSksA7bRVZYa5QfascSp
	zq2Bv/80+svo3cnFdnjBJkZYdZobVJ+D9yC3rBk8oBsDvczoygBRO2BSGyBl
	ov31jP4EQAn8W7DNv7579fL05Fc0xH69OHtxuo2u/wTDqfNT9aCrcOQ+jtzn
	kbtqY2iiq63D7l7v0+cnb7YvNs0nVb8pMrRhxCj08L3ly/S2el2V701abxk8
	nBgf7T0/e/nnHbSwPh2yPiiEXp4VH2wPWSQE4Jxuqud4k+ToxjJbI85DugXC
	i3cnT3bsNYjxfqYLTcAQt3wCS80O6k8E0wYZnpdNlRqWNCSG8HFitYle5dls
	Xiurr9BGp7s4/g6Aei9HL85e/vB74ZqbslptgHVBlwmOZaVnKP5Si5oE3Z36
	E5moAuV2gN7cuceW1Tokslk9gKPP7kI/K2kfB/lkkQ/q6s49cg+YZW+dN8sl
	q0Wd//pU5wbF0q8nbtrNCVA8hBRRmSW4c5YGHuwUKDvfuCW04KY+mwAo2RQE
	0DbWc4RzYdI5/ET/RQSpusUYCZ96XsIThnU/eC4fmqV6Drql0aBe9p6fvHi+
	vwW1Z09Hr3qvR8fbph8Vhfmohgfg4tJOPS0L9N3ICijWRN7T7CrL1egqowsO
	tJGp4G5TE+wXYJCAxFogcli0PpLH/lLmDZDj2RlMEdxHrk7NpAElCroyzZsJ
	Ue68tIb94dejl+fgCOm6AX/yPlwwk/7+Li78EryR7gyw9KcmX6HGO9q60xb8
	H9MHYEvSPBrR1Rse9HSw6l69sereFS23l2W96EZv6Zfb88vt0XJ7uNzeUsPL
	vNwEHJdlmaF1B5vjABIOQLUQMAazwzgvxwNwuooBTloWg3G6vHt/kAoh9j8S
	y4LIHvWA8c9enL0bXZy9egl46530gZo+lL1Mj5GXdG+RFdlCsAVQA7AZcFXS
	7/eTpNfrgYkB3qkGcZwkF/PMKlBNDfKcmphpVpDtqMhVR4XvqKt2wQ6xT+Vh
	NF0T8f5IrlXOqkJi2B4RCahF07gJiicA7qxWEsdwDiV6jDi7XZoU+DBlowxm
	aM1dvJ0jb8EfU2vq5PLdZVddzzNwumFxRQl3wYSrVFNMwJCoy3KCa+pkiyVQ
	Tz2Hpby9eIqP4kgw9NRUlZkk9ANsIcM7yUK7BcWwfdR5BBaaUTc3DPjnz7CM
	n/8rU8Evwc9jpfYI2Z0UBu6opQZJW+nlHFglz9XYAOIW5RWMOl7RNIAA4JcM
	ffj9f/xHIvALhg+RqyjsAAjY6w2H+4hnuG4Bb0g95FWAoWUyHA8oFjF9dnr+
	A1y8ysw1gEh0sMgmE6ALoFVgvqqcNCnh9OZWhn9+TpKT2JNQujKqsbTnsHMA
	wgrsdoQEsGJq3IxMYlyJBkHuOKqrNCwRF3WtV+y+gVUL74FxOcHNm81IcpTK
	kTuRRjFJbDoHjgNdOgOYTzGMAn4CUFZaw0xo+NdEIKgsUyBawqJgyEE5MTat
	siXGBFQNVJ0I+Ta2pT+i635ycxP6JZ8/K+stdFw87NTE5KuenpRLGD5Z54gu
	8Y2uclAXfn8AJ0yKfnAYF59H+pmbZAxuhNe1PkIYBAYZ2psbYQgksB/LawPj
	d+GdzDp2BBSX17ZdDkkejASBTAF9AKRO+5VnNSiRJGDMCiTgFWPSc2g/eWJW
	Je77nNe1oqEAfY3Ok5CV4W2NuIbJtJoBkotAUmBoheCAjTEg/AAv4E4BzcHO
	GuQAkL4rEP8KbFONW43PZjVvXAHCy22AwqAbGMYisDLcDdxn2kNwTBrymlVI
	dMzZPB3sSjpPbIMSYY1sOHAL81lbphkvxVtmGDnr4qNlBaKDJKH+YJDIYbUp
	ReqU4fgrDa7tdkMOpC3IUgKrn7xAbPKGA99EIDMavLhlIDbkL2InibDj6a9W
	udEWOBHe85SHNKKzCjB9bfLckS+QlDgySFLPmgq3ZwEasxvDtKDVXCPOcNUM
	IS5a4cORWGdIW77oBoKeIm0lwAeaSegFV+UYXtmVrc0C10ZAJ0AFdl42+WSN
	qYEEbt1S52m5NF+lvewKOOCjt7iFNWCjvBgHcg7Zy9ENq4NpiWyFCwDtvzRV
	Db74cZLcJlkczNJMp9lHxDSmHzC2iHS9ZA7rAvV+wCHMRxJe6CZFE7ZwUfKi
	ztBvIcIMGLzvZhV+z7Y9Tfqh5+YBxbVsckKuRwJvIAMREzoxagBLRB/x3ICL
	K5CFyIUzA3ypc5CQE5LuLY20Igam2iSTUPAmf8U9ngqLhULNxnJxW+aEn5Tk
	SX+DKEpjifBERbabZh0gMtc10L8hArYGxE2N0R1jm7yOrQitYKdFSjA/EsFk
	VnmDgaVhsrckVqzUtKnBatwnM4Pc8+QZhZqQf1MUMJtgEo09o/d4m1i0akQ5
	Gzt0FUjXlot1m4T2tMsLwowChbD8colNstZ6AuBbQthzcgzkawm6Am1kGGIC
	wztj0BRgOiqy9Gya7fBdwSSZTsHjJ3yqDakbammxdwJyuK06z/JS126wDqCo
	b/rdeO1I8pi6CkmLlf1YyBtGRZSzWagin9vJGRXJGW9copxhigdzh9CE0KGw
	AtLKprTPNVsyMENXOazFTsyoLhdZig4yzrt3MTpD+vTae4dxrJvZwpnPG7S2
	ABYbY7IU5E2aGRbKEwAYUK3JsAbCzjBVleKD9bUxHMhkv5BMOVgV7OC6IhdD
	OxDeblFumDV8+lgqIjRBCbJB1wE0IDdFlYB1Bzgdm1QzbonUPbF5UiMhDdZe
	2li0OPUYjOMubCI87HwEkVe8oy1ZI8SEPVRj+God7JkLiSPVeawuyfgFi40W
	JZZzZWU6cAfKCl1cfA5s9oWVF8RKRdPINgtHrSw+UajNs5wESry9Po+Behz8
	dJRblNkmU4aEgAhV0CHxRgPPlPkVWG9rO00ihEmD7XM0oxAZGPMmAYGMAmQ8
	RqOa/Fg2neC5ckwWYjBRCC2qDKYDnrxh6xBctcAocqKVZ2JTFgPJWSUZDnS1
	cCdQIHVFHCbOcnSuXWRvsC53iguR7IQyGcuMLrC6wJpABQdARBbyy7I2Itpi
	Pc3jta6r05mWdYUojcwmIEmymTwjCCD1RrK+dt4GIHva5C2W4rUkQMFocrHN
	chIQ6M2tgFw/o84y6oMBAw1wCi7ii7fnFyD06P/q5Sv6/eb0P789e3N6gr/P
	fxw9f+5/JPLE+Y+v3j4/aX+1bz599eLF6csTfhmuquhS0nkx+qnTJSx3Xr3G
	sMLoeYeRE6pS9P7Ylg/kJHBpIlKXkfXk6et//qfhXdiPbzD/OiRHiv94MLx/
	F/4AvVTwbOSW8J+wDyt0GsF/IsYAhzHVy6zWObqPFoX0dUEEhMbIz4gZ8Km/
	G6fL4d3v5QIuOLrocBZdJJxtXtl4mZG45dKWaTw2o+trmI7hHf0U/e3wHlz8
	7h9y5IHe8ME/fA8cl4DsPU6O1dMSiCQriHek/gCjdxm6KoAojCEhRyNnZRi9
	wHSqU7JPgPF0g3HFSFGhKfe6zID0QK6/AKMHQ3p7T85ev9jHzQBJ874pODhA
	hiY4GUuscTBwZ0KCGtwz8IbSVp1/MeOCUggzly7A8qwi+9MlYsBVPn1zjnys
	4Bbo2OHD+4cwalU2szmu536XFNF1vFzUcRUa3gDCzoWq/NsfDVpVsLwf93GG
	J2aKjgzO0Q4bS2HQCOWsIBuX5D0FJ9kI0ZbMI5hkQUDA3GATwQMTULDqfQPK
	bpKlzPUccgh0EcWN/9aQQhLj3CyWtUhm9j3W9hhEOAp4QOICPD0O7bCNVZVx
	TMwgzoFZlAtvlVOsYFmAzgAntqBlcaiLZLhVP7y4iEIY3uYR6NhgchjyApJF
	gnayEOQgapcSnfXRk5fPkGRHbNLAw090+qGxvZe6qchyR5vOB2R4MG8bqiUi
	FRTVmEAQmc/BAdBhdZmWOVp1uUTRifwD0U4aAUtRmJJQxlK6Nn7G13s8QcT5
	N0jagd4qK4okoQJLszpfYZTyq70RXDtOS3VRRC8bsVOAwJfI8U2Ym3YwEL3o
	1TjLgvBZqAYMrnE2a8rGthjz+68xvgjKkry/NeO7T5JEvSIrDkc7EYJMjTf1
	XCgnMLeR8MnWbWxDTMFPUEVVYWZUdIO7sSwx0gG/waoWgwo4o8EUD2IHlLFG
	D7kbuzFirmNtFML/0lyrn8rqQ1e9/AmY8nzUdbr6mnSPc34ODw7vdJG27/F0
	aNiZeeZAtSWV9ARGKwZgewf3jg8OOoCHd4RM570TfZPbVHjbkcJaNcnWiQGh
	QD5v6FRMYcqDAxjvkfCXXZbAXarzrsmbDrsIJA+fjl5xIRc6ljpfzjUgG9l2
	Y/MooG0wWwujdJB091rbgUe8uTk3LI8PhWrZ8nHBaEkbcahR5MPG5P19Jiv1
	DsvLGBMcxWU2iSL5bNPlbNjMsyU+Fuwg4Amw4sRYSH3LXKeG3cUZ2o7qhYax
	KMeIZNQV/LIRD2YVbSFmkRq0A5GWEeVTp3/IAFvo5Xqks90T23ceFyU9yVRz
	AhrjIjQt6jSQqnUYAMZh2iWJyFjR+xorkMZt8JuxwZHvCSid1AU23LDtOEjZ
	ZThNtw3WpPrKkI0K/yHjuX3Nkj0/hwfUJ1Nh7hpQuGjyGlM5yGQkFkMkTBra
	hgLENyihbU55EAuAwUqKx64FByLSXgsOIEbeFnn2wWx5NMQjK4oFaBkKnKS5
	zsBn0lhousUtnwokPpLcLmkPpYcPYuJTpKthkAY8rowT/EhxoClQeOJCCYU9
	AhoDduJViC8Lb3bIWQTc4mxVZz8mQNpoF0gEk5Pd6wrlWWGuJWYm0HlNPPEC
	lLRTTEORzOMUBzIG+CcxJIhstrjDWXC8c7gOFhL40DYtu+qpzjNYbJHpTgw7
	haDI65p495pZP0Z3HD+KRidid2VoKGgERCZi3LkCtBXqwNHLkVoTHhgCCKPn
	Li7GQeCWcfxrlAtHLKo9kp1In8Cc8ORl/ekSafQSB0J/9HI/tPSAvgmAmxus
	hfj8+eaGK0FZ0b8obc33PSyIU1ToDKLL5OWYMIZnSeuwWdHKLRZXwptzeNkK
	7Vq9CMPzJCu7yvRn/a66PG0wTDx4jUEOXsHIZnpwUX5YlZcCr9RuUFh1m1nC
	IpRBjZcRbA8KhCsx0px1I7GqHe+yE25bt5jDQiqzgZJgSFBgLX12FBGXNhWZ
	rPIqs9d0LRt7LBjaEdgi2bji7WNTeC34iGArpv/SUaHkZ1YEmZdWmvKbGIDw
	VBWvNqESASIuwDLbOuv0uhY7YsB0m2puuYa3V13+4eDB8d17l11xYCwX1aNb
	INlES/YGrcOTSgEmXBUNF1m8FAVKqNKYavdDRTFtZcdxIsUSYPIc9g7u9w4e
	XIDdMbx7fHCfwfqZ//cLPjgqvMEj+XM2cQjhPtYMCt7IhoYy38QCyIaxJjBt
	2cIIr33+vE+kPMpZbXvE6NZllAlajuSNts3Smdjr4QZc/BjchWuNMRGX68hy
	ZFYcEt6+bCvecFsnrtztMkxedB1f7AKhrspilq8o2AhGJHgSE6oKLgJx0G1j
	fy7SACAtV06bITvK3qLY1JEER3YqNqaP8ooW1manKGd1wepQ5hP1J4LdRgLf
	ZZ0KorqsWDY1An5SMm9llmsLgPEpdwVL1NaideJFwJq697qNQvb8GGoL2UYY
	q0CjR9jQFVmgUHKZEg5MVhUX+zldRyo4jJ+yXJlMMMg8plqUrjdJrjE8vEvn
	ensa1y9pqEnsWCBdAJMc9A6G8O8FGed/OBjCf38OpfMvl7wisLRbuAAkZbOP
	MMSiLOq53chV4ZJzlHDSOMGFvM0CWFyi/FuzIRRnaOpWKASYCX2NXYDz/365
	hGEIaAlYu5A/4dvtAeHWFZXA5qJUQ2yhgyTiQHBKRBSrLOBjLvc8plqvUqwZ
	rkVEgYHeHRYL3tzgc8hd5IxjdafzXaTgDQs6Yd+Bu7NmgYuT7YpGFE3jIqYw
	PW7lRmaZbMcgCdMVP6dt1hA3CJs1AKjEuUd38HpQetFtUyBL5IqKQuRnF2+9
	3LFYBhKVTpOivqXeYtYBd9RL6ptbUvRD8V0MbWC3FaiGpPXP7vbvRB4a1cM5
	LdxKBZ/eu3yHZkMCqga3/zLW2p1thUpqR6FSslao1GcjQSa87LkJrOcjdrUk
	i2s+UoFFwhN7pQ8EJEB8KMrrgltoAg0S+VAoYJuCHuy4zGzaVikuMs6sgM6V
	OH5wE1fRxk3CfjoAgbqX1NzoCaVpogB0i/s7HvfY+4MxHe60YOaZJC7QteMl
	7B3CvSewwxlDMDMOSFE+DRVNVyQESmQ90cva9xKUSZj0xxCazgHXNkHVBmIt
	s230dKpTYeSwJungQNbADoOUGKHK5NQxAYFSnuKGbofRWl+4qtqgNEb6ntqt
	ZukUplncEIl3vZREvOAt1KpIrRheArRwkoOYhPxQxyWy7VFmxGfwdvMJ1oxl
	s4KSYnXrMUvicokqA0PFoQ3qwhSOwgE2gGNhdNHKXW3dmo6TfztRq4Cov8Dq
	5JBdZT6uqYnDOKyLGf6b4781JYoPqug9m6p/N0Co/FjzbymHc6VOrcKX8BJW
	JmKIJptlaLMHpWv15tZ5YdFhRHaQU/20y6YCFWGi+kupTWPq3krPoWeP7+RI
	jbSv5MKDl//oS2zt2N9SlpKiCDjQmjBhDma4vAlMARaGvCphngWpasU1JOTW
	W88SxFts3kVIZFHd8Wtmic0o2VFcuktmrxVyME9hMtMmaznNiE/XS2BVqz54
	mcxvk0cJLRX9taxgkDiyrdvY2teAm+wEl4CkIIqH9KtkmRNhkeQifZRECwNg
	mtRYiZFemdxLAKYUdg9oNuaABKudzBWrBud1ossLnk9TAV2FCeCY0udcqEHE
	kiB0pIKQCCbIVSkJOmIQyir3k786KdVsSMHulj0C+SSlJ8C6YXQRdEdCYdO+
	1ObuTDdMo3QDppWx35o6PiSZ4MSv8I4rqOD8DbGW+htI1AwL2xCXrvnQGRGt
	5btR7UYdIRIqIw+cKhlcLSIzA+c2bKT6cGhUHlnRrs3lcyyTvKRRAB6/6KAT
	kvPlcd1rXPpZylauwio0zuasVbqS9pZnOFA7xnjH1vq8oPx0gqYzhlkpMA9E
	dbvWM3u7S5WmImnV7Q9mdZtiBfD7SueNua1c3SsHG8CSQezD/oCu69Oy6DmJ
	qOqZk+NU0OkM49oscP9cKSUMNF8t56YYYKKFx0I8jkKU0DhNlk/YZ/B90oFr
	c5v39bYLZhQrjF2MgQPKacLVqrhIGPnPZsXF4CjWq16KITzM5YOJ+RcEn2/i
	5R6e8cD5oKYgsd76eF54wIjnZM67isl81QOBTiK3TWFwLS9CRiwfhCTWjEMt
	BMqk9MbM8DFKlBLcONw2qlIXsDhgoUpeMBNgnnOJm8BOfHCLbh9A1GMEI185
	2yMEpRWOLrYhXNgXBRORoYXNhT1FK3wq4eA6GMIhgbrlFXbLCxzki0kzPSaA
	MkQO0Cf41SR0ElLYbCg6je7fbEvffLEUoL+clY2lVCcgTLU9UC6diZUqe4B/
	F3JHx5VR3oNbl2xPY/f/58/7ScIbwIF46QbCgTqvHVw67yBtd17TgQcwWSdJ
	TlzVPkYVMVhHxevjKjPTtqK/TZfBtOi5csiQjj8AI4sB/uu8FCNdruM75qrM
	r9yexVJ/hmFVYukrJmU2bwhvOM2WvUu1a2kxYmW0/RgwGRXhUzxEWoJIcLIg
	xtdzQI/tSumZTySQxSiV+ddmrJYaA597b988txht88UTjB7/oks5LB0yPe1K
	u4AAykm1PI9X799u9yZ6HytkM6mwhvfqwG7A/NVaoS8+6avdqGQ8m66FIPWC
	iuhJ8CI4GI8LAXrkeQelSVcSb0xQHLtmQKTmDR0pMejWYAmC5UTVUvFMkNfY
	0u2sY+4SSlHQUglAIZKCY7GA1oyjBC1B5VR7cpVVZdE29KdYEVOzCe7ExSNO
	Q5EgwSgiFm55vc/d523HOQ5CoUYa4j2vEatLYl+ODBOPMslsTrNZI3Ud1LCA
	ccy2kK0I1tEXyctna4iw1SF1SuiFqhioABrZx78P9IHLSXLDJe70bOlKZyRO
	5UtPr+dimy0aS7hZVtQ+4cr6X4n8Vz/Q+/hHV53mKDVhV69sXz0VtUChpWax
	lIalbYqDQ0mbhon1Ip3FOXvh6rYb4zYJuVUimhdYGbN8FZib05rWJ8UvVeuu
	83LrsnLyiGtV+sneqAgtEylulGBuYHqmJsGqRpd5CEDsSiock/V/lYrnKTdr
	UKFRKljaXBXY4LeN4O72MdkWYLRmy8wlfSpDJipYC0TsxSoYJErauSrVxC3r
	jdG2rdV0os9b/O003nT2VKv2AEvoqzJh7UcS2AEAJEXxYFdtScP4Iiwn8ckp
	Fj6jknT289mA8rFhsIPCdWFWnXAjyDN+EkDJbUc8TAMRvhI9EVdenvd5gGDu
	ry8NEhJJxCqSklIpzY1SNnoWtauAAhopB6c8lNCOWb8mIsy2dQVjUeAekVIb
	Vzr9YFpxZz6muRaDZaGrD5zfuXQT9Ka5nsUaXWK0PqcdFjD7RLukq7YmqzZD
	8UniRG1FTPw1Gaeuz3GHQ4HkQneqTvBGmCtp/fVLhoAWJQ3Eh4dse7ePz9Ep
	dxVO69uBWkcYy7En1RrV6yyGgPiUPPWMeUqJ6rcfuf2vK5eQc5SUbBCQlIpj
	rnFKsTFQLX8P3UnynaZeS9ziSXldPO4MO9+HMQUYDmR60MfKaCdW2YL7Vqwy
	OLsBeLe+1V73m4/zbIz9F6KV1krapfcn8plx+95dtkNwD2+Qs21DFuHWr+Wp
	+8lb64y/LcUInAMnNyGkrKxImA4o2QOD4mK7Ijlwk6+wlw3V3xZkHLrdONxC
	/N8NaHNgP845Dk5lUYUL6jnSkwJ/X+bKgnvyd1kNBqnqx2Oqdshhuj1tXbvC
	donNISPulnbpklYyq0sa8HKfSiHZCMJGJ9e65VijLUdoWaf792D9JkbNTpr6
	pgGv8zE2soH6/OVn+uu9Xmr6c/dr8VvffO1r36yjkLx8ih3qwsutte4bNKRw
	D4Pi4RaJA9JSia+vQL7kBIyTvCRRdLAzpG+8gLAm0slUEoGNKoUB301yFhj6
	Duo9QkOEBmOzUmy7WpPKlUoqNuc5E039L977bvuCtP3guAi2unLlUtKkQr5n
	jJGdpQOBGApjFi9GP7EAckAFhSVBEwt5/YG+wPBSiHVPkJFZtbmKZMcq4n3t
	t309K64pKr1FR0J+UuLOkX7dPrN7M1INshdrO6C27QBVqCYAC7pOHNj44vpD
	09DTWeLoDA2k2EiljfDDY2Eh39vkaJQGIBbXlilHBnhJ4nqHv7iLSVl4/zQg
	GaLTdF6WXMumphnIpKiahTt14QcajQn1CX5BF/0/EBtsrNRYJUzcaCY+vcRe
	zFm4GZcUjGX1dUl6vEfaJgw84YELAUvQhmyWA3HxlzT063hgMXrZNBUj0CZB
	wsgVdm8WdDuu9FmsOA2H1rtXFYF1II7O9sj51vReEo7Ljbpxkt+bW9JvtW2F
	EtSP6N0nB8PBfJqKkLVRM0NubpGwCRMGeCPTVrf96SGDpBQ0o+NlNjr44uNP
	kqmuetzvBtKYU5TrhYZtfS2nAMOSuG9t2K6b4TEDY0tHtNXo6VOkgC3LcZln
	dr617HfdROcCEewNdik/jho4fKKdIRmJEM+i7rU1GwHYeKeixlBBeJdDP8aL
	HYWOBWUupYi2juxv95YuNtUWxtK2WdH9RFKoG3OQPQPzkLVGWmWHId5PRmnN
	OmXzJiEmK65IL7C8dvovqNkrq4R1RxsSDse4yvSu+kinkUgNUTVXAqgclL4W
	bEGFvWB2ZNRdE1cWe4M8qJaS9hJ6pBer3ZZQEyfnuGfCBRWo/Xit3XqDKYEQ
	ONMYHEqy5pY9L4sJigTaZhZGbOtF/lc3TjZZib1FQf6da+m2vfusIBKiUmx5
	AlJq722jpO07veegiQvtvP50FLbf1hNxM5zamDmJSQ7+2ts2sNOhXEm5w0Q+
	CE1kRuxOrSVPrz18c6xubUMiny32uBPprnV66qBqcn7izqoHpGBON3O+36kM
	EUPhJvtgDOb+Z2VIe1GR+nqXelZFCUUKb/qi4qAmRaqhpQB3PRjAPv+XmSZi
	mT1Xi+m0ntP7yfr5BuK7Bi1ru2h339mQsU4L6vdXPjnOxZsYqAvUR4AocFLi
	bLnDllrHFohKxlB3y5k50v8uXoZbA1kfvncB+SOailL5LSiNd7DZmy6n2wW8
	PzcnlhYScxGU7d4SSTMn1JSyU9TNqa6NOFOk2AYHMl8nrfPFB07Uvkxe8hlb
	nSmKZrf+chKvNCBf1/Xs/b02jMSkRVYldUWDro/K8raqjN2y4t3Xiol3X5IQ
	m/LhZbkmKbNiq5hoPTpfzBGeTxDwJ53WFpG71OSYhCq20IklZZSm1Pc842b/
	VqpgFDisZowLjpIvFJ2A4CFhYduwEVVcnPMpAafRSTFB1ed6wyZZ/djr6goT
	XOCVaZ8fJ6rBh7YcQhCyJ/hT7cEKVA4j6ilvXFUWlh+5TIlPdV/8vvBzZoOq
	SU5jJNRicdmWkADgWD3YXmHbjk0AkKre4AtbZdf6E+/1j7B8IKjruxw9f/3j
	SIY6Ofvh7OJy/aUn/WHUjAtA/Df4h0+Up9mRs3p8xEWuHisaUg1Up9/B//7a
	CZ4CK7lC4n+sNt8cKAIA3+nRm38I3yS9suPN2/EE0pwR//PIn3qFcGGKu98P
	x6c+kbXxac7be51BZ+3ifvuin+Cx6vzcUVGsfisgfHhoNO1AxbuoOr90kgR8
	aL9CN0WeUsOo4BWfcBh1T4RvRRhN2qqA7U/fdsMl7lF28+TR4W2aGoCMblu5
	Hb0COIMtDC/tu5cwZv9vwFgAfOdxPLQldInuCP55rH72eP7FFdTg/EkSsZU8
	7K+5PE4SQeaGVJ1vOgrjDoKMcD5H+YT1xO1V+MR/+ng07N0fEQeRdCdXghxP
	Eukkk9w1Su5uE3uwfjq8mE4tRQp63IlW1EfejCW/cxYQGSRlSfClrpIyOLtF
	+/oRQNVlN0G2aWP8kl7cLJZytak6D8xuzAe0nwqIDn2S6qULJ4jjk7AuY35D
	hVXj50WIeelsFOBeZ3C42sBxifZEhaaKOyGAUmqUOm0zKHIqJ4Yq16dBg/8y
	Zs5LzuW1pdZj9l+IcVn+x/2XfTTL2yS0HGIkcWOvd+PDJ6gyua0KMm0ruM+E
	dNtRrEQFKGuvr3HFmLCWzI2HJnnn+/jozB4uL+KgtUR1bFY30tRhyZYtJZcd
	ueFAqJQTwdpopKhjNYo7D6+RUTAazZWgxYx6zLj8bmMnwZgKzh3UsJaP2QL4
	CF4Y3sUwCpaTY6hT8vmst0kxrzVsvsK2I7AeKJDpyrP5VDS4lEpBKE3GZ2ng
	t1zaGBS1JrrGREVVEdLttXXMj6mh6KIbkvYZAdwgGOr3we7wBZ+pyTYUUU5e
	lmhqNkvX/DPx2+uNTinuR0PZV0lRwYxHLjvoG5gNCjwIXSJHuPgdSxTHRk75
	dId5XEmU9JRtTBsVrYrhiUci/WikAofi4O4GbtnvOg2Q7Ibs46SeJsOHD496
	w8Pe8OHF8Oj4zsPje2gJY3bUi8ZqmqKw818scjLSG3+txOao45pLiQLw5mZ9
	lDDaYhWMIgdiEI/cu9+eoyOFf0YNj2BwatgC2+kE/DEqwxw+xH3AZWyp5eel
	+DPp4jOwuGjVuatqi7t66bBzeIC+AWEHLXPpDWE7lcb9KpT+PCKfW4NbYX8d
	FTNwdOwvLZ79F6HqT9wsK6poEhwK3fYEM1bX3omRKt5iWu9coESrrzI8McU5
	lmOMsXnXCpWSlFnw8/NmoYvwdID2kFjagKxO9jqvNaeekf46+17lMJewqFwv
	TvanyCZyiuy/B6ucnZibcWWu11DMTMW3HI7lUwziSOEqf+T7LtTdYjt8/feg
	m32yzBXmWj80oyM6G9qlH9wjGBFxTravT3UNhlm9A+avxd+v07J8PNbVLz//
	Otaf4Fe9FWPLKruiKEdEllHVG9oS65iS18gpdWdDbJMGXdXUWU6HSlPxXOYq
	bMnVj6ahjvQcXGUEIChNpGMp0pwyUddllFLLTEpyctvpjmxlPZLQjlS4hae5
	bSkw5N0Iywgpxh7UPnqA3UG37tBMVzNOyyTXGm0vpFclhdV/Niv8uJokWUZI
	HgUWQN3c8gSRJK8a31vqDz5pM5CcUY0KFHAGMqLQgU7lfOokqPgKDh72J4FK
	Gtw1HLqgANiRK+WbqKicrH2XehfDM3N8PwCmkeVDTFgKT7lUOj0s4dMit+Ka
	I5IyoCxI/A0X0eA6cLR8gxSsa92j84jkhfA0ibrtym2R3dZ1o5nz5g6dnjGi
	xHfDloxkV8eYOMTegTrq4qXvqlBzO9Wl46EbGDks6oQ/yyL9IVcmL5dEHK5l
	eFtnrxwV4kNeFLhpvwcjLbhkZ2LlJzzjTna5uYVfOqFQ1Wc8b78ue2PTk8P0
	f9m8Ql+LU6d8sj7YXYZKfgwfUwS3pG9eUopwgfxD3wjByMch2MpeuHpjNI6N
	OxlFjmIxVkxOQyjBBJ1ui+/lrJPOhc/wClNcgL+IrQodNhwLEHT+Jfqeo+rs
	PCm+0+dz8r3hGVRMozylgxXZ0nY8teUAXReWCnohPmPMmL12Ogoe1YA/61OG
	J3Mt7Hq4uYF19+JRkt9U3FagflNbegTgatgEsMtJ/01tVP3TeK5fLXoWpibh
	E77uuw7iq76OzPMLMtLr8Kiu3/ibCmvghKpMglhEHr+RjonR0WZdGLFPGbH4
	2jai4P4Vh+2OnBtahbjDc3TTFRd0Hx6xGd45j5Lzb6TqhBs32z4BpJjMSCNC
	5xSFeg0P4wcjOnzIUtAUgMdnIEGsp766YhrQy+TFAmiNq8/XNoXr2h0tgb1W
	NkuTuHiAHH86wrzrmwbQ8XQnq1ONTEPcBKOuTC0uPU9q2eHm9GE49xhPNMIv
	hzqmEN3A3n9CctSTpOvPR3puZnhIEJ1uNw3OhBQjhnSR68XswjBmKZkPOswe
	6aW6MnJCrFdZ7fCYuci54b54X67oGxNcvMpNBHSMlprhR0tarapiaL8lry3N
	LOlOnwZ3CBnjB24Cr33nUicgBcuVqClqlzRSrRRUTcupwjqmu9JlmtB1zahd
	DJvjAAn+9ODgaTpSjc5JW5aUXMFcPVdJpMDCHJfos1GGIVfex4xF/C11btKm
	wj7PWBWIW0kFRYDyk8ymeYlnmTJ9+ObQ0oeUrnRF7oC3mRSeg5WDWbWKpCJ7
	W0EvJBe+o13m/HSec+Ln7GMRj3MzpnwuIlouq61PI6v48pc2Dn4/Cp33w/LQ
	SXbV5DOuJ9nUppsfVpB2TndWJvUlzUtsoce9dUp918EbbXs4aM1k7bg3ObhM
	TvQIPz6k/MeH1DUb8hgEqEG1b3zICJf3AmcPzr5eclNJtw1tsf+/nrEtDBt4
	qZADJt4lqBR9dcB3c2x+UsMm4XkgaF0Tfv3XN4JAmLMBNvJ6CEaC5FBVrqqA
	aq7hBUEKbhfxQ7jz09B4C+bJgjrcsHct3gw5WxoxL7GP+LAH9ZcmL1xnNLal
	YwiJjvDkgy45OeVb4Tg1RRtMu+maZvyZAkLzCRolV/HQ1Lq8dtIEuAzWHZMe
	njsOpDiVz1q8LFUam3QoizgINo06eAQ6rl9ieiqtwW0HtVIEgqxsHQY+K7la
	uQYjmgRrKJGlo2oH+spccrajhqyeB+JCV7V1gdiw+EtO51+vWyEHy/B5Qdhr
	1OWwsTcyg4h78FGtLWcvkK88Dc7Y36ym5T4rHFmOWQ8GBwjwO0zECDIRVrMa
	ErsBwNEXtlzloD97Erx+Og6/PW2QjgOwTijLERDg2fOZeFJ/E5f2YEBrwrnt
	BBuiF4bir3SUCnXAOIIPuGy/y+F9/sJcsC4pCjQLUV/iuWB1Nn/yJvjyF4el
	NR9q4A60d7HseOfoM4r8pSw8hww1zyhFugSrfWbkrKDjpmDfgNqF32QYTJ6o
	H7KxlZ638LvbLUXxl71Q70nPIg3H/h9/HM8KifN5m3SeQvGBT2rEQ5DUa52X
	izHIFSIIlHajE/99r/8Lw9XEuqR/AAA=
	</rfc>		</rfc>
End of changes. 155 change blocks.
	753 lines changed or deleted		325 lines changed or added
This html diff was produced by rfcdiff 1.48.