Diff: rfc9512.original.xml

	rfc9512.original.xml	rfc9512.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2. 2) -->	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2. 2) -->

	<?rfc tocindent="yes"?>
	<?rfc strict="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
	<?rfc compact="yes"?>	="IETF" category="info" consensus="true" docName="draft-ietf-httpapi-yaml-mediat
	<?rfc comments="yes"?>	ypes-10" number="9512" tocInclude="true" sortRefs="true" symRefs="true" updates=
	<?rfc inline="yes"?>	"" obsoletes="" xml:lang="en" version="3">
	<?rfc docmapping="yes"?>	<!-- xml2rfc v2v3 conversion 3.18.0 -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-httpapi-yaml-mediatypes-10" category="info" tocInclude="true" sortRefs="tr
	ue" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.18.0 -->
	<front>	<front>


	<title>YAML Media Type</title>	<title>YAML Media Type</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-yaml-mediatypes-	<seriesInfo name="RFC" value="9512"/>
	10"/>
	<author initials="R." surname="Polli" fullname="Roberto Polli">	<author initials="R." surname="Polli" fullname="Roberto Polli">

	<organization>Digital Transformation Department, Italian Government</organ ization>	<organization abbrev="DTD, Italian Government">Digital Transformation Depa rtment, Italian Government</organization>
	<address>	<address>
	<postal>	<postal>
	<country>Italy</country>	<country>Italy</country>
	</postal>	</postal>
	<email>robipolli@gmail.com</email>	<email>robipolli@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="E." surname="Wilde" fullname="Erik Wilde">	<author initials="E." surname="Wilde" fullname="Erik Wilde">
	<organization>Axway</organization>	<organization>Axway</organization>
	<address>	<address>

	skipping to change at line 48 ¶	skipping to change at line 45 ¶
	</author>	</author>
	<author initials="E." surname="Aro" fullname="Eemeli Aro">	<author initials="E." surname="Aro" fullname="Eemeli Aro">
	<organization>Mozilla</organization>	<organization>Mozilla</organization>
	<address>	<address>
	<postal>	<postal>
	<country>Finland</country>	<country>Finland</country>
	</postal>	</postal>
	<email>eemeli@gmail.com</email>	<email>eemeli@gmail.com</email>
	</address>	</address>
	</author>	</author>

	<date year="2023" month="August" day="30"/>	<date year="2024" month="February"/>
	<area>Applications and Real-Time</area>	<area>art</area>
	<workgroup>HTTPAPI</workgroup>	<workgroup>httpapi</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>
	<?line 71?>


	<t>This document registers	<abstract>
	the application/yaml media type	<t>This document registers the <tt>application/yaml</tt> media type and the
	and the +yaml structured syntax suffix	<tt>+yaml</tt> structured syntax suffix with IANA. Both identify document
	on the IANA Media Types registry,	components that are serialized according to the YAML specification.
	intended to be used to identify document components	</t>
	serialized according to the YAML specification.</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>About This Document</name>	</front>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-httpapi-yaml-mediatypes/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	HTTPAPI Working Group mailing list (<eref target="mailto:httpapi@ietf.or
	g"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/httpapi/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/httpapi
	/"/>.
	Working Group information can be found at <eref target="https://datatrac
	ker.ietf.org/wg/httpapi/about/"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-wg-httpapi/mediatypes/labels/yaml"
	/>.</t>
	</note>
	</front>
	<middle>	<middle>

	<?line 80?>

	<section anchor="introduction">	<section anchor="introduction">
	<name>Introduction</name>	<name>Introduction</name>

	<t>YAML <xref target="YAML"/> is a data serialization format	<t>YAML <xref target="YAML"/> is a data serialization format that is
	that is capable of conveying one or multiple	capable of conveying one or multiple documents in a single presentation
	documents in a single presentation stream	stream (e.g., a file or a network resource). It is widely used on the
	(e.g., a file or a network resource).	Internet, including in the API sector (e.g., see <xref target="OAS"/>),
	It is widely used on the Internet,	but a corresponding media type and structured syntax suffix had not
	including in the API sector (e.g., see <xref target="OAS"/>),	previously been registered by IANA.</t>
	but a corresponding media type and structured syntax suffix had not previously b	<t>To increase interoperability when exchanging YAML streams and
	een registered by IANA.</t>	leverage content negotiation mechanisms when exchanging YAML resources,
	<t>To increase interoperability when exchanging YAML streams,	this specification registers the <tt>application/yaml</tt> media type
	and leverage content negotiation mechanisms when exchanging	and the <tt>+yaml</tt> structured syntax suffix <xref
	YAML resources,	target="RFC6838"/>.</t>
	this specification	<t>Moreover, it provides security considerations and interoperability
	registers the <tt>application/yaml</tt> media type	considerations related to <xref target="YAML"/>, including its relation
	and the <tt>+yaml</tt> structured syntax suffix <xref target="MEDIATYPE"/>.</t>	with <xref target="RFC8259"/>.</t>
	<t>Moreover, it provides security considerations
	and interoperability considerations related to <xref target="YAML"/>,
	including its relation with <xref target="JSON"/>.</t>
	<section anchor="notational-conventions">	<section anchor="notational-conventions">
	<name>Notational Conventions</name>	<name>Notational Conventions</name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"MAY", and "OPTIONAL" in this document are to be interpreted as	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	only when, they	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	These words may also appear in this document in	be interpreted as
	lower case as plain English words, absent their normative meanings.	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	<?line -8?>	when, and only when, they appear in all capitals, as shown here.
	</t>	</t>

	<t>The terms "content", "content negotiation", "resource",
	and "user agent"	<t>The terms "content negotiation" and "resource"
	in this document are to be interpreted as in <xref target="HTTP"/>.</t>	in this document are to be interpreted as in <xref
	<t>The terms "fragment" and "fragment identifier"	target="RFC9110"/>.</t>
	in this document are to be interpreted as in <xref target="URI"/>.</t>	<t>The terms "fragment" and "fragment identifier" in this document are
	<t>The terms "presentation", "stream", "YAML document", "representation	to be interpreted as in <xref target="RFC3986"/>.</t>
	graph", "tag",	<t>The terms "presentation", "stream", "YAML document",
	"serialization detail",	"representation graph", "tag", "serialization detail", "node", "alias
	"node", "alias node", "anchor" and "anchor name"	node", "anchor", and "anchor name" in this document are to be
	in this document are to be interpreted as in <xref target="YAML"/>.</t>	interpreted as in <xref target="YAML"/>.</t>
	<t>Figures containing YAML code always start with
	the "%YAML 1.2" directive to improve readability.</t>	<t>Figures containing YAML code always start with the <tt>%YAML</tt>
		directive to improve readability.</t>
	</section>	</section>
	<section anchor="application-yaml-fragment">	<section anchor="application-yaml-fragment">

	<name>Fragment identification</name>	<name>Fragment Identification</name>
	<t>A fragment identifies a node in a stream.</t>	<t>A fragment identifies a node in a stream.</t>
	<t>A fragment identifier starting with "*"	<t>A fragment identifier starting with "*"
	is to be interpreted as a YAML alias node (see <xref target="fragment-alias-node "/>).</t>	is to be interpreted as a YAML alias node (see <xref target="fragment-alias-node "/>).</t>

	<t>For single-document YAML streams,
	a fragment identifier that is empty	<t>For single-document YAML streams, a fragment identifier that is
	or that starts with "/"	empty or that starts with "/" is to be interpreted as a JSON Pointer
	is to be interpreted as a JSON Pointer <xref target="JSON-POINTER"/>	<xref target="RFC6901"/> and is evaluated on the YAML
	and is evaluated on the YAML representation graph,	representation graph, traversing alias nodes; in particular, the
	walking through alias nodes;	empty fragment identifier references the root node. This syntax can
	in particular, the empty fragment identifier	only reference the YAML nodes that are on a path that is made up of
	references the root node.	nodes interoperable with the JSON data model (see <xref
	This syntax can only reference the YAML nodes that are	target="int-yaml-and-json"/>).</t>
	on a path that is made up of nodes interoperable with
	the JSON data model (see <xref target="int-yaml-and-json"/>).</t>
	<t>A fragment identifier is not guaranteed to reference an existing node .	<t>A fragment identifier is not guaranteed to reference an existing node .

	Therefore, applications SHOULD define how an unresolved alias node	Therefore, applications <bcp14>SHOULD</bcp14> define how an unresolved alias nod e
	ought to be handled.</t>	ought to be handled.</t>
	<section anchor="fragment-alias-node">	<section anchor="fragment-alias-node">

	<name>Fragment identification via alias nodes</name>	<name>Fragment Identification via Alias Nodes</name>
	<t>This section describes how to use	<t>This section describes how to use

	alias nodes (see Section 3.2.2.2 and 7.1 of <xref target="YAML"/>)	alias nodes (see Sections 3.2.2.2 and 7.1 of <xref target="YAML"/>)
	as fragment identifiers to designate nodes.</t>	as fragment identifiers to designate nodes.</t>
	<t>A YAML alias node can be represented in a URI fragment identifier	<t>A YAML alias node can be represented in a URI fragment identifier

	by encoding it into bytes using UTF-8 <xref target="UTF-8"/>,	by encoding it into bytes using UTF-8 <xref target="RFC3629"/>,
	but percent-encoding of those characters is not allowed by the fragment rule	but percent-encoding of those characters is not allowed by the fragment rule

	in <xref section="3.5" sectionFormat="of" target="URI"/>.</t>	in <xref section="3.5" sectionFormat="of" target="RFC3986"/>.</t>
	<t>If multiple nodes would match a fragment identifier,	<t>If multiple nodes match a fragment identifier,
	the first occurrence of such match is selected.</t>	the first occurrence of such a match is selected.</t>
	<t>Users concerned with interoperability of fragment identifiers:</t>	<t>Users concerned with interoperability of fragment identifiers:</t>
	<ul spacing="normal">	<ul spacing="normal">

	<li>SHOULD limit alias nodes to a set of characters	<li><bcp14>SHOULD</bcp14> limit alias nodes to a set of characters
	that do not require encoding	that do not require encoding

	to be expressed as URI fragment identifiers:	to be expressed as URI fragment identifiers
	this is generally possible since	(this is generally possible since
	anchor names are a serialization detail;</li>	anchor names are a serialization detail), and</li>
	<li>SHOULD NOT use alias nodes that match multiple nodes.</li>	<li><bcp14>SHOULD NOT</bcp14> use alias nodes that match multiple no
		des.</li>
	</ul>	</ul>

	<t>In the example resource below, the relative reference (see <xref se	<t>In the example resource below, the relative reference (see <xref
	ction="4.2" sectionFormat="of" target="URI"/>) <tt>file.yaml#*foo</tt>	section="4.2" sectionFormat="of" target="RFC3986"/>)
	identifies the first alias node <tt>*foo</tt> pointing to the node with value <t	<tt>file.yaml#*foo</tt> identifies the first alias node
	t>scalar</tt>	<tt>*foo</tt> pointing to the node with value <tt>scalar</tt> and
	and not the one in the second document;	not to the one in the second document, whereas the relative reference
	whereas	<tt>file.yaml#*document_2</tt> identifies the root node of the
	the relative reference <tt>file.yaml#*document_2</tt> identifies the root node	second document <tt>{one: [a, sequence]}</tt>.</t>
	of the second document <tt>{one: [a, sequence]}</tt>.</t>
	<figure>	<figure>

	<name>A YAML stream containing two YAML documents.</name>	<name>A YAML Stream Containing Two YAML Documents</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	one: &foo scalar	one: &foo scalar
	two: &bar	two: &bar
	- some	- some
	- sequence	- sequence
	- items	- items
	...	...
	%YAML 1.2	%YAML 1.2
	---	---
	&document_2	&document_2
	one: &foo [a, sequence]	one: &foo [a, sequence]
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section anchor="media-type-and-structured-syntax-suffix-registrations">	<section anchor="media-type-and-structured-syntax-suffix-registrations">

	<name>Media Type and Structured Syntax Suffix registrations</name>	<name>Media Type and Structured Syntax Suffix Registrations</name>
	<t>This section describes the information required to register
	the above media type according to <xref target="MEDIATYPE"/></t>	<t> This section includes the information required for IANA to register
		the <tt>application/yaml</tt> media type and the <tt>+yaml</tt> structured
		syntax suffix
		per <xref target="RFC6838"/>.</t>

	<section anchor="application-yaml">	<section anchor="application-yaml">

	<name>Media Type application/yaml</name>	<name>Media Type <tt>application/yaml</tt></name>
	<t>The media type for YAML text is <tt>application/yaml</tt>;	<t>The media type for YAML is <tt>application/yaml</tt>;
	the following information serves as the registration form for this media type.</ t>	the following information serves as the registration form for this media type.</ t>
	<dl>	<dl>
	<dt>Type name:</dt>	<dt>Type name:</dt>
	<dd>	<dd>
	<t>application</t>	<t>application</t>
	</dd>	</dd>
	<dt>Subtype name:</dt>	<dt>Subtype name:</dt>
	<dd>	<dd>
	<t>yaml</t>	<t>yaml</t>
	</dd>	</dd>
	<dt>Required parameters:</dt>	<dt>Required parameters:</dt>
	<dd>	<dd>
	<t>N/A</t>	<t>N/A</t>
	</dd>	</dd>

	</dl>
	<!-- RFC 6838:
	"N/A", written exactly that way, can be used in any field if desired
	to emphasize the fact that it does not apply or that the question was
	not omitted by accident. Do not use 'none' or other words that could
	be mistaken for a response.
	-->

	<dl>
	<dt>Optional parameters:</dt>	<dt>Optional parameters:</dt>
	<dd>	<dd>

	<t>N/A; unrecognized parameters should be ignored</t>	<t>N/A; unrecognized parameters should be ignored.</t>
	</dd>	</dd>
	<dt>Encoding considerations:</dt>	<dt>Encoding considerations:</dt>
	<dd>	<dd>
	<t>binary</t>	<t>binary</t>
	</dd>	</dd>
	<dt>Security considerations:</dt>	<dt>Security considerations:</dt>
	<dd>	<dd>

	<t>see <xref target="security-considerations"/> of this document</t>	<t>See <xref target="security-considerations"/> of this document.</t >
	</dd>	</dd>
	<dt>Interoperability considerations:</dt>	<dt>Interoperability considerations:</dt>
	<dd>	<dd>

	<t>see <xref target="interoperability-considerations"/> of this docu ment</t>	<t>See <xref target="interoperability-considerations"/> of this docu ment.</t>
	</dd>	</dd>
	<dt>Published specification:</dt>	<dt>Published specification:</dt>
	<dd>	<dd>
	<t><xref target="YAML"/>, this document</t>	<t><xref target="YAML"/>, this document</t>
	</dd>	</dd>
	<dt>Applications that use this media type:</dt>	<dt>Applications that use this media type:</dt>
	<dd>	<dd>

	<t>Applications that need a human-friendly, cross language, Unicode	<t>Applications that need a human-friendly, cross-language, and Unic
	based data serialization language designed around the common native	ode-based data serialization language designed around the common data types of d
	data types of dynamic programming languages.</t>	ynamic programming languages.</t>
	</dd>	</dd>
	<dt>Fragment identifier considerations:</dt>	<dt>Fragment identifier considerations:</dt>
	<dd>	<dd>

	<t>See <xref target="application-yaml-fragment"/> of this document</ t>	<t>See <xref target="application-yaml-fragment"/> of this document.< /t>
	</dd>	</dd>

	</dl>
	<t>Additional information:</t>	<dt>Additional information:</dt>
	<ul spacing="normal">	<dd>
	<li>Deprecated alias names for this type: application/x-yaml, text/ya	<t><br/></t>
	ml, text/x-yaml.	<dl spacing="compact">
	These names are used, but not registered.</li>	<dt>Deprecated alias names for this
	<li>Magic number(s) N/A</li>	type:</dt><dd>application/x-yaml, text/yaml, and text/x-yaml. These
	<li>File extension(s): "yaml" (preferred), "yml". See <xref target="in	names are used but are not registered.</dd>
	t-yaml-filename-extension"/> of this document.</li>	<dt>Magic number(s):</dt><dd>N/A</dd>
	<li>Macintosh file type code(s): N/A</li>	<dt>File extension(s):</dt><dd>"yaml" (preferred) and "yml". See <xref
	<li>Windows Clipboard Name: YAML</li>	target="int-yaml-filename-extension"/> of this document.</dd>
	</ul>	<dt>Macintosh file type code(s):</dt><dd>N/A</dd>
	<dl>	<dt>Windows Clipboard Name:</dt><dd>YAML</dd>
		</dl>
		</dd>

	<dt>Person and email address to contact for further information:</dt>	<dt>Person and email address to contact for further information:</dt>
	<dd>	<dd>
	<t>See the Authors' Addresses section of this document.</t>	<t>See the Authors' Addresses section of this document.</t>
	</dd>	</dd>
	<dt>Intended usage:</dt>	<dt>Intended usage:</dt>
	<dd>	<dd>
	<t>COMMON</t>	<t>COMMON</t>
	</dd>	</dd>
	<dt>Restrictions on usage:</dt>	<dt>Restrictions on usage:</dt>
	<dd>	<dd>

	<t>None.</t>	<t>None</t>
	</dd>	</dd>
	<dt>Author:</dt>	<dt>Author:</dt>
	<dd>	<dd>
	<t>See the Authors' Addresses section of this document.</t>	<t>See the Authors' Addresses section of this document.</t>
	</dd>	</dd>
	<dt>Change controller:</dt>	<dt>Change controller:</dt>
	<dd>	<dd>
	<t>IETF</t>	<t>IETF</t>
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>
	<section anchor="suffix-yaml">	<section anchor="suffix-yaml">

	<name>The +yaml Structured Syntax Suffix</name>	<name>The <tt>+yaml</tt> Structured Syntax Suffix</name>
	<t>The suffix	<t>The suffix

	<tt>+yaml</tt> MAY be used with any media type whose representation follows	<tt>+yaml</tt> <bcp14>MAY</bcp14> be used with any media type whose representati on follows
	that established for <tt>application/yaml</tt>.	that established for <tt>application/yaml</tt>.

	The media type structured syntax suffix registration form follows.	The structured syntax suffix registration form follows.
	See <xref target="MEDIATYPE"/> for definitions of each of the registration form	See <xref target="RFC6838"/> for definitions of each part of the registra
	headings.</t>	tion form.</t>

	<dl>	<dl>
	<dt>Name:</dt>	<dt>Name:</dt>
	<dd>	<dd>
	<t>YAML Ain't Markup Language (YAML)</t>	<t>YAML Ain't Markup Language (YAML)</t>
	</dd>	</dd>
	<dt>+suffix:</dt>	<dt>+suffix:</dt>
	<dd>	<dd>

	<t>+yaml</t>	<t><tt>+yaml</tt></t>
	</dd>	</dd>
	<dt>References:</dt>	<dt>References:</dt>
	<dd>	<dd>
	<t><xref target="YAML"/>, this document</t>	<t><xref target="YAML"/>, this document</t>
	</dd>	</dd>
	<dt>Encoding considerations:</dt>	<dt>Encoding considerations:</dt>
	<dd>	<dd>

	<t>Same as "application/yaml"</t>	<t>Same as <tt>application/yaml</tt></t>
		</dd>
		<dt>Interoperability considerations:</dt>
		<dd>
		<t>Same as <tt>application/yaml</tt></t>
	</dd>	</dd>
	<dt>Fragment identifier considerations:</dt>	<dt>Fragment identifier considerations:</dt>
	<dd>	<dd>

	<t>Differently from <tt>application/yaml</tt>,	<t>Unlike <tt>application/yaml</tt>,
	there is no fragment identification syntax defined	there is no fragment identification syntax defined

	for +yaml.	for <tt>+yaml</tt>.
	</t>	</t>
	<t>A specific <tt>xxx/yyy+yaml</tt> media type	<t>A specific <tt>xxx/yyy+yaml</tt> media type
	needs to define the syntax and semantics for fragment identifiers	needs to define the syntax and semantics for fragment identifiers

	because the ones defined for "application/yaml"	because the ones defined for <tt>application/yaml</tt>
	do not apply unless explicitly expressed.</t>	do not apply unless explicitly expressed.</t>
	</dd>	</dd>

	<dt>Interoperability considerations:</dt>
	<dd>
	<t>Same as "application/yaml"</t>
	</dd>
	<dt>Security considerations:</dt>	<dt>Security considerations:</dt>
	<dd>	<dd>

	<t>Same as "application/yaml"</t>	<t>Same as <tt>application/yaml</tt></t>
	</dd>	</dd>
	<dt>Contact:</dt>	<dt>Contact:</dt>
	<dd>	<dd>
	<t>httpapi@ietf.org or art@ietf.org</t>	<t>httpapi@ietf.org or art@ietf.org</t>
	</dd>	</dd>
	<dt>Author:</dt>	<dt>Author:</dt>
	<dd>	<dd>

	<t>See the Authors' Addresses section of this document</t>	<t>See the Authors' Addresses section of this document.</t>
	</dd>	</dd>
	<dt>Change controller:</dt>	<dt>Change controller:</dt>
	<dd>	<dd>
	<t>IETF</t>	<t>IETF</t>
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>
	<section anchor="interoperability-considerations">	<section anchor="interoperability-considerations">
	<name>Interoperability Considerations</name>	<name>Interoperability Considerations</name>
	<section anchor="int-yaml-evolving">	<section anchor="int-yaml-evolving">

	<name>YAML is an Evolving Language</name>	<name>YAML Is an Evolving Language</name>
	<t>YAML is an evolving language and, over time,	<t>YAML is an evolving language, and over time,
	some features have been added and others removed.</t>	some features have been added and others removed.</t>

	<t>This <xref target="YAML"/> media type registration is independent of
	YAML version.	<t>The <tt>application/yaml</tt> media type registration is independent of the Y
		AML version.
	This allows content negotiation of version-independent YAML resources.</t>	This allows content negotiation of version-independent YAML resources.</t>
	<t>Implementers concerned about features related to a specific YAML vers ion	<t>Implementers concerned about features related to a specific YAML vers ion
	can specify it in YAML documents using the <tt>%YAML</tt> directive	can specify it in YAML documents using the <tt>%YAML</tt> directive
	(see Section 6.8.1 of <xref target="YAML"/>).</t>	(see Section 6.8.1 of <xref target="YAML"/>).</t>
	</section>	</section>
	<section anchor="int-yaml-streams">	<section anchor="int-yaml-streams">

	<name>YAML streams</name>	<name>YAML Streams</name>
	<t>A YAML stream can contain zero or more YAML documents.</t>	<t>A YAML stream can contain zero or more YAML documents.</t>


	<t>When receiving a multi-document stream,	<t>When receiving a multi-document stream,

	an application that only expects one-document streams,	an application that only expects single-document streams
	ought to signal an error instead of ignoring the extra documents.</t>	should signal an error instead of ignoring the extra documents.</t>
	<t>Current implementations consider different documents in a stream inde
	pendent,	<t>Current implementations consider different documents in a stream independent,
	similarly to JSON Text Sequences (see <xref target="RFC7464"/>);	similarly to JSON text sequences (see <xref target="RFC7464"/>);
	elements such as anchors are not guaranteed to be referenceable	elements such as anchors are not guaranteed to be referenceable
	across different documents.</t>	across different documents.</t>
	</section>	</section>
	<section anchor="int-yaml-filename-extension">	<section anchor="int-yaml-filename-extension">

	<name>Filename extension</name>	<name>Filename Extension</name>
	<t>The "yaml" filename extension is the preferred one;	<t>The "yaml" filename extension is the preferred one;
	it is the most popular and widely used on the web.	it is the most popular and widely used on the web.
	The "yml" filename extension is still used.	The "yml" filename extension is still used.
	The simultaneous usage of two filename extensions in the same context	The simultaneous usage of two filename extensions in the same context
	might cause interoperability issues	might cause interoperability issues
	(e.g., when both a "config.yaml" and a "config.yml" are present).</t>	(e.g., when both a "config.yaml" and a "config.yml" are present).</t>
	</section>	</section>
	<section anchor="int-yaml-and-json">	<section anchor="int-yaml-and-json">
	<name>YAML and JSON</name>	<name>YAML and JSON</name>

	<t>When using flow collection styles (see Section 7.4 of <xref target="Y	<t>When using flow collection styles (see Section 7.4 of <xref target="Y
	AML"/>)	AML"/>),
	a YAML document could look like JSON <xref target="JSON"/>,	a YAML document could look like JSON <xref target="RFC8259"/>;
	thus similar interoperability considerations apply.</t>	thus, similar interoperability considerations apply.</t>
	<t>When using YAML as a more efficient format	<t>When using YAML as a more efficient format
	to serialize information intended to be consumed as JSON,	to serialize information intended to be consumed as JSON,
	information not reflected in the representation graph	information not reflected in the representation graph

	and classified as presentation or serialization detail	and classified as presentation or serialization details
	(see Section 3.2 of <xref target="YAML"/>) can be discarded.	(see Section 3.2 of <xref target="YAML"/>) can be discarded.
	This includes comments (see Section 3.2.3.3 of <xref target="YAML"/>),	This includes comments (see Section 3.2.3.3 of <xref target="YAML"/>),
	directives, and alias nodes (see Section 7.1 of <xref target="YAML"/>)	directives, and alias nodes (see Section 7.1 of <xref target="YAML"/>)
	that do not have a JSON counterpart.</t>	that do not have a JSON counterpart.</t>
	<figure anchor="example-json-discards-information">	<figure anchor="example-json-discards-information">

	<name>JSON replaces alias nodes with static values.</name>	<name>JSON Replaces Alias Nodes with Static Values</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	# This comment will be lost	# This comment will be lost
	# when serializing in JSON.	# when serializing in JSON.
	Title:	Title:
	type: string	type: string
	maxLength: &text_limit 64	maxLength: &text_limit 64

	Name:	Name:
	type: string	type: string
	maxLength: *text_limit # Replaced by the value 64.	maxLength: *text_limit # Replaced by the value 64.
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<t>Implementers need to ensure that relevant	<t>Implementers need to ensure that relevant

	information will not be lost during the processing.	information will not be lost during processing.
	For example, they might consider acceptable	For example, they might consider
	that alias nodes are replaced by static values.</t>	alias nodes being replaced by static values as acceptable.</t>
	<t>In some cases an implementer may want to	<t>In some cases, an implementer may want to
	define a list of allowed YAML features,	define a list of allowed YAML features,

	taking into account that the following ones	taking into account that the following features might have interoperability
	might have interoperability	issues with <xref target="RFC8259"/>:</t>
	issues with <xref target="JSON"/>:</t>
	<ul spacing="normal">	<ul spacing="normal">

	<li>multi-document YAML streams;</li>	<li>multi-document YAML streams</li>
	<li>non UTF-8 encoding. Before encoding YAML streams in UTF-16 or UTF-	<li>non-UTF-8 encoding. Before encoding YAML streams in UTF-16 or UTF-
	32,	32,
	it is important to note that <xref section="8.1" sectionFormat="of" target="JSON	it is important to note that <xref section="8.1" sectionFormat="of" target="RFC8
	"/> mandates the use of UTF-8	259"/> mandates the use of UTF-8
	when exchanging JSON texts between systems that are not part of a closed ecosyst	when exchanging JSON texts between systems that are not part of a closed ecosyst
	em,	em
	and that Section 5.2 of <xref target="YAML"/> recommends the use of UTF-8;</li>	and that Section 5.2 of <xref target="YAML"/> recommends the use of UTF-8.</li>
	<li>mapping keys that are not strings;</li>	<li>mapping keys that are not strings</li>
	<li>circular references represented using anchor (see <xref target="se	<li>cyclic references represented using anchors (see <xref target="sec
	c-yaml-exhaustion"/>	-yaml-exhaustion"/>
	and <xref target="example-yaml-cyclic"/>);</li>	and <xref target="example-yaml-cyclic"/>)</li>
	<li>	<li>

	<tt>.inf</tt> and <tt>.nan</tt> float values, since JSON does not su pport them;</li>	<tt>.inf</tt> and <tt>.nan</tt> float values, since JSON does not su pport them</li>
	<li>non-JSON types,	<li>non-JSON types,
	including the ones associated with tags like <tt>!!timestamp</tt>	including the ones associated with tags like <tt>!!timestamp</tt>

	that were included in the default schema of older YAML versions;</li>	that were included in the default schema of older YAML versions</li>
	<li>tags in general, and specifically the ones that do not map	<li>tags in general, specifically ones that do not map to JSON
	to JSON types like	types, e.g., custom and local tags such as <tt>!!python/object</tt>
	custom and local tags such as <tt>!!python/object</tt> and	and <tt>!mytag</tt> (see Section 2.4 of <xref target="YAML"/>)</li>
	<tt>!mytag</tt> (see Section 2.4 of <xref target="YAML"/>);</li>
	</ul>	</ul>
	<figure anchor="example-unsupported-keys">	<figure anchor="example-unsupported-keys">

	<name>Example of mapping keys and values not supported in JSON in a mu	<name>Example of Mapping Keys and Values Not Supported in JSON in a Mu
	lti-document YAML stream</name>	lti&nbhy;Document YAML Stream</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	non-json-keys:	non-json-keys:
	0: a number	0: a number
	[0, 1]: a sequence	[0, 1]: a sequence
	? {k: v}	? {k: v}
	: a map	: a map
	---	---
	non-json-keys:	non-json-keys:
	!date 2020-01-01: a timestamp	!date 2020-01-01: a timestamp
	non-json-value: !date 2020-01-01	non-json-value: !date 2020-01-01
	...	...
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="int-fragment">	<section anchor="int-fragment">

	<name>Fragment identifiers</name>	<name>Fragment Identifiers</name>
	<t>To allow fragment identifiers to traverse alias nodes,	<t>To allow fragment identifiers to traverse alias nodes, the YAML
	the YAML representation graph needs to be generated before the fragment identifi	representation graph needs to be generated before the fragment
	er evaluation.	identifier evaluation. It is important that this evaluation does not
	It is important that this evaluation will not cause the issues mentioned in <xre	cause the issues mentioned in Sections <xref
	f target="int-yaml-and-json"/>	target="int-yaml-and-json" format="counter"/> and <xref
	and in <xref target="security-considerations">Security considerations</xref> suc	target="security-considerations" format="counter"/>, such as infinite lo
	h as infinite loops and unexpected code execution.</t>	ops and
		unexpected code execution.</t>
	<t>Implementers need to consider that the YAML version and supported fea tures (e.g., merge keys)	<t>Implementers need to consider that the YAML version and supported fea tures (e.g., merge keys)
	can affect the generation of the representation graph (see <xref target="example -merge-keys"/>).</t>	can affect the generation of the representation graph (see <xref target="example -merge-keys"/>).</t>

	<t>In <xref target="application-yaml"/>, this document extends the use o
	f specifications based on	<t>In <xref target="application-yaml-fragment"/>, this document extends the use
		of specifications based on
	the JSON data model with support for YAML fragment identifiers.	the JSON data model with support for YAML fragment identifiers.

	This is to improve the interoperability of already consolidated practices,	This is to improve the interoperability of already-consolidated practices,
	such as the one of writing <xref target="OAS">OpenAPI documents</xref> in YAML.<	such as writing <xref target="OAS">OpenAPI documents</xref> in YAML.</t>
	/t>	<t><xref target="ex-fragid"/> provides a non-exhaustive list of examples
	<t><xref target="ex-fragid"/> provides a non-exhaustive list of examples	to help
	that could help	readers understand interoperability issues related to fragment identifiers.</t>
	understand interoperability issues related to fragment identifiers.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="security-considerations">	<section anchor="security-considerations">
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>Security requirements for both media type and media type suffix	<t>Security requirements for both media types and media type suffixes
	registrations are discussed in Section 4.6 of <xref target="MEDIATYPE"/>.</t>	are discussed in <xref target="RFC6838" sectionFormat="of" section="4.6"/>.</t>
	<section anchor="sec-yaml-code-execution">	<section anchor="sec-yaml-code-execution">
	<name>Arbitrary Code Execution</name>	<name>Arbitrary Code Execution</name>

	<t>Care should be used when using YAML tags,	<t>Care should be used when using YAML tags because their resolution
	because their resolution might trigger unexpected code execution.</t>	might trigger unexpected code execution.</t>
	<t>Code execution in deserializers should be disabled by default,
		<t>Code execution in deserializers should be disabled by default
	and only be enabled explicitly.	and only be enabled explicitly.

	In those cases, the implementation should ensure - for example, via specific fun ctions -	In the latter case, the implementation should ensure (for example, via specific functions)
	that the code execution results in strictly bounded time/memory limits.</t>	that the code execution results in strictly bounded time/memory limits.</t>

	<t>Many implementations provide safe deserializers addressing these issu es.</t>	<t>Many implementations provide safe deserializers that address these is sues.</t>
	</section>	</section>
	<section anchor="sec-yaml-exhaustion">	<section anchor="sec-yaml-exhaustion">
	<name>Resource Exhaustion</name>	<name>Resource Exhaustion</name>
	<t>YAML documents are rooted, connected, directed graphs	<t>YAML documents are rooted, connected, directed graphs
	and can contain reference cycles,	and can contain reference cycles,
	so they can't be treated as simple trees (see Section 3.2.1 of <xref target="YAM L"/>).	so they can't be treated as simple trees (see Section 3.2.1 of <xref target="YAM L"/>).
	An implementation that treats them as simple trees	An implementation that treats them as simple trees
	risks going into an infinite loop while traversing the YAML representation graph .	risks going into an infinite loop while traversing the YAML representation graph .
	This can happen:</t>	This can happen:</t>
	<ul spacing="normal">	<ul spacing="normal">

	<li>when trying to serialize it as JSON;</li>	<li>when trying to serialize it as JSON or </li>
	<li>or when searching/identifying nodes using specifications based on	<li>when searching/identifying nodes using specifications based on the
	the JSON data model (e.g., <xref target="JSON-POINTER"/>).</li>	JSON data model (e.g., <xref target="RFC6901"/>).</li>
	</ul>	</ul>
	<figure anchor="example-yaml-cyclic">	<figure anchor="example-yaml-cyclic">

	<name>A cyclic document</name>	<name>A Cyclic Document</name>
	<sourcecode type="yaml"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	x: &x	x: &x
	y: *x	y: *x
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>

	<t>Even if a representation graph is not cyclic, treating it as a simple
	tree could lead to improper behaviors	<t>Even if a representation graph is not cyclic, treating it as a
	(such as the "billion laughs"	simple tree could lead to improper behaviors, such as triggering an
	or "Exponential Entity Expansion" problem).</t>	Exponential Data Expansion (e.g., a Billion Laughs Attack).
		</t>
	<figure anchor="example-yaml-1e9lol">	<figure anchor="example-yaml-1e9lol">

	<name>A billion laughs document</name>	<name>A Billion Laughs Document</name>
	<sourcecode type="yaml"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	x1: &a1 ["a", "a"]	x1: &a1 ["a", "a"]
	x2: &a2 [a1, a1]	x2: &a2 [a1, a1]
	x3: &a3 [a2, a2]	x3: &a3 [a2, a2]
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>

	<t>This can be addressed using processors limiting the anchor recursion	<t>This can be addressed using processors that limit the anchor recursio
	depth	n depth
	and validating the input before processing it;	and validate the input before processing it;
	even in these cases it is important	even in these cases, it is important
	to carefully test the implementation you are going to use.	to carefully test the implementation you are going to use.
	The same considerations apply when serializing a YAML representation graph	The same considerations apply when serializing a YAML representation graph
	in a format that does not support reference cycles (see <xref target="int-yaml-a nd-json"/>).</t>	in a format that does not support reference cycles (see <xref target="int-yaml-a nd-json"/>).</t>
	</section>	</section>
	<section anchor="yaml-streams">	<section anchor="yaml-streams">

	<name>YAML streams</name>	<name>YAML Streams</name>
	<t>Incremental parsing and processing of a YAML stream can produce parti al results	<t>Incremental parsing and processing of a YAML stream can produce parti al results
	and later indicate failure to parse the remainder of the stream;	and later indicate failure to parse the remainder of the stream;
	to prevent partial processing, implementers might prefer validating and processi ng all the documents in a stream at the same time.</t>	to prevent partial processing, implementers might prefer validating and processi ng all the documents in a stream at the same time.</t>
	<t>Repeated parsing and re-encoding of a YAML stream can result	<t>Repeated parsing and re-encoding of a YAML stream can result
	in the addition or removal of document delimiters (e.g., <tt>---</tt> or <tt>... </tt>)	in the addition or removal of document delimiters (e.g., <tt>---</tt> or <tt>... </tt>)

	as well as the modification of anchor names and other serialization details,	as well as the modification of anchor names and other serialization details that
	which can break signature validation.</t>	can break signature validation.</t>
	</section>	</section>
	<section anchor="expressing-booleans">	<section anchor="expressing-booleans">

	<name>Expressing booleans</name>	<name>Expressing Booleans</name>
	<t>Section 10.3.2 of <xref target="YAML"/> specifies that only the scala rs matching the	<t>Section 10.3.2 of <xref target="YAML"/> specifies that only the scala rs matching the
	regular expression <tt>true\|True\|TRUE\|false\|False\|FALSE</tt> are interpreted as booleans.	regular expression <tt>true\|True\|TRUE\|false\|False\|FALSE</tt> are interpreted as booleans.

	Older YAML versions were more tolerant (e.g., interpreting <tt>NO</tt> and <tt>N	Older YAML versions were more tolerant (e.g., interpreting <tt>NO</tt> and <tt>N
	</tt> as <tt>False</tt>,	</tt> as <tt>False</tt> and interpreting
	and <tt>YES</tt> and <tt>Y</tt> as <tt>True</tt>).	<tt>YES</tt> and <tt>Y</tt> as <tt>True</tt>).
	When the older syntax is used, a YAML implementation could then interpret	When the older syntax is used, a YAML implementation could then interpret
	<tt>{insecure: n}</tt> as <tt>{insecure: "n"}</tt> instead of <tt>{insecure: fal se}</tt>.	<tt>{insecure: n}</tt> as <tt>{insecure: "n"}</tt> instead of <tt>{insecure: fal se}</tt>.
	Using the syntax defined in Section 10.3.2 of <xref target="YAML"/> prevents the se issues.</t>	Using the syntax defined in Section 10.3.2 of <xref target="YAML"/> prevents the se issues.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>This specification defines the following new Internet media type <xref	<t> IANA has updated the <eref
	target="MEDIATYPE"/>.</t>	target="https://www.iana.org/assignments/media-types">"Media Types"
	<t>IANA is asked to update the "Media Types" registry at <eref target="htt	registry</eref> with the registration information in <xref
	ps://www.iana.org/assignments/media-types">https://www.iana.org/assignments/medi	target="application-yaml"/> for the
	a-types</eref>	media type <tt>application/yaml</tt>.
	with the registration information provided in the section below.</t>	</t>
	<table>
	<thead>	<t>IANA has updated the <eref
	<tr>	target="https://www.iana.org/assignments/media-type-structured-suffix">"St
	<th align="left">Media Type</th>	ructured
	<th align="left">Registration information section</th>	Syntax Suffixes" registry</eref> with the registration information in
	</tr>	<xref target="suffix-yaml"/> for the structured syntax suffix
	</thead>	<tt>+yaml</tt>.</t>
	<tbody>
	<tr>
	<td align="left">application/yaml</td>
	<td align="left">
	<xref target="application-yaml"/> of this document</td>
	</tr>
	</tbody>
	</table>
	<t>IANA is asked to update the "Structured Syntax Suffixes" registry at <e
	ref target="https://www.iana.org/assignments/media-type-structured-suffix">https
	://www.iana.org/assignments/media-type-structured-suffix</eref>
	with the registration information provided in the section below.</t>
	<table>
	<thead>
	<tr>
	<th align="left">Suffix</th>
	<th align="left">Registration information section</th>
	</tr>
	</thead>
	<tbody>
	<tr>
	<td align="left">+yaml</td>
	<td align="left">
	<xref target="suffix-yaml"/> of this document</td>
	</tr>
	</tbody>
	</table>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>

		<displayreference target="RFC3986" to="URI"/>
		<displayreference target="RFC3629" to="UTF-8"/>
		<displayreference target="RFC6838" to="MEDIATYPE"/>
		<displayreference target="RFC6901" to="JSON-POINTER"/>
		<displayreference target="RFC9110" to="HTTP"/>
		<displayreference target="RFC8259" to="JSON"/>

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>


		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"
		/>

	<reference anchor="YAML" target="https://yaml.org/spec/1.2.2/">	<reference anchor="YAML" target="https://yaml.org/spec/1.2.2/">
	<front>	<front>
	<title>YAML Ain't Markup Language Version 1.2</title>	<title>YAML Ain't Markup Language Version 1.2</title>

	<author initials="" surname="Oren Ben-Kiki">	<author initials="O" surname="Ben-Kiki">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Clark Evans">	<author initials="C" surname="Evans">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Ingy dot Net">	<author initials="I" surname="dot Net">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Tina Müller">	<author initials="T" surname="Müller">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Pantelis Antoniou">	<author initials="P" surname="Antoniou">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Eemeli Aro">	<author initials="E" surname="Aro">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Thomas Smith">	<author initials="T" surname="Smith">
	<organization/>	<organization/>
	</author>	</author>
	<date year="2021" month="October" day="01"/>	<date year="2021" month="October" day="01"/>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="OAS">
		<reference anchor="OAS">
	<front>	<front>

	<title>OpenAPI Specification 3.0.0</title>	<title>OpenAPI Specification</title>
	<author initials="" surname="Darrel Miller">	<author initials="D" surname="Miller">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Jeremy Whitlock">	<author initials="J" surname="Whitlock">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Marsh Gardiner">	<author initials="M" surname="Gardiner">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Mike Ralphson">	<author initials="M" surname="Ralphson">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Ron Ratovsky">	<author initials="R" surname="Ratovsky">
	<organization/>	<organization/>
	</author>	</author>

	<author initials="" surname="Uri Sarid">	<author initials="U" surname="Sarid">
	<organization/>	<organization/>
	</author>	</author>
	<date year="2017" month="July" day="26"/>	<date year="2017" month="July" day="26"/>
	</front>	</front>

	</reference>	<refcontent>v3.0.0</refcontent>
	<reference anchor="JSON-POINTER">
	<front>
	<title>JavaScript Object Notation (JSON) Pointer</title>
	<author fullname="P. Bryan" initials="P." role="editor" surname="Bry
	an"/>
	<author fullname="K. Zyp" initials="K." surname="Zyp"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham"/>
	<date month="April" year="2013"/>
	<abstract>
	<t>JSON Pointer defines a string syntax for identifying a specific
	value within a JavaScript Object Notation (JSON) document.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6901"/>
	<seriesInfo name="DOI" value="10.17487/RFC6901"/>
	</reference>
	<reference anchor="MEDIATYPE">
	<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="JSON">
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format
	</title>
	<author fullname="T. Bray" initials="T." role="editor" surname="Bray
	"/>
	<date month="December" year="2017"/>
	<abstract>
	<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
	language-independent data interchange format. It was derived from the ECMAScrip
	t Programming Language Standard. JSON defines a small set of formatting rules fo
	r the portable representation of structured data.</t>
	<t>This document removes inconsistencies with other specifications
	of JSON, repairs specification errors, and offers experience-based interoperabi
	lity guidance.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="90"/>
	<seriesInfo name="RFC" value="8259"/>
	<seriesInfo name="DOI" value="10.17487/RFC8259"/>
	</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>
	<reference anchor="HTTP">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="
	Fielding"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham"/>
	<author fullname="J. Reschke" initials="J." role="editor" surname="R
	eschke"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
	on-level protocol for distributed, collaborative, hypertext information systems.
	This document describes the overall architecture of HTTP, establishes common te
	rminology, and defines aspects of the protocol that are shared by all versions.
	In this definition are core protocol elements, extensibility mechanisms, and the
	"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
	<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
	232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="97"/>
	<seriesInfo name="RFC" value="9110"/>
	<seriesInfo name="DOI" value="10.17487/RFC9110"/>
	</reference>
	<reference anchor="URI">
	<front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
	"/>
	<author fullname="R. Fielding" initials="R." surname="Fielding"/>
	<author fullname="L. Masinter" initials="L." surname="Masinter"/>
	<date month="January" year="2005"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification de
	fines the generic URI syntax and a process for resolving URI references that mig
	ht be in relative form, along with guidelines and security considerations for th
	e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
	et of all valid URIs, allowing an implementation to parse the common components
	of a URI reference without knowing the scheme-specific requirements of every pos
	sible identifier. This specification does not define a generative grammar for UR
	Is; that task is performed by the individual specifications of each URI scheme.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="UTF-8">
	<front>
	<title>UTF-8, a transformation format of ISO 10646</title>
	<author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
	<date month="November" year="2003"/>
	<abstract>
	<t>ISO/IEC 10646-1 defines a large character set called the Univer
	sal Character Set (UCS) which encompasses most of the world's writing systems. T
	he originally proposed encodings of the UCS, however, were not compatible with m
	any current applications and protocols, and this has led to the development of U
	TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu
	ll US-ASCII range, providing compatibility with file systems, parsers and other
	software that rely on US-ASCII values but are transparent to other values. This
	memo obsoletes and replaces RFC 2279.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="63"/>
	<seriesInfo name="RFC" value="3629"/>
	<seriesInfo name="DOI" value="10.17487/RFC3629"/>
	</reference>	</reference>
	</references>	</references>
	<references>	<references>


	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="I-D.ietf-jsonpath-base">
	<front>
	<title>JSONPath: Query expressions for JSON</title>
	<author fullname="Stefan Gössner" initials="S." surname="Gössner">
	<organization>Fachhochschule Dortmund</organization>
	</author>
	<author fullname="Glyn Normington" initials="G." surname="Normington
	">
	</author>
	<author fullname="Carsten Bormann" initials="C." surname="Bormann">
	<organization>Universität Bremen TZI</organization>
	</author>
	<date day="25" month="August" year="2023"/>
	<abstract>
	<t> JSONPath defines a string syntax for selecting and extractin
	g JSON
	(RFC 8259) values from a JSON value.


	</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7464.xml"
	</abstract>	/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-base-20"/
	>
	</reference>
	<reference anchor="RFC7464">
	<front>
	<title>JavaScript Object Notation (JSON) Text Sequences</title>
	<author fullname="N. Williams" initials="N." surname="Williams"/>
	<date month="February" year="2015"/>
	<abstract>
	<t>This document describes the JavaScript Object Notation (JSON) t
	ext sequence format and associated media type "application/json-seq". A JSON tex
	t sequence consists of any number of JSON texts, all encoded in UTF-8, each pref
	ixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Fee
	d character (0x0A).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7464"/>
	<seriesInfo name="DOI" value="10.17487/RFC7464"/>
	</reference>
	</references>	</references>
	</references>	</references>

	<?line 553?>

	<section anchor="ex-fragid">	<section anchor="ex-fragid">

	<name>Examples related to fragment identifier interoperability</name>	<name>Examples Related to Fragment Identifier Interoperability</name>
	<section anchor="unreferenceable-nodes">	<section anchor="unreferenceable-nodes">

	<name>Unreferenceable nodes</name>	<name>Unreferenceable Nodes</name>
	<t>In this example, a couple of YAML nodes that cannot be referenced
	based on the JSON data model	<t> This example shows a couple of YAML nodes that cannot be
	since their mapping keys are not strings.</t>	referenced based on the JSON data model since their mapping keys are
		not strings.</t>
	<figure anchor="example-unsupported-paths">	<figure anchor="example-unsupported-paths">

	<name>Example of YAML nodes that are not referenceable based on JSON d	<name>Example of YAML Nodes That Are Not Referenceable Based on JSON D
	ata model.</name>	ata Model</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	a-map-cannot:	a-map-cannot:
	? {be: expressed}	? {be: expressed}
	: with a JSON Pointer	: with a JSON Pointer

	0: no numeric mapping keys in JSON	0: no numeric mapping keys in JSON
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="referencing-a-missing-node">	<section anchor="referencing-a-missing-node">

	<name>Referencing a missing node</name>	<name>Referencing a Missing Node</name>
	<t>In this example the fragment <tt>#/0</tt> does not reference an exist	<t>In this example, the fragment <tt>#/0</tt> does not reference an exis
	ing node</t>	ting node.</t>
	<figure anchor="example-missing-node">	<figure anchor="example-missing-node">

	<name>Example of a JSON Pointer that does not reference an existing no	<name>Example of a JSON Pointer That Does Not Reference an Existing No
	de.</name>	de</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	0: "JSON Pointer `#/0` references a string mapping key."	0: "JSON Pointer `#/0` references a string mapping key."
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="representation-graph-with-anchors-and-cyclic-references">	<section anchor="representation-graph-with-anchors-and-cyclic-references">

	<name>Representation graph with anchors and cyclic references</name>	<name>Representation Graph with Anchors and Cyclic References</name>
	<t>In this YAML document, the <tt>#/foo/bar/baz</tt> fragment identifier	<t>In this YAML document, the <tt>#/foo/bar/baz</tt> fragment identifier
	traverses the representation graph and references the string <tt>you</tt>.	traverses the representation graph and references the string <tt>you</tt>.
	Moreover, the presence of a cyclic reference implies that	Moreover, the presence of a cyclic reference implies that
	there are infinite fragment identifiers <tt>#/foo/bat/../bat/bar</tt>	there are infinite fragment identifiers <tt>#/foo/bat/../bat/bar</tt>
	referencing the <tt>&anchor</tt> node.</t>	referencing the <tt>&anchor</tt> node.</t>
	<figure anchor="example-cyclic-graph">	<figure anchor="example-cyclic-graph">

	<name>Example of a cyclic reference and alias nodes.</name>	<name>Example of a Cyclic Reference and Alias Nodes</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.2	%YAML 1.2
	---	---
	anchor: &anchor	anchor: &anchor
	baz: you	baz: you
	foo: &foo	foo: &foo
	bar: *anchor	bar: *anchor
	bat: *foo	bat: *foo
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>

	<t>Many YAML implementations will resolve
		<t>Many YAML implementations will resolve
	<eref target="https://yaml.org/type/merge.html">the merge key "<<:"</eref> defined in YAML 1.1	<eref target="https://yaml.org/type/merge.html">the merge key "<<:"</eref> defined in YAML 1.1
	in the representation graph.	in the representation graph.
	This means that the fragment <tt>#/book/author/given_name</tt> references the st ring <tt>Federico</tt>	This means that the fragment <tt>#/book/author/given_name</tt> references the st ring <tt>Federico</tt>
	and that the fragment <tt>#/book/<<</tt> will not reference any existing n ode.</t>	and that the fragment <tt>#/book/<<</tt> will not reference any existing n ode.</t>
	<figure anchor="example-merge-keys">	<figure anchor="example-merge-keys">

	<name>Example of YAML merge keys.</name>	<name>Example of YAML Merge Keys</name>
	<sourcecode type="example"><![CDATA[	<sourcecode type="yaml"><![CDATA[
	%YAML 1.1	%YAML 1.1
	---	---
	# Many implementations use merge keys.	# Many implementations use merge keys.
	the-viceroys: &the-viceroys	the-viceroys: &the-viceroys
	title: The Viceroys	title: The Viceroys
	author:	author:
	given_name: Federico	given_name: Federico
	family_name: De Roberto	family_name: De Roberto
	book:	book:
	<<: *the-viceroys	<<: *the-viceroys
	title: The Illusion	title: The Illusion
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	<section numbered="false" anchor="acknowledgements">	<section numbered="false" anchor="acknowledgements">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>

	<t>Thanks to Erik Wilde and David Biesack for being the initial contributo	<t>Thanks to <contact fullname="Erik Wilde"/> and <contact fullname="David
	rs of this specification,	Biesack"/> for being the initial contributors to this specification
	and to Darrel Miller and Rich Salz for their support during the adoption phase.<	and to <contact fullname="Darrel Miller"/> and <contact fullname="Rich Salz"/> f
	/t>	or their support during the adoption phase.</t>
	<t>In addition to the people above, this document owes a lot to the extens	<t>In addition, this document owes a lot to the
	ive discussion inside	extensive discussion inside and outside the HTTPAPI Working Group. The
	and outside the HTTPAPI workgroup.	following contributors helped improve this specification by opening
	The following contributors have helped improve this specification by	pull requests, reporting bugs, asking smart questions, drafting or
	opening pull requests, reporting bugs, asking smart questions,	reviewing text, and evaluating open issues: <contact fullname="Tina
	drafting or reviewing text, and evaluating open issues:</t>	(tinita) Müller"/>, <contact fullname="Ben Hutton"/>, <contact
	<t>Tina (tinita) Müller,	fullname="Carsten Bormann"/>, <contact fullname="Manu Sporny"/>, and
	Ben Hutton,	<contact fullname="Jason Desrosiers."/></t>
	Carsten Bormann,
	Manu Sporny
	and Jason Desrosiers.</t>
	</section>
	<section numbered="false" removeInRFC="true" anchor="faq">
	<name>FAQ</name>
	<dl>
	<dt>Q: Why this document?</dt>
	<dd>
	<t>After all these years, we still lack a proper media-type for YAML.
	This has some security implications too
	(eg. wrt on identifying parsers or treat downloads)</t>
	</dd>
	<dt>Q: Why using alias nodes as fragment identifiers?</dt>
	<dd>
	<t>Alias nodes are a native YAML feature that allows
	addressing any node in a YAML document.
	Since YAML is not limited to string keywords,
	not all nodes are addressable using JSON Pointers.
	Alias nodes are thus the natural choice for fragment identifiers
	<xref target="application-yaml-fragment"/>.</t>
	</dd>
	<dt>Q: Why not use plain names for alias nodes? Why not define plain nam
	es?</dt>
	<dd>
	<t>Using plain name fragments could have
	limited the ability of future xxx+yaml
	media types to define their plain name fragments.
	Moreover, alias nodes starts with <tt>*</tt> so we found no reason
	to strip it when using them in fragments.
	</t>
	<t>Preserving <tt>*</tt> had another positive result:
	it allows distinguishing
	a fragment identifier expressed as an alias node from
	one expressed in other formats.
	In this document we included JSON Pointer <xref target="JSON-POINTER"/>
	which is expected to start with <tt>/</tt>.
	Moreover, since JSON Path <xref target="I-D.ietf-jsonpath-base"/> expressions
	start with <tt>$</tt>, this mechanism can be extended to JSON Path too.</t>
	</dd>
	<dt>Q: Why not just use JSON Pointer as the primary fragment identifier?
	</dt>
	<dd>
	<t>Fragment identifiers in YAML always reference
	YAML representation graph nodes.
	JSON Pointer can only rely on string keywords so
	it is not able to reference a generic node in the
	representation graph.
	</t>
	<t>Since JSON Pointer is a specification unrelated to YAML,
	we decided to isolate the impacts of changes in JSON Pointer
	on YAML fragments:
	only fragments starting with "/" are "delegated" to an external spec,
	and if <xref target="JSON-POINTER"/> changes, it will only affect fragments star
	ting with "/".</t>
	<t>The current behaviour for empty fragments is the same
	for both JSON Pointer and alias nodes.
	Incidentally, it's the only sensible behaviour independently of <xref target="JS
	ON-POINTER"/>.</t>
	</dd>
	<dt>Q: Why describe the YAML/JSON so closely?</dt>
	<dd>
	<t>In the context of Web APIs, YAML is widely used as a more compact w
	ay to serialize
	content inteded to be consumed according to the JSON data model.
	Typical examples are OpenAPI specifications and Kubernetes manifest files,
	that can be serialized in both formats.
	The YAML media type registration I-D is a spin-off and a building block
	for the OpenAPI specification media type registration.
	The YAML/JSON section aims at clarifying what developers should expect when usin
	g YAML
	instead of JSON, and its content arose from common mistakes and FAQs.
	</t>
	<t>Please note that we are not imposing any normative restriction on Y
	AML streams;
	this is because YAML is defined outside this document.
	Instead, we only provide Interoperability and Security considerations that,
	by their nature, are not normative.</t>
	</dd>
	<dt>Q: Do we forbid using non-UTF-8 YAML serialization?</dt>
	<dd>
	<t>No. Since <xref target="JSON"/> recommends UTF-8 in interoperabilit
	y context
	we suggest that using UTF-8 is an interoperable behavior.
	This is aligned with Section 5.2 of <xref target="YAML"/> that explicitly
	recommends UTF-8.</t>
	</dd>
	<dt>Q: Why media type registration information is outside the IANA Consi
	derations?</dt>
	<dd>
	<t>We decided to follow the style adopted in <xref target="HTTP"/> whe
	re
	the IANA Considerations in <xref section="18.8" sectionFormat="of" target="HTTP"
	/>
	references the <tt>multipart/byteranges</tt> media type registration form
	contained in the specification body <xref section="14.6" sectionFormat="of" targ
	et="HTTP"/>.</t>
	</dd>
	</dl>
	</section>
	<section numbered="false" removeInRFC="true" anchor="change-log">
	<name>Change Log</name>
	<section numbered="false" anchor="since-draft-ietf-httpapi-yaml-mediatypes
	-02">
	<name>Since draft-ietf-httpapi-yaml-mediatypes-02</name>
	<ul spacing="normal">
	<li>clarification on fragment identifiers #50.</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpapi-yaml-mediatypes
	-01">
	<name>Since draft-ietf-httpapi-yaml-mediatypes-01</name>
	<ul spacing="normal">
	<li>application/yaml fragment identifiers compatible with JSON Pointer
	#41 (#47).</li>
	</ul>
	</section>
	</section>	</section>

	</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA7VcbXfbxrH+jl+xoe5NLIekLNlxHDltqthyo9ZvteT65Pj4
	hEtySaICARYLiGIc9bfcH3I/3fvH7jwzu8ACBOWkvc1pZQlY7M7Ozs7LM7M7
	GAyiIi4Sc6x+PHnxXL0w01iri83KRHo8zs3VcTTNJqleUoNprmfFIDbFbLAo
	ipVexYONXiaDJb4p6BM7OLwXTXRh5lm+OVZxOsuiKF7lx6rIS1sc3bv3zb2j
	SOdGH6uT1SqJqW2cpVbpdKreGJ0MLuKlidZZfjnPs3J1rH64uHh98vosujQb
	ejo9VmdpYfLUFIOnICaKbEHf/qSTLCUCN8ZGq/hYvS+ySV/RjzidmrToK5vl
	RW5mln7bLN0vRR5P6NUkW660+2VJjelVnCZxavqKJr7Uq1Wczj9EVyYtzXGk
	VIswpTDxY/WOaKaG6o94TU8XGTgGNtnjg4OpLnSR68mlyYfg3zDL5wfr+YFj
	44EeZ2VxQJ8tdZzIZ/T4D74pvdD5ZFH3h2Z4El+Zuj88OBjn2dqaqmP6Mjer
	rP5yHheLcjykyR7wQq7nfi0P6mU8SPTYJPYAqxvJF4PY2tIM+AUxGi8iXRaL
	LCemDGgYRWyzx+rNUL3OkiTmJyI2b7KxyYsseE7UHqunMfWsE3WR69TOsnzJ
	sqCempXOiyUv2xm9j3Wq/phd0aLjGX9uhEt5No5X6PMPczzAnPj1JCvTAvKH
	zzcN6k6H6l2cTE1A3WkeXwYPmbST67XehEMZajRco9EfprkphiSAzaHO13Hx
	s8kTEsb2gCd5Fg5nliaJq4c83Ivs5zhJdGNAbrZrYs9IQjFSlArbrlgysX+P
	uWG4oU/i9ItCvdD5ZblSz3U6L/XcqL+a3ILbh8Mj/oIElD44und0SFt4cO+Q
	H1brS/8NZD6vcpOq7006+HN8GYcvnpA8XqrTK1rL8PFZOt/QPirUS8cx9/wi
	TrV68b//nSQmD5+/1rS/k9iqk7TI0jgrw5ct3vmuaKtpq86XJKcye53PTVGL
	PISVN4hdmckBzXh4hH3x6uS8wa1XK5PSjlbn1CqeOdWk7g/vDe81WHT49eDe
	14Ojh7tY9FTnuUnUi7g9tz+Z3Cw36t2Cxssml+ErWh67UH/U+ZQUT+OjF/Gl
	UW90slrYLA1fvCHi3ugiu7KXm/D52zxW5zqPSQ7Vn85fvRy8fnX28uL0DX3x
	7MnDb2hpI+jlQG7OBk9ZiQz+RkOsdLEYjLWlN9FgMFB6bKG4SNNeLGhZSCWW
	2IekVeaxJVVso2JhlK6VObNbsS5h1RhBt6PNl/yCeisnRZmbKanitNDXypaz
	WXwd0XTQ6uzk5UlghKwbKN/0iezCkD6n3jI1Nqq08msMFR/PNjVtUOlkD0iX
	R5Z2LumQn6mpnkwy8HeOjzAUbw8brvZQ5ryMp9PERNEerE2eTYlgehlF/MF7
	/PygiBcaIqGVH0LkRThLTNEF2kz0So8To7IZUZVemQ3GJ9po46tlmRTxigby
	hFtaQerVUhv6ZJUbSw+lW+KA0cvojhnOh31qM4sT7kMrUkWwl8Qnm5X5xOwP
	ozMeek2MSTbCJs9cZzzBy0lSMjNieQXJt2ZSUJ9uEGuMek+b5MN+PxqXBQ1F
	/KNRiLX8Yb3EbL53Laxa6KlKSQPQfK5oQ1uiaWxIi3gJog/GG153Yv8FrWc6
	oblao7DeebYyuR7HSVxs1HpBn5nryYK0GCiQBWTO2D7LWWLIUEC/EbMLiEJK
	rkgRCw+XBl/GdmnbPcnKeg5SXwVkvSEaUSXwzK5RW+JHXSI/+lJe7eTNx4+f
	vTh9enZy8ePr099hfz66/+jmhvjwIssNjB45I+BcdkWLabFAZQ5O0PQsPcnF
	feLxtrjVbEOzS0iB8Y4REW4IQeEagE9kyhagDNoDRD06+uobJmpvT73MRCDJ
	bj+BPKdCACkHo8hHU3DSrOq9eHt+0evLv+rlK/79zelf3p69OX2K389/OHn+
	vPolci3Of3j19vnT+rf6yyevXrw4fflUPqanqvEo6r04+ZHegA29V68vzl69
	PHneE8kOdRY5nk53MLNIIMEQbSPi7SSPxwZcVN8/ef0//3X4ABygyR8dHtLk
	3R+PDr9+QH9AemS0LE027k9a701EUmF0zts4SbD54eGQR0n2yS6ydaoWJO9D
	cIvkW3i11BtqbDNVf9ukOk6jJFubnLqjj6inVaKp0SkpiZiMBvfSh55GY6Ii
	zlXlFpBQksSnczuMvv0OTq0aPPru95GsF7GAtoLqub0C1nZsGzz2O6Mnu6xH
	OoVUzxwfRb+ay5gZsRGOM6Tqm8PDeyxVNSm9Ge1d9NGTpfR/ehUfm/y3j/f2
	zRmGu//No4ft4UINi2mKKsFvrA/8CMKBhjqe53q1wPNCzyF/TRswNQW5bXie
	ZlODZnBjrar+SifkNLhJyh/sHf7Gyck2pik9i+ekWywrPRKNSjVOaDySLfJl
	SfzIKyp4a7PB7v0ntyBnqKemcU6KH9ICa7qEtjGkDfTUaRLZ+c/ai+EcpI97
	gSqUeNCv200UnajtRYTlBCuctWOmD7ub5kI3ZsRaqXeXeGS7OaJl0jWr1R2Y
	sI8ffbcDfjXAq5ubffCN+C7GdlAxvGVTOmnyxt0sV8UmytwDptQ6Og9uoxOK
	laIhfk70hV7azY0oc+r8Sicla2xnvJ2N2pbDfrTWCQefxYKiz/ki4IF9DJlC
	RBVPSnLRWU8J4V1TIys3Iw2VkhHkhnlGhhv9DMX9c9ZrQjEZq76qeU0hjyoc
	IeGFW6cVnMqKa0tNS0OxCLlE0jawXOTUVCLKXGIPa0nNEr+a1FqkjPjEHqus
	Zbf0xJZdD4p5cgQWYv5qojWcALLq4J2fJb0iH46ifx0CFM4gTc0MSpRUOb4t
	UyjG5ArrWnE8wgoUbunJvyBPcso7aPcWuiK/IVgy2lJdIus8cDhpomTEZlmm
	hoYjpRyFvTC/zl3r+4h6hkescr4eHoL5oj72I/qgg3UsvNRNPE9JCKVLZnN7
	k0EWxqYWTDGiWpHe7ZQw8vWI95lzO7D4xKlNQQSX2Ivq7cWzwSNW3PiFVffD
	IzLB4oSSlEzAl6oLmghFYGQYyZdDnALK3aqTCSa7yd4l5KkiJi/J52bjUHPn
	K3REJLOJOJtVvrnj5TorkylJbjFZqE6d0GeRncW5LVQ2IS9NBIw6tSV9I1/y
	6iU0JkvEWwtaSWdP4JNPRXFseXHUQ9fqIDrzQpnEFPo2BIhYirik4LCj4guw
	KuzBacbsyc3fS9L81WrgNQutucZSWtFWO5bRHnNvMTObHAEiOCF9sMqsjbGL
	aSknAFQC62bZmLXjJbGVj+vZwLsr4eiE8wHZwsPmwmCxRDuaa73EY++q0ERo
	9UXdiWfLRs3vfKdMvAA8oK3hBWBfjRBdDaFk9u7OsmwUBaarXuZgD4y4Gc2e
	li8IMPkdLyt0OTWzE006eMQqHkuARggGXQxGW5tiq8r4P47W0EZaQuyOSYR0
	+o9+OhqpFrmVEo94s2yNo0YfGT19rxH0/b1E3x9uRsTbf/zjH56xkao8hkhR
	kBwp/uZzmriSaUWKAlF6MtYMYAyUzZbG/eZ6lb/iwixJGIfD4Xann9fzCEdo
	kAayoo/Hgtv8rncS2uzQByJyVMORs8OeukFYX+MLrBDP6/DsXAzcuYRnDnvQ
	VZDTqX/B0gpSyVK/sZytkahRUJJxxi55HTeHkER3LMi+V0hvG2nZ9r9uxMkN
	xiHahBOFuWYbvB2+PhYFlkFnCixQT4h27BW2rxOngCkMd3D3rAvqIeFoY2QG
	PaPjkOwoOi/HRfhS0OQ3nm3krdCLgpXMsXp5cBJF3342GAC/UmAKo209ek6+
	9JrC4YJjedJxyUY0BTm8fW+XGP6AQUrJ4YkNafF4xnaNRkI/xHjyhhbaxj+L
	EzOjjpyvAlVpnC0h+jfKu3poR8JoJVzWjHiiVbYENWxxaGl5Gw6Veir6Fkrt
	i5Rk+gv0k1EfuQsBuc8JTAw6IqKXxGB9aZi9pDEFdLHEVNo+AwrfXq1cDL7F
	qsfslEyyecqYV/0e8SdsGPzROcWHNPvo1BvRJlSArsZxqvMNLVU34oAmokE9
	JDFoNqAomZVNEMtAVd8KUdSdtq3gr+n8dTlGPAyIJcRt0KnDO9pfNDJQvAZY
	opYg4/vthilcSa0W5VKnFO7Ehtw8yFxO9k8lDmTvq7dpjBiMlg2I6rQLL/SN
	na+FbsmHd/gRUlLUJmXFHyn5njM0YMB0QxsongAeojhgucRK+u5gGbfcTWAI
	Wxw/Z47vjuG6eH0yncZOAgM9wT7JU/iBE45bnIFk01+pCMmWNdTYNY/YZ+V0
	EPwqzyH0gpfUTgQ2dV/BHxRHxgOJwG/VCz0npqTlcmzyO3ZfiQYZqGeATKlf
	kyLzQW+OVQ8D9NSdFdtU6mCfovMNPRo6tlTBBiwtxh9UHXQwxg0/gU9rF4LR
	sqKDEPCAnpZ3cTrN1lY9SeLVONP5VL3k7BAElUSZ9iviJpICTgcpPZ3CI4Oy
	YvtGGgoMnZU5a5HGGsiKMqTLuQn7hTqRz01tvDooP/PoemlJftAPELZXL6GY
	JVfK4k8fVw1ekjJDTOByIP/syNETwLCC2eYZsibo6+z04lnE1u+iSh7sNNQf
	9wRQDe2fyyt4DPbFyY+VPWCfDBYhsJFrjiJa8bXYQytwPrFBex0D9m8b0WHb
	8O4EfruMKA81jETyKleA5AyDceQZuzWYKaPJF3bu3HZfC6OngvrR5mHJon9v
	zQfewbt9NP9SKJQvhO94/KYCBtybHUpVqZ1WBZ+dEzFwJHpt3vXw6a/RWOjl
	aTxjamDxZ3m27FiKvqT24EBLPLgdxbjo2y2MhPZsgZnhX4ry4b9PKpuiRtfX
	1webzebLLdCfc7xkF1zkzEABe9vSP+dIaDvT0BPRh11hFfcyJgUqpojDA+tp
	4686OMfZySzwU8o0gbqgQI5axuBSFdPxjD5piD+9VDsdg09/+kRUmDRtlzpw
	Uisv6tIHanVSJVn/KRUT8aDbOobFWNTM3jZLnjRTLFBEvH+Q+EvV6VWWXEHI
	qx30ca8yFsa9vHEpQ/nEP61NPolEXyHLQ6HM0vQjBExqZnTBaO5CXxnJlJH6
	hzlFvgECjVTNkj6bDl1I4lKSgd5pqAQE6aTZV4aLYcAepupKSgAcssdgie3M
	m9EHru0g7KeZM4MFQZwIhjdxDa5tqacV5KF0va1CiiK47vJmIxBRK4xzSBFn
	2DiAHNUYdtSAvR4OHzXArmG9jg7jDdfNPbqpYC4fUxI9Lq5UP5OUcPKWXOh2
	dBlF7xac2JyYmFdaC1xRo8vSIbIooQckPiUDqrRPiXSYWdP+yvZraJFhuYSl
	Ks8zeADkAOkpZsrevWcPeSu5blD4hKGpAji/LJZza/02Jk463araaWlhRiAC
	JLHxEoVICLwyAWwvEGGeu1DdepzlO4rdvn7w8MHNzf7jyMjAVqAxIOIMEolr
	tw3XjgPIAwhxpMXN7iDUZSqcr1Y7e+Eid3hy4i84Z3C2/XUsgW/lJWJ1Hkdx
	4V8sM1uoVbYCwM7btCP1vjbjoRtm9ygUUCYJfyZtib0kPzo1WWnF7WLlts46
	vrcVioTHvI+vi2gZQ2LEnGxhi1zSZX1RAefExxk8I04EzuL5UFiCKQXP+FFe
	FSiEmwotWQwChlc4vdsesnlnpG6IyiRxO9UWm6QNWn89fNAAqpv7TSJmlWTZ
	pUpQJcMDv8fPD4BjiWVOPD+ZG2erOWzQJ9NBtoZ3uiGfaBJjVF/gkVWBXBP9
	aVWpYCQil7FUkNaPwsYSvswEE/YL2JXjYchwkmhr4Sdwb41GyGR14KpROwkQ
	8NMjJNPYTigCEZljW4GqAE4nSkHkdibh/vB+0FE/qrSvlbT4zjREK/UQwtFs
	7lxujAvdTI601adQSIQHcUUr7TzaQDSphLYkXrJQe864chcMQVHlBZd9MQbE
	MSmCHEbB1VJfPzfpvFgcq8+xi34ShP3hA3IkvDd920d3g4+IhjdmlehJnYgQ
	MPjhg2ELyOSp59LYNnjI8YrFUk/kayCZe44nvLkGbhXtIBCvm5ZNTp1GJYVR
	Iq8M7pM5NlekbBtiyVzEojhOqmlZmZRVnhF52CNDTqA6KqQAQjl9442JnkzM
	qmCtLRnBYFJQIXnAmub8GNhnhwhlD+xAxfVcuGpirVHwkEXO19akBSy7Nz7x
	w6LiHQ9SCfpSJACux4RlrIbzauQTHrfTmyyTbeURidr0ZTJYtZsbxj5axj50
	M5DgSImzkt3yKZeh+p6TjXVGrOGaxNL+8CG2N367f4SwRgwPcSPLC2EB1sqt
	Z53TcJ6P0EcMS1HAKAYL1gDpDhBDHbbrqlgQIcOWBKBYwwW1GwvUvsrrSkUX
	SgrAb9JMGWydmWTSsM+pn6k09wR9FaofeEm8Z6fbJIFZrvAaRUWtUWXLMUcn
	cc5ZbRWkrcNEpKhyl4O6UwGWzku/XpBZ5H1y48j9+NHvKW4x2UzIRWOfZaBG
	Q9ohI242GqY6HcGEEVkir33JeLmktUeNbbnCImGCSycBA2EuMDxey6oEqwr2
	SMdnk5h9ZBaxQs+tGLjRZ58hUKCNslyNfDZvzRGu6OzKhNCW0CSMyk5oZA3G
	Zgn2Y+hmMwe5c/rIpfBEfVcAapJsarpCZU2rI+nCejZMIj2cEE8pIudqvIy6
	kCG8q0dTWG0ocksPsvHfSC6YofTV6LPlhhqOmubiqOEAPP6EKQB3WRdCZlhH
	3ztGqQkjgfjz/b2+OvxwzDnIOiH1nfp4eayuIAMK73huOzr8DHsIZdKokab/
	oX21JMEHLBTHW80l6dXU+qcucUnzbMg8GCiyFYqSLDFznZ3y3SonMBBlWn3N
	U7npLuiBiRC/LSjguchEne6sEaAAAwLVSNhKNnxnwUoNk5B9EcnjrInowkau
	PgCCXEEMh6xnbRUoarwum2lYsRpNcap7KXWLwszOkhJXUqne78A5PtzZ25H5
	2K9knfQFIDuY0GwlC1qmEuDRyFycZa6pE1d53GmqK0taGapwC8turSSjirGd
	R780+ZzLMu0+x9SaAqaJ9OK4XsEl3V6n15lekLhDESEuujlLO1IHNzctUFBi
	lKaeb+RorEuPUOjfVfgj3o9TpVUqs0sevQdrw0o2Sc9ul1XoBDVusrBZEk9Z
	BleolYi5Btgvo0/S0yfINmKDvvdnBarIk+Th1cn5vscqiDfgGm+keErmtyrh
	1awkvO0h8rzT4ngcZgPVwiSrqKRoIudjTrsiuBBT6WZLtFcDdm1gq3rh8tbi
	84PPHAy2yrxDcFsA9kaSnK00fNHSusRrXWLxENNsINsSOZ7k45i+z0Ea7YlT
	vyeA6ntjjd0yqHYL6aUnGKjOaQqs3wrfYHn6UYCmxjkDVol0Lz4eeRPzOW2w
	27bmk8YDzIqW0kd/jdwqTR3eLju0zghLzSyjOyiuSeV9jc0OpYSFa5jg6krN
	ShOf8SM4z33Ay1N53qgfq5C0WZm6VM0gqpRGc0ZgAhHGhl9SO6ANWUfIEJmz
	g6WhqHcjlUUQnxdIlrQhIyfTyuqZaTHEJaycX2O94pX1fuNLdE4rDyxc6sAv
	c/hpDURxzJCRszvFeb005fXqO/SPiGetJfXwIWhXl8zApePNnUm8Qq2+4DAH
	NtMVaFqeKJ50VdE14cSTtL1SwnP0xqpj2e4xymN7adU8q2ORtGkqSI45cyiG
	1fuGO62pU3qY7wI15JKH5b1Q5BtXXBJgFYWHIuD/kRi5EJmPE6bzA3+cxtdE
	erR1h8ZWnaWaYn/apa37LpjnnNKW+3ZN0fY1nKwNRdDXW0U+4ozXRdm1exP6
	6lF0ekXTiWdcNtFh0VxtoDTvy0K5UkRGe4Kl8gATgFVvT0j3krRQXBhnuY3u
	hDaiRzo5kZR+OV/YHgqDybuTk0jEfHVK/5CapUeaEbsedhApg+Un+EJe5uf6
	UL3vaS4e732gZ0d4dqTe39WHfUU/8Ow+nt3HsyM8O9oulGpSuJOXh+abJEt8
	wamDidyWrqIqhwMAt2U14eXURVs5rIoVJGpVCH5FrhnMrG8Zp6uy8F5fDSvQ
	UjyODK9i6rSHQACtuBcQ3IQUwqzkMIV88C7FuclK1hqy36RM1oGrDifdAgK3
	QSO9e/dF7IYLdOJDpFb019Y+n6hkbmco4GZNxCxLxY8LaqchzzgKb+csVnx2
	zUj5N33r1L6clNIFVw5MsaNR9RQnpZw1wAjGuYRLDbg/9z6i9P0YnMdpLrgZ
	vu+aln4I1FhnZQU7DyWgNQGcl+HItTPp4MwYLxkM1BBVCSvR2CFHctOoDN5m
	ibAgcmGydnUsigV2mRF5XFjjHVfSZRBtTMOptBFtyRGajyiSG3Hx9NoQ6dpn
	AqZ1YhkENMpffQKvE6olo0R6n9QJ7zci+FKyPPDoK76xN0LycSrpXExznGWk
	oZwjx/0d3hs2kF6vur1vya4Is5PrNq1U1rpdCXeOIRWXMUaHoyIvzS8X/OPN
	29NfZjqx5pdn8vPk+fnpiLdY65yDJ2wYvdrGHgS2YGi9oGZI93gWV92AotHL
	Vw5zeTli/IBHHYlPNfrx9Ny9/VHegsYRbSIG8tlx56FdCj62rnLIyUVLVYi6
	LxYmrWmIRrRNOdKjcD69kVGCR720Rw+D9Fv4kvmEQtq3lRVvFhuE/vHWqrkd
	Zrc8KDkj23bjL7aOLLpRbAvfTM26OggauvNtz5xHQWbYXkpoUa4YzmBbF5zQ
	7VVHdLFNv/Wnrtfr9TDWqZarCSxkmfe1XDMwYMzo95EgXO0ilhCLdl5mBW35
	LD/XdxOZvwx+1X+/splvHf0SFt3u/u8X8mZ3EO4JDVv/+6jdqgvuprYrXN8q
	mPh3U3u7aO0q8vpXJG1QF2INJGz9N4veb2AJVs+Vsf1L8nXrcv1Ger7cJUKQ
	oLDUbqfw/H/Sw4fyx3pyCeV36nGS20GPbazk414NyLARfZs26gok2nEHSoAk
	+vAaB99LB9G2j7iRsXZ5sqqvaXRbbBRJnkDAiCbg28xvfCrxqQf09UDGP3Y4
	9piMTlXp5QBtqXVsnDmMIiDjaQZonDyRSZMOhy/vhqk7jvn5RHbAzYoJLQYM
	dwDTOCPokGlfa+hKaGJxdPgES3t1mmjxaO/g3qh2wHcf9PsEb4k7vcYhTek4
	yDJpt0wh64a93TxrHfpsBgq3HEgMmOX44A8DMp86AlxX2+oqagCESOBcE18z
	sYGuCO5EM51l2cFY5/T/n0edR/g85O/Pg3RQIc544yypY9iIIjJyieoLDlxp
	jfUH5vQWxeyoefc1kppOcTgdatKZm6hmUhwMh/zPGGev8kC4eMKfC7NG7gTo
	J3Ydt0Wgzb/weQ398zHCzIh8rEzOK8ljanY3bFbQ33h5i5BszbxVTRHKg7Qd
	ML9vHETX4dZayYO4k6rRew5TfGJA9b799rj34c7WVTkwmgfcbLgolsl+6LE6
	lhxGt9SrOFAK1w/YIMkebFQKDy4P5Pqcg3lMnu5PiJJGu6TmmZlCVWWjqMor
	d/b47bejOvET8nHTPurbvdCHVV1JJ+YJILlOqwwjEDG4iidkajYW5SLBn1wl
	IncLAW/4a/A4vDZI1bM/Vn6a8maml3Gyca+eGn+TVoTY6pK/puVTd28Z9CxJ
	Sq6pvF2bB1MKNU6d7gEsoU4ml2m2Tsx0LkkCdCjZVTP9XY+jnR6jRjq95BRM
	fbcWC/JTTe6U+p52MtlyyTCYGgyKGUfgAt14XBZQX963aIQ1EvtR742LluQK
	OcTP5zr52Z03gY31KExQwqKn2UocvIUGGgR9WEEB7uzmymRgEB/Za+ezsjVb
	gCQrfGtXhXdV5T7EWUOAJuh/WeB3butujlPVLXcCR9UBWoMFXIKCPBD2XpXR
	2gr1xpuIfB0+9rgqebvz+TTb5+vf5AaFcTnnq0i4CsYuUbzhD7HZfsSX+zFu
	AizkKjZMC6pApCjAJ1bRYoUQmePRY1puXOV1p8AC6n1/p1c/+p7a/FAWBRbs
	ic4tTul9D+c1pQe0t0p1ToSlG+bPn7Tlq99sntkqY/Xs5C9dEuaqn+M0n01+
	1wM0AaH7y7F6t9g0F+q76FipkxkMroOXaPduDBHTV2vjqi0TyKJWDtutQ4Yq
	04gDSFJktgCUj5Kk6h4eNkzVyTBR/HfMfKjWqIxJVQimM64Goc4FdSYy12mS
	6andr8h3BSthlVT36XyZWquaSruTYo3CJ+ejyTkWqJ46NQMFV1/E0XAGeNLn
	7Kr6EnYoVIHDePc5xewuZuRiFn/qPiRJRmOPUCYX+kGWh2lPg0s3+fw0JgCd
	sMhIu916ZuLWE2zDir/+HKZcoVMfTQs4/l3V0NWVBW2Z6wLm1E8rmqzP2mo+
	rFczi4/+1sf5S16W6+trOVxDLWsUpnV4hPRX10DMttqDCuUlvIVkdHdE8gpR
	n/GRwhTnkbW7R84t4QqwepA45ZQVDRiMhdavYeFzLmpHr7jTS6cCZq5oy7qD
	6cBW2SzFXuKgD6EzytguXKFk950qjUsHUKtQn67HCR98iCR83YxolPElIhae
	nLXvz1kHtVG3X7uiUAcXyy0NVSaYmeQvzlGjg1GL80HR12vN5YDdl+lRnFzj
	qSywYbf/MXIWprqhzCddpHJCCKlHIUXTFOm/lVbkujFF7cvW4yWS6x1cZ3nu
	rAPybp67PahypED6LXU9cieDUk1CguticIg6besOElInNP7mDqiL5k0tUrGC
	g51OYQGrVmqH81lrrwYhfGlf03DiuHSFI2BmrMjWSGhPYsf5mFxnD0/FfFus
	dTdrpHNTBcxVdM2i2ixSkeox5kGtLVpXGx1IVX2PYmQzB0U9JclhCEGO4x6g
	nMnjWpDZlgx7ivjSOHaCeURX9nPLwMIweCETdzzE5TjLXCoNGvcFWX/uAekY
	fFjVijTFrxW6yP6UU/GoLASVX/jyGiLTwoNi5KAaOzhrkmykeqQ543ob+OsY
	qlz5ARND6o9rU5MNy7q7LMSdjkCP78wYdx8Sz7ydCw9v1AcA3DXBuFugkU/H
	rPyhKcy7q/K/ffFkGxFh5m9WKLisy4AgC77MqJV7B2f/XI4ZwUc1G6mMGdKf
	OBQihthjU6AjuAIzdgc8QpV54WsLdh0fI43mN06cDrLZzJ0HGZfk2LNf6W8z
	dU53N9m7+m8Q4RbNIZs6XlogvZNE586JWjNwYq5MAnetqrwRhd0uAGKlUqdm
	+PiF7J2iPummc1Te8ClSd9ze3b4gfCYn1JvAhG+lrEut16aCvpCUDlwqf/te
	Xp+crlRCVRCu6gt0fImSF0EfbNdhQ+PENG8knhb7sbx7fDHO1jlGvuCku4iR
	p8HyIicTcHMg+4z9amLVXGSnPXXeRD6OfR0Aytmkql2mF6Y2ec+9zIZOF/ti
	+bD2Wz6N084zOnyESdSxLedzSfHzPQ31TVFyuLJ5h5iv0Khddz7hKPcrsNLr
	rkmXY95VZZbYlyaptcbZedwyPAxkG6FfR+KOWfSuYW4kEnToxyZx8aovVkX4
	KHdQ5kZkqLNf1bjg6vDR8BHmKR/LvBowy0juVSK7cIDLuHK2I6Odc8QMvebT
	HhdigptRaTbdhFS4GkChgmM8dyz3eTb/9aHe3p6Tp19xH/29ox0gxV2nVapk
	fdqNIu59dc/VZPz6MQ93jrmVpesck21NEfvb8Jpmde/Bobqz9+Dr/WH0f+D1
	qsa8XwAA


		</back>

	</rfc>	</rfc>

End of changes. 111 change blocks.
	866 lines changed or deleted	331 lines changed or added
This html diff was produced by rfcdiff 1.48.