Diff: rfc9038.original.xml

	rfc9038.original.xml	rfc9038.xml
	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='utf-8'?>

	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.
	An alternate method (rfc include) is described in the references. -->
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3688.xml">
	<!ENTITY RFC3735 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3735.xml">
	<!ENTITY RFC3915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3915.xml">
	<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5234.xml">
	<!ENTITY RFC5730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5730.xml">
	<!ENTITY RFC5731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5731.xml">
	<!ENTITY RFC5910 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5910.xml">
	<!ENTITY RFC7451 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7451.xml">
	<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7942.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY RFC8590 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8590.xml">
	<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.o
	rg/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="yes"?>
	<!-- keep one blank line between list items -->
	<?rfc comments="yes" ?>
	<!-- show cref output -->
	<?rfc inline="yes" ?>
	<!-- inline cref output -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-regext-unhandled-namespaces-08"
	ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en"
	tocInclude="true" tocDepth="4"
	symRefs="true" sortRefs="true" version="3" consensus="true">

	<!-- *** FRONT MATTER *** -->


		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-regext-unhan dled-namespaces-08" number="9038" ipr="trust200902" obsoletes="" updates="" subm issionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true " tocDepth="4" symRefs="true" sortRefs="true" version="3">
	<front>	<front>

	<title abbrev="unhandledNamespaces">	<title abbrev="Unhandled Namespaces">
	Extensible Provisioning Protocol (EPP) Unhandled Namespaces</title>	Extensible Provisioning Protocol (EPP) Unhandled Namespaces</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-regext-unhandled-namespa ces-08"/>	<seriesInfo name="RFC" value="9038"/>
	<author fullname="James Gould" surname="Gould">	<author fullname="James Gould" surname="Gould">
	<organization>VeriSign, Inc.</organization>	<organization>VeriSign, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>
	<city>Reston</city>	<city>Reston</city>
	<region>VA</region>	<region>VA</region>
	<code>20190</code>	<code>20190</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>jgould@verisign.com</email>	<email>jgould@verisign.com</email>

	<uri>http://www.verisigninc.com</uri>	<uri>http://www.verisign.com</uri>
	</address>	</address>
	</author>	</author>
	<author fullname="Martin Casanova" surname="Casanova">	<author fullname="Martin Casanova" surname="Casanova">
	<organization>SWITCH</organization>	<organization>SWITCH</organization>
	<address>	<address>
	<postal>	<postal>
	<street>P.O. Box</street>	<street>P.O. Box</street>
	<city>Zurich</city>	<city>Zurich</city>
	<code>8021</code>	<code>8021</code>

	<country>CH</country>	<country>Switzerland</country>
	</postal>	</postal>
	<email>martin.casanova@switch.ch</email>	<email>martin.casanova@switch.ch</email>
	<uri>http://www.switch.ch</uri>	<uri>http://www.switch.ch</uri>
	</address>	</address>
	</author>	</author>

	<date day="19" month="February" year="2021"/>	<date month="May" year="2021"/>

		<keyword>login</keyword>
		<keyword>greeting</keyword>
		<keyword>URI</keyword>
		<keyword>namespace</keyword>
		<keyword>response</keyword>
		<keyword>general</keyword>
		<keyword>poll</keyword>
		<keyword>object-level</keyword>
		<keyword>command-response</keyword>
		<keyword>signal</keyword>
		<keyword>signaling</keyword>

	<abstract>	<abstract>
	<t>The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,	<t>The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
	includes a method for the client and server to	includes a method for the client and server to
	determine the objects to be managed during a session and the object	determine the objects to be managed during a session and the object
	extensions to be used during a session. The services are identified using	extensions to be used during a session. The services are identified using
	namespace URIs, and an "unhandled namespace" is one that is associated wit h	namespace URIs, and an "unhandled namespace" is one that is associated wit h
	a service not supported by the client.	a service not supported by the client.
	This document defines an operational practice that enables the server	This document defines an operational practice that enables the server

	to return information associated with unhandled namespace URIs that is	to return information associated with unhandled namespace URIs and that
	compliant with the negotiated services defined in	maintains compliance with the negotiated services defined in
	RFC 5730.</t>	RFC 5730.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>
	<t>The Extensible Provisioning Protocol (EPP), as defined in <xref target= "RFC5730" format="default"/>, includes a method for the client and server to	<t>The Extensible Provisioning Protocol (EPP), as defined in <xref target= "RFC5730" format="default"/>, includes a method for the client and server to
	determine the objects to be managed during a session and the object	determine the objects to be managed during a session and the object
	extensions to be used during a session. The services are identified using	extensions to be used during a session. The services are identified using
	namespace URIs. How should the server handle	namespace URIs. How should the server handle
	service data that needs to be returned in the response when	service data that needs to be returned in the response when
	the client does not support the required service namespace URI,	the client does not support the required service namespace URI,

	which is referred to as an unhandled namespace? An unhandled namespace	which is referred to as an "unhandled namespace"?
	is a significant issue for the processing of <xref target="RFC5730" format	An unhandled namespace
	="default"/> poll messages, since poll messages are inserted	is a significant issue for the processing of the poll messages described i
		n <xref target="RFC5730" format="default"/>, since poll messages are inserted
	by the server prior to knowing the supported client services,	by the server prior to knowing the supported client services,
	and the client needs to be capable of processing all poll messages.	and the client needs to be capable of processing all poll messages.
	Returning an unhandled namespace poll message is not compliant with the ne gotiated services defined in	Returning an unhandled namespace poll message is not compliant with the ne gotiated services defined in

	<xref target="RFC5730" format="default"/> and returning an error makes the unhandled namespace poll message	<xref target="RFC5730" format="default"/>, and returning an error makes th e unhandled namespace poll message
	a poison message by halting the processing of the poll queue.	a poison message by halting the processing of the poll queue.

	An unhandled namespace is an issue also for general EPP responses when the	An unhandled namespace is also an issue for general EPP responses when the
	server has information that it cannot return to the client due to	server has information that it cannot return to the client due to
	the client's supported services. The server should be able to return	the client's supported services. The server should be able to return
	unhandled namespace information that	unhandled namespace information that
	the client can process later. This document defines an operational	the client can process later. This document defines an operational
	practice that enables the server to return information associated	practice that enables the server to return information associated

	with unhandled namespace URIs that is compliant with the negotiated	with unhandled namespace URIs and that maintains compliance with the negot iated
	services defined in <xref target="RFC5730" format="default"/>.</t>	services defined in <xref target="RFC5730" format="default"/>.</t>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Conventions Used in This Document</name>	<name>Conventions Used in This Document</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"/>	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	when, and only when, they	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	<t>XML is case sensitive. Unless stated otherwise, XML specifications	be interpreted as
	and examples provided in this document MUST be interpreted in the	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>

		<t>XML <xref target="W3C.REC-xml11-20060816"/> is case sensitive. Unless
		stated otherwise, XML specifications
		and examples provided in this document <bcp14>MUST</bcp14> be interprete
		d in the
	character case presented in order to develop a conforming	character case presented in order to develop a conforming
	implementation.</t>	implementation.</t>
	<t>In examples, "S:" represents lines returned by a protocol server.	<t>In examples, "S:" represents lines returned by a protocol server.
	Indentation and white space in examples are provided only to illustrate element relationships	Indentation and white space in examples are provided only to illustrate element relationships

	and are not a required feature of this protocol.	and are not required features of this protocol.
	</t>	</t>
	<t>The examples reference XML namespace prefixes that are used for the a ssociated XML namespaces.	<t>The examples reference XML namespace prefixes that are used for the a ssociated XML namespaces.

	Implementations MUST NOT depend on the example XML namespaces and instea d employ a proper	Implementations <bcp14>MUST NOT</bcp14> depend on the example XML namesp aces and instead employ a proper
	namespace-aware XML parser and serializer to interpret and	namespace-aware XML parser and serializer to interpret and
	output the XML documents. The example namespace prefixes used and their associated XML namespaces include:</t>	output the XML documents. The example namespace prefixes used and their associated XML namespaces include:</t>

	<dl newline="false" spacing="compact" indent="4">	<dl newline="false" spacing="normal" indent="4">
	<dt>"changePoll":</dt>	<dt>changePoll:</dt>
	<dd>urn:ietf:params:xml:ns:changePoll-1.0</dd>	<dd>urn:ietf:params:xml:ns:changePoll-1.0</dd>

	<dt>"domain":</dt>	<dt>domain:</dt>
	<dd>urn:ietf:params:xml:ns:domain-1.0</dd>	<dd>urn:ietf:params:xml:ns:domain-1.0</dd>

	<dt>"secDNS":</dt>	<dt>secDNS:</dt>
	<dd>urn:ietf:params:xml:ns:secDNS-1.1</dd>	<dd>urn:ietf:params:xml:ns:secDNS-1.1</dd>
	</dl>	</dl>
	<t>In the template example XML, placeholder content is represented by th e following variables:</t>	<t>In the template example XML, placeholder content is represented by th e following variables:</t>

	<dl newline="false" spacing="compact" indent="4">	<dl newline="false" spacing="normal" indent="4">
	<dt>"[NAMESPACE-XML]":</dt>	<dt>[NAMESPACE-XML]:</dt>
	<dd>XML content associated with a login service namespace URI.	<dd>XML content associated with a login service namespace URI.
	An example is the <domain:infData> element content in <xref ta rget="RFC5731" format="default"/>.</dd>	An example is the <domain:infData> element content in <xref ta rget="RFC5731" format="default"/>.</dd>

	<dt>"[NAMESPACE-URI]":</dt>	<dt>[NAMESPACE-URI]:</dt>
	<dd>XML namespace URI associated with the [NAMESPACE-XML] XML content.	<dd>XML namespace URI associated with the [NAMESPACE-XML] XML content.
	An example is "urn:ietf:params:xml:ns:domain-1.0" in <xref target="R FC5731" format="default"/>.</dd>	An example is "urn:ietf:params:xml:ns:domain-1.0" in <xref target="R FC5731" format="default"/>.</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>
	<section anchor="unhandledNamespace" numbered="true" toc="default">	<section anchor="unhandledNamespace" numbered="true" toc="default">
	<name>Unhandled Namespaces</name>	<name>Unhandled Namespaces</name>

	<t>An Unhandled Namespace is an XML namespace that is associated with a re sponse extension that is	<t>An unhandled namespace is an XML namespace that is associated with a re sponse extension that is
	not included in the client-specified EPP login services of <xref target="RFC 5730" format="default"/>. The EPP login	not included in the client-specified EPP login services of <xref target="RFC 5730" format="default"/>. The EPP login

	services consists of the set of XML namespace URIs included in the <objUR	services consist of the set of XML namespace URIs included in the <objURI
	I> or <extURI> elements of	> or <extURI> elements of
	the <xref target="RFC5730" format="default"/> EPP <login> command. Th	the EPP <login> command <xref target="RFC5730" format="default"/>. Th
	e services supported by the server are	e services supported by the server are
	included in the <objURI> and <extURI> elements of the <xref targ	included in the <objURI> and <extURI> elements of the EPP <gr
	et="RFC5730" format="default"/> EPP <greeting>, which should be	eeting> <xref target="RFC5730" format="default"/>, which should be
	a superset of the login services included in the EPP <login> command. A server may have information	a superset of the login services included in the EPP <login> command. A server may have information
	associated with a specific namespace that it needs to return in the response to a client. The unhandled namespaces problem exists when the server	associated with a specific namespace that it needs to return in the response to a client. The unhandled namespaces problem exists when the server

	has information that it needs to return to the client but the namespace of t he information is not supported by the client based on the	has information that it needs to return to the client, but the namespace of the information is not supported by the client based on the
	negotiated EPP <login> command services.</t>	negotiated EPP <login> command services.</t>
	</section>	</section>
	<section anchor="extValueApproach" numbered="true" toc="default">	<section anchor="extValueApproach" numbered="true" toc="default">
	<name>Use of EPP <extValue> for Unhandled Namespace Data</name>	<name>Use of EPP <extValue> for Unhandled Namespace Data</name>
	<t>In <xref target="RFC5730" format="default"/>, the <extValue> elem ent is used to provide additional	<t>In <xref target="RFC5730" format="default"/>, the <extValue> elem ent is used to provide additional
	error diagnostic information, including the <value> element that ide ntifies the client-provided element that caused	error diagnostic information, including the <value> element that ide ntifies the client-provided element that caused
	a server error condition and the <reason> element containing the hum an-readable message that describes the reason for	a server error condition and the <reason> element containing the hum an-readable message that describes the reason for
	the error. This operational practice extends the use of the <extValue& gt; element for the purpose of returning	the error. This operational practice extends the use of the <extValue& gt; element for the purpose of returning
	unhandled namespace information in a successful response.</t>	unhandled namespace information in a successful response.</t>
	<t>When a server has data to return to the client that the client does not support based on the login services,	<t>When a server has data to return to the client that the client does not support based on the login services,

	the server MAY return a successful response, with the data for each unsupp	the server <bcp14>MAY</bcp14> return a successful response with the data f
	orted namespace moved into an	or each unsupported namespace moved into an <extValue> element <xref targe
	<xref target="RFC5730" format="default"/> <extValue> element. The u	t="RFC5730" format="default"/>. The unhandled namespace will not cause an error
	nhandled namespace will not cause an error response,	response,
	but the unhandled namespace data will instead be moved to an <extValue& gt; element, along with a reason why	but the unhandled namespace data will instead be moved to an <extValue& gt; element, along with a reason why
	the unhandled namespace data could not be included in the appropriate loca tion of the response.	the unhandled namespace data could not be included in the appropriate loca tion of the response.

	The <extValue> element XML will not be processed by the XML processo r. The <extValue>	The <extValue> element will not be processed by the XML processor. The <extValue>
	element contains the following child elements:	element contains the following child elements:
	</t>	</t>

	<dl newline="false" spacing="compact" indent="4">	<dl newline="false" spacing="normal" indent="4">
	<dt><value>:</dt>	<dt><value>:</dt>

	<dd>Contains a child-element with the unhandled namespace XML.	<dd>Contains a child element with the unhandled namespace XML.
	The unhandled namespace MUST be declared in the child element or any	The unhandled namespace <bcp14>MUST</bcp14> be declared in the child
	containing element including the root element.	element or any
		containing element, including the root element.
	XML processing of the <value> element is	XML processing of the <value> element is
	disabled by the XML schema in <xref target="RFC5730" format="default" />, so the information can	disabled by the XML schema in <xref target="RFC5730" format="default" />, so the information can
	safely be returned in the <value> element.</dd>	safely be returned in the <value> element.</dd>
	<dt><reason>:</dt>	<dt><reason>:</dt>

	<dd>A formatted human-readable message that indicates the reason the	<dd>A formatted, human-readable message that indicates the reason the
	unhandled namespace data was not returned in the appropriate location of the response. The formatted reason	unhandled namespace data was not returned in the appropriate location of the response. The formatted reason

	SHOULD follow the <xref target="RFC5234" format="default">Augmented Ba	<bcp14>SHOULD</bcp14> follow the <xref target="RFC5234" format="defaul
	ckus-Naur Form (ABNF) grammar</xref> format: NAMESPACE-URI "not in login service	t">Augmented Backus-Naur Form (ABNF) grammar</xref> format: NAMESPACE-URI " not
	s",	in login services",
	where NAMESPACE-URI is the unhandled XML namespace like "urn:ietf:para	where NAMESPACE-URI is the unhandled XML namespace like "urn:ietf:para
	ms:xml:ns:domain-1.0" for <xref target="RFC5731" format="default"/>.</dd>	ms:xml:ns:domain-1.0" in <xref target="RFC5731" format="default"/>.</dd>
	</dl>	</dl>

	<t>This document applies to the handling of unsupported namespaces for <xr	<t>This document applies to the handling of unsupported namespaces for obj
	ef target="RFC3735" format="default"/> object-level extensions and command-respo	ect-level extensions and command-response extensions <xref target="RFC3735" form
	nse extensions.	at="default"/>.
	This document does not apply to the handling of unsupported namespaces for	This document does not apply to the handling of unsupported namespaces for
	<xref target="RFC3735" format="default"/> protocol-level extensions or authenti	protocol-level extensions or authentication-information extensions <xref target
	cation information extensions.	="RFC3735" format="default"/>.
	Refer to the following sections on how to handle an unsupported object-lev el extension namespace or an unsupported command-response extension namespace.</ t>	Refer to the following sections on how to handle an unsupported object-lev el extension namespace or an unsupported command-response extension namespace.</ t>
	<section anchor="objectLevelExtension" numbered="true" toc="default">	<section anchor="objectLevelExtension" numbered="true" toc="default">
	<name>Unhandled Object-Level Extension</name>	<name>Unhandled Object-Level Extension</name>
	<t>An object-level extension in <xref target="RFC5730" format="default"/ > is a child element of the <resData> element. If the client does not han dle	<t>An object-level extension in <xref target="RFC5730" format="default"/ > is a child element of the <resData> element. If the client does not han dle

	the namespace of the object-level extension, then the <resData> el	the namespace of the object-level extension, then the <resData> el
	ement is removed and its object-level extension child element is moved into a	ement is removed and its object-level extension child element is moved into an &
	<xref target="RFC5730" format="default"/> <extValue> <value>	lt;extValue> <value> element <xref target="RFC5730" format="default"/>,
	element, with the namespace URI included in the corresponding <extValue>	with the namespace URI included in the corresponding <extValue> <reaso
	<reason> element.	n> element.
	The response becomes a general EPP response without the <resData> element.</t>	The response becomes a general EPP response without the <resData> element.</t>

	<t keepWithNext="true">Template response for a supported object-level ex tension.	<t keepWithNext="true">Below is a template response for a supported obje ct-level extension.
	The [NAMESPACE-XML] variable represents the object-level extension XML.< /t>	The [NAMESPACE-XML] variable represents the object-level extension XML.< /t>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<sourcecode type="xml"><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: [NAMESPACE-XML]	S: [NAMESPACE-XML]
	S: </resData>	S: </resData>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	<t keepWithNext="true">Template for an unhandled namespace response for	<t keepWithNext="true">Below is a template for an unhandled namespace re
	an unsupported object-level extension.	sponse for an unsupported object-level extension.
	The [NAMESPACE-XML] variable represents the object-level extension XML and	The [NAMESPACE-XML] variable represents the object-level extension XML, an
	the [NAMESPACE-URI]	d the [NAMESPACE-URI]
	variable represents the object-level extension XML namespace URI.</t>	variable represents the object-level extension XML namespace URI.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<sourcecode type="xml"><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>
	S: [NAMESPACE-XML]	S: [NAMESPACE-XML]
	S: </value>	S: </value>
	S: <reason>	S: <reason>
	S: [NAMESPACE-URI] not in login services	S: [NAMESPACE-URI] not in login services
	S: </reason>	S: </reason>
	S: </extValue>	S: </extValue>
	S: </result>	S: </result>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	<t>The EPP response is converted from an object response to a general EP	<t>The EPP response is converted from an object response to a general EP
	P response by the server when the client does not support the object-level exten	P response by the server when the client does not support the object-level exten
	sion namespace URI.	sion namespace URI.</t>
	Below is an example of converting the <transfer> query response ex	<t keepWithNext="true">Below is an example of a <transfer> query r
	ample in Section 3.1.3 of <xref target="RFC5731" format="default"/> to an unhand	esponse (see <xref target="RFC5731" sectionFormat="of" section="3.1.3"/>) conver
	led namespace response.</t>	ted into an unhandled namespace response.</t>
	<t keepWithNext="true"><xref target="RFC5731" format="default"/> example	<sourcecode type="xml"><![CDATA[
	<transfer> query response converted into an unhandled namespace response:
	</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>
	S: <domain:trnData	S: <domain:trnData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:name>example.com</domain:name>	S: <domain:name>example.com</domain:name>

	skipping to change at line 290 ¶	skipping to change at line 253 ¶
	S: urn:ietf:params:xml:ns:domain-1.0 not in login services	S: urn:ietf:params:xml:ns:domain-1.0 not in login services
	S: </reason>	S: </reason>
	S: </extValue>	S: </extValue>
	S: </result>	S: </result>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</section>	</section>
	<section anchor="commandResponseLevelExtension" numbered="true" toc="defau lt">	<section anchor="commandResponseLevelExtension" numbered="true" toc="defau lt">
	<name>Unhandled Command-Response Extension</name>	<name>Unhandled Command-Response Extension</name>
	<t>A command-response extension in <xref target="RFC5730" format="defaul t"/> is a child element of the <extension> element. If the client does no t handle	<t>A command-response extension in <xref target="RFC5730" format="defaul t"/> is a child element of the <extension> element. If the client does no t handle

	the namespace of the command-response extension, the command-response ch	the namespace of the command-response extension, the command-response ch
	ild element is moved into an <xref target="RFC5730" format="default"/> <extVa	ild element is moved into an <extValue> <value>
	lue> <value>	element <xref target="RFC5730" format="default"/>, with the namespace UR
	element, with the namespace URI included in the corresponding <extVal	I included in the corresponding <extValue> <reason> element. Afterw
	ue> <reason> element. If after moving the command-response child eleme	ards, if there
	nt there	are no additional command-response child elements, the <extension>
	are no additional command-response child elements, the <extension>	element <bcp14>MUST</bcp14> be removed.</t>
	element MUST be removed.</t>	<t keepWithNext="true">Below is a template response for a supported comm
	<t keepWithNext="true">Template response for a supported command-respons	and-response extension.
	e extension.
	The [NAMESPACE-XML] variable represents the command-response extension X ML.</t>	The [NAMESPACE-XML] variable represents the command-response extension X ML.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<sourcecode type="xml"><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <extension>	S: <extension>
	S: [NAMESPACE-XML]	S: [NAMESPACE-XML]
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	<t keepWithNext="true">Template unhandled namespace response for an unsu	<t keepWithNext="true">Below is a template of an unhandled namespace res
	pported command-response extension. The [NAMESPACE-XML] variable represents the	ponse for an unsupported command-response extension. The [NAMESPACE-XML] variab
	command-response extension XML and the	le represents the
		command-response extension XML, and the
	[NAMESPACE-URI] variable represents the command-response extension XML n amespace URI.</t>	[NAMESPACE-URI] variable represents the command-response extension XML n amespace URI.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<sourcecode type="xml"><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>
	S: [NAMESPACE-XML]	S: [NAMESPACE-XML]
	S: </value>	S: </value>
	S: <reason>	S: <reason>
	S: [NAMESPACE-URI] not in login services	S: [NAMESPACE-URI] not in login services
	S: </reason>	S: </reason>
	S: </extValue>	S: </extValue>
	S: </result>	S: </result>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	<t>The EPP response is converted to an unhandled namespace response by m	<t>The EPP response is converted to an unhandled namespace response by m
	oving the unhandled command-response extension from under the <extension>	oving the unhandled command-response extension from under the <extension>
	to an <extValue> element.	to an <extValue> element.</t>
	Below is example of converting the DS Data Interface <info> respon	<t keepWithNext="true">Below is example of the Delegation Signer (DS) Da
	se example in Section 5.1.2 of <xref target="RFC5910" format="default"/> to an u	ta Interface <info> response (see <xref target="RFC5910" sectionFormat="of
	nhandled namespace response.</t>	" section="5.1.2"/>) converted to an unhandled namespace response.</t>
	<t keepWithNext="true"><xref target="RFC5910" format="default"/> DS Data	<sourcecode type="xml"><![CDATA[
	Interface <info> response converted into an unhandled namespace response:
	</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
	S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">	S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>
	S: <secDNS:infData	S: <secDNS:infData
	S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">	S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">

	skipping to change at line 401 ¶	skipping to change at line 363 ¶
	S: <domain:authInfo>	S: <domain:authInfo>
	S: <domain:pw>2fooBAR</domain:pw>	S: <domain:pw>2fooBAR</domain:pw>
	S: </domain:authInfo>	S: </domain:authInfo>
	S: </domain:infData>	S: </domain:infData>
	S: </resData>	S: </resData>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
		]]></sourcecode>
	</section>	</section>
	</section>	</section>
	<section anchor="signal-client-server-support" numbered="true" toc="default" >	<section anchor="signal-client-server-support" numbered="true" toc="default" >
	<name>Signaling Client and Server Support</name>	<name>Signaling Client and Server Support</name>
	<t>This document does not define new EPP protocol elements but rather spec ifies an operational practice using the existing EPP protocol, where	<t>This document does not define new EPP protocol elements but rather spec ifies an operational practice using the existing EPP protocol, where
	the client and the server can signal support for the operational practic e using a namespace URI in the login and greeting extension services.	the client and the server can signal support for the operational practic e using a namespace URI in the login and greeting extension services.
	The namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to signal support for the operational practice. The	The namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to signal support for the operational practice. The

	client includes the namespace URI in an <svcExtension> <extURI&	client includes the namespace URI in an <svcExtension> <extURI&
	gt; element of the <xref target="RFC5730" format="default"/> <login> Comma	gt; element of the <login> command <xref target="RFC5730" format="default"
	nd.	/>.
	The server includes the namespace URI in an <svcExtension> <ext	The server includes the namespace URI in an <svcExtension> <ext
	URI> element of the <xref target="RFC5730" format="default"/> Greeting.</t>	URI> element of the greeting <xref target="RFC5730" format="default"/>.</t>
	<t>A client that receives the namespace URI in the server's Greeting exten	<t>A client that receives the namespace URI in the server's greeting exten
	sion services can expect the following supported behavior by the server:	sion services can expect the following supported behavior by the server:
	</t>	</t>

	<ol spacing="compact" type="1">	<ul spacing="normal">
	<li>Support unhandled namespace object-level extensions and command-resp	<li>support unhandled namespace object-level extensions and command-resp
	onse extensions in EPP poll messages, per <xref target="usagePollMessages" forma	onse extensions in EPP poll messages, per <xref target="usagePollMessages" forma
	t="default"/>.</li>	t="default"/></li>
	<li>Support the option of unhandled namespace command-response extension	<li>support the option of unhandled namespace command-response extension
	s in general EPP responses, per <xref target="usageGeneralResponses" format="def	s in general EPP responses, per <xref target="usageGeneralResponses" format="def
	ault"/>.</li>	ault"/></li>
	</ol>	</ul>
	<t>A server that receives the namespace URI in the client's <login>	<t>A server that receives the namespace URI in the client's <login>
	Command extension services can expect the following supported behavior by the cl	command extension services can expect the following supported behavior by the cl
	ient:	ient:
	</t>	</t>

	<ol spacing="compact" type="1">	<ul spacing="normal">
	<li>Support monitoring the EPP poll messages and general EPP responses f	<li>support monitoring the EPP poll messages and general EPP responses f
	or unhandled namespaces.</li>	or unhandled namespaces</li>
	</ol>	</ul>
	</section>	</section>
	<section anchor="usageGeneralResponses" numbered="true" toc="default">	<section anchor="usageGeneralResponses" numbered="true" toc="default">
	<name>Usage with General EPP Responses</name>	<name>Usage with General EPP Responses</name>
	<t>The unhandled namespace approach defined in <xref target="extValueAppro ach" format="default"/>	<t>The unhandled namespace approach defined in <xref target="extValueAppro ach" format="default"/>

	MAY be used for a general EPP response to an EPP command. A general EPP r	<bcp14>MAY</bcp14> be used for a general EPP response to an EPP command.
	esponse	A general EPP response
	includes any non-poll message EPP response. The use of the unhandled name	includes any EPP response that is not a poll message. The use of the unha
	space approach	ndled namespace approach
	for poll message EPP responses is defined in <xref target="usagePollMessag	for poll-message EPP responses is defined in <xref target="usagePollMessag
	es" format="default"/>.	es" format="default"/>.
	The server MAY exclude the unhandled namespace information in the general	The server <bcp14>MAY</bcp14> exclude the unhandled namespace information
	EPP response	in the general EPP response
	or MAY include it using the unhandled namespace approach.</t>	or <bcp14>MAY</bcp14> include it using the unhandled namespace approach.</
	<t>The unhandled namespace approach for general EPP responses SHOULD only	t>
	be applicable	<t>The unhandled namespace approach for general EPP responses <bcp14>SHOUL
		D</bcp14> only be applicable
	to command-response extensions, defined in <xref target="commandResponseLe velExtension" format="default"/>,	to command-response extensions, defined in <xref target="commandResponseLe velExtension" format="default"/>,

	since the server SHOULD NOT accept an object-level EPP command if the clie nt did not	since the server <bcp14>SHOULD NOT</bcp14> accept an object-level EPP comm and if the client did not
	include the object-level namespace URI in the login services. An object-l evel	include the object-level namespace URI in the login services. An object-l evel
	EPP response extension is returned when the server successfully executes a n	EPP response extension is returned when the server successfully executes a n

	object-level EPP command extension. The server MAY return an unhandled	object-level EPP command extension. The server <bcp14>MAY</bcp14> return
	object-level extension to the client as defined in <xref target="objectLev	an unhandled
	elExtension" format="default"/>.</t>	object-level extension to the client, as defined in <xref target="objectLe
		velExtension" format="default"/>.</t>
	<t>Returning domain name Redemption Grace Period (RGP) data, based on <xre f target="RFC3915" format="default"/>,	<t>Returning domain name Redemption Grace Period (RGP) data, based on <xre f target="RFC3915" format="default"/>,
	provides an example of applying the unhandled namespace approach for a gen eral EPP response.	provides an example of applying the unhandled namespace approach for a gen eral EPP response.
	If the client	If the client
	does not include the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login	does not include the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login

	services, and the domain <info> response of a domain name does have	services and the domain <info> response of a domain name does have R
	RGP	GP
	information, the server MAY exclude the <rgp:infData> element from t	information, the server <bcp14>MAY</bcp14> exclude the <rgp:infData>
	he EPP response	element from the EPP response
	or MAY include it under the <extValue> element per <xref target="com	or <bcp14>MAY</bcp14> include it under the <extValue> element, per <
	mandResponseLevelExtension" format="default"/>.	xref target="commandResponseLevelExtension" format="default"/>.</t>
	Below is example of converting the domain name <info> response examp	<t keepWithNext="true">Below is an example of a domain name <info> r
	le in Section 4.1.2 of <xref target="RFC3915" format="default"/> to an unhandled	esponse <xref target="RFC5731" format="default"/> converted to an unhandled <
	namespace response.</t>	rgp:infData> element (see <xref target="RFC3915" sectionFormat="of" section="
	<t keepWithNext="true"><xref target="RFC5731" format="default"/> domain na	4.1.1"/>) included under an <extValue> element:
	me <info> response with the unhandled
	<xref target="RFC3915" format="default"/> <rgp:infData> element incl
	uded under an <extValue> element:
	</t>	</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<sourcecode type="xml"><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
	S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"	S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0	S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
	S: epp-1.0.xsd">	S: epp-1.0.xsd">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>

	skipping to change at line 505 ¶	skipping to change at line 466 ¶
	S: <domain:authInfo>	S: <domain:authInfo>
	S: <domain:pw>2fooBAR</domain:pw>	S: <domain:pw>2fooBAR</domain:pw>
	S: </domain:authInfo>	S: </domain:authInfo>
	S: </domain:infData>	S: </domain:infData>
	S: </resData>	S: </resData>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
		]]></sourcecode>
	</section>	</section>
	<section anchor="usagePollMessages" numbered="true" toc="default">	<section anchor="usagePollMessages" numbered="true" toc="default">

	<name>Usage with Poll Message EPP Responses</name>	<name>Usage with Poll-Message EPP Responses</name>
	<t>The unhandled namespace approach, defined in <xref target="extValueAppr oach" format="default"/>,	<t>The unhandled namespace approach, defined in <xref target="extValueAppr oach" format="default"/>,

	MUST be used if there is unhandled namespace information included in an EP P <poll> message response.	<bcp14>MUST</bcp14> be used if there is unhandled namespace information in cluded in a <poll> response.
	The server inserts poll messages into the client's poll queue independent of knowing the supported	The server inserts poll messages into the client's poll queue independent of knowing the supported

	client login services, therefore there may be unhandled object-level and c ommand-response	client login services; therefore, there may be unhandled object-level exte nsions and command-response
	extensions included in a client's poll queue. In <xref target="RFC5730" f ormat="default"/>, the <poll> command	extensions included in a client's poll queue. In <xref target="RFC5730" f ormat="default"/>, the <poll> command
	is used by the client to retrieve and acknowledge poll messages that have been	is used by the client to retrieve and acknowledge poll messages that have been

	inserted by the server. The <poll> message response is an EPP respo	inserted by the server. The <poll> response is an EPP response that
	nse that includes the	includes the
	<msgQ> element that provides poll queue meta-data about the message.	<msgQ> element that provides poll queue metadata about the message.
	The	The
	unhandled namespace approach, defined in <xref target="extValueApproach" f ormat="default"/>, is used	unhandled namespace approach, defined in <xref target="extValueApproach" f ormat="default"/>, is used
	for an unhandled object-level extension and for each of the	for an unhandled object-level extension and for each of the

	unhandled command-response extensions attached to the <poll> message	unhandled command-response extensions attached to the <poll> respons
	response. The resulting	e. The resulting
	EPP <poll> message response MAY have either or both the object-level	<poll> response <bcp14>MAY</bcp14> have either or both the object-le
	extension or	vel extension or
	command-response extensions moved to <extValue> elements, as defined in	command-response extensions moved to <extValue> elements, as defined in
	<xref target="extValueApproach" format="default"/>.</t>	<xref target="extValueApproach" format="default"/>.</t>

	<t>The Change Poll Message, as defined in Section 3.1.2 of <xref target="R	<t>The change poll message, as defined in <xref target="RFC8590" sectionFo
	FC8590" format="default"/>, which is an extension of any EPP object,	rmat="of" section="3.1.2"/>, which is an extension of any EPP object,
	is an example of applying the unhandled namespace approach for EPP <pol	is an example of applying the unhandled namespace approach for <poll&gt
	l> message responses.	; responses.
	Below are examples of converting the domain name <info> response exa	Below are examples of converting the domain name <info> response exa
	mple in Section 3.1.2 of <xref target="RFC8590" format="default"/> to an unhandl	mple in <xref target="RFC8590" sectionFormat="of" section="3.1.2"/> to an unhand
	ed namespace response.	led namespace response.
	The object that will be used in the examples is a <xref target="RFC5731" f	The object that will be used in the examples is a domain name object <xref
	ormat="default"/> domain name object.</t>	target="RFC5731" format="default"/>.</t>
	<t keepWithNext="true"><xref target="RFC5731" format="default"/> domain na	<t keepWithNext="true">Below is a domain name <info> <poll> re
	me <info> <poll> message response with the unhandled	sponse <xref target="RFC5731" format="default"/> with the unhandled <changePo
	<xref target="RFC8590" format="default"/> <changePoll:changeData> el	ll:changeData> element <xref target="RFC8590" format="default"/> included und
	ement included under an <extValue> element:	er an <extValue> element.</t>
	</t>	<sourcecode type="xml"><![CDATA[
	<artwork name="" type="" align="left" alt=""><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1301">	S: <result code="1301">
	S: <msg lang="en-US">	S: <msg lang="en-US">
	S: Command completed successfully; ack to dequeue</msg>	S: Command completed successfully; ack to dequeue</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>
	S: <changePoll:changeData	S: <changePoll:changeData
	S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"	S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"

	skipping to change at line 581 ¶	skipping to change at line 541 ¶
	S: <domain:crID>ClientY</domain:crID>	S: <domain:crID>ClientY</domain:crID>
	S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>	S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
	S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>	S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
	S: </domain:infData>	S: </domain:infData>
	S: </resData>	S: </resData>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
	<t keepWithNext="true">Unhandled <xref target="RFC5731" format="default"/>	]]></sourcecode>
	domain name <info> <poll> message response and the unhandled	<t keepWithNext="true">Below is an unhandled domain name <info> <
	<xref target="RFC8590" format="default"/> <changePoll:changeData> el	poll> response <xref target="RFC5731" format="default"/> and the unhandled
	ement included under an <extValue> element:	<changePoll:changeData> element <xref target="RFC8590" format="defau
	</t>	lt"/> included under an <extValue> element.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<sourcecode type="xml"><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1301">	S: <result code="1301">
	S: <msg>Command completed successfully; ack to dequeue</msg>	S: <msg>Command completed successfully; ack to dequeue</msg>
	S: <extValue>	S: <extValue>
	S: <value>	S: <value>
	S: <domain:infData	S: <domain:infData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:name>domain.example</domain:name>	S: <domain:name>domain.example</domain:name>

	skipping to change at line 641 ¶	skipping to change at line 601 ¶
	S: </result>	S: </result>
	S: <msgQ count="201" id="1">	S: <msgQ count="201" id="1">
	S: <qDate>2013-10-22T14:25:57.0Z</qDate>	S: <qDate>2013-10-22T14:25:57.0Z</qDate>
	S: <msg>Registry initiated update of domain.</msg>	S: <msg>Registry initiated update of domain.</msg>
	S: </msgQ>	S: </msgQ>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
		]]></sourcecode>
	</section>	</section>
	<section anchor="ImplementationConsiderations" numbered="true" toc="default" >	<section anchor="ImplementationConsiderations" numbered="true" toc="default" >
	<name>Implementation Considerations</name>	<name>Implementation Considerations</name>
	<t>There are implementation considerations for the client and the server t o help address	<t>There are implementation considerations for the client and the server t o help address
	the risk of the client ignoring unhandled namespace information included in an EPP response	the risk of the client ignoring unhandled namespace information included in an EPP response
	that is needed to meet technical, policy, or legal requirements.	that is needed to meet technical, policy, or legal requirements.
	</t>	</t>
	<section anchor="ClientImplementationConsiderations" numbered="true" toc=" default">	<section anchor="ClientImplementationConsiderations" numbered="true" toc=" default">
	<name>Client Implementation Considerations</name>	<name>Client Implementation Considerations</name>
	<t>To reduce the likelihood of a client receiving unhandled namespace in formation, the	<t>To reduce the likelihood of a client receiving unhandled namespace in formation, the
	client should consider implementing the following:</t>	client should consider implementing the following:</t>

	<ol spacing="compact" type="1">	<ol spacing="normal">
	<li>Ensure that the client presents the complete set of what it supp orts when presenting its login services.	<li>Ensure that the client presents the complete set of what it supp orts when presenting its login services.
	If there are gaps between the services supported by the client and the login	If there are gaps between the services supported by the client and the login
	services included in the login command, the client may	services included in the login command, the client may
	receive unhandled namespace information that the client could have supported.	receive unhandled namespace information that the client could have supported.
	</li>	</li>
	<li>Support all of the services included in the server greeting serv ices that	<li>Support all of the services included in the server greeting serv ices that

	may be included in an EPP response, including the poll queue respo nses.	may be included in an EPP response, including the <poll> res ponses.
	The client should evaluate the gaps between the greeting services and the	The client should evaluate the gaps between the greeting services and the
	login services provided in the login command to identify extension s that need	login services provided in the login command to identify extension s that need
	to be supported.</li>	to be supported.</li>
	<li>Proactively monitor for unhandled namespace information in the E PP	<li>Proactively monitor for unhandled namespace information in the E PP
	responses by looking for the inclusion of the <extValue> eleme nt in	responses by looking for the inclusion of the <extValue> eleme nt in

	successful responses, recording the unsupported namespace included i	successful responses, record the unsupported namespace included in t
	n the	he
	<reason> element, and recording the unhandled namespace inform	<reason> element, and record the unhandled namespace informati
	ation included in the	on included in the
	<value> element for later processing. The unhandled namespace should be implemented	<value> element for later processing. The unhandled namespace should be implemented
	by the client to ensure that information is processed fully in futur e EPP responses.</li>	by the client to ensure that information is processed fully in futur e EPP responses.</li>
	</ol>	</ol>
	</section>	</section>
	<section anchor="ServerImplementationConsiderations" numbered="true" toc=" default">	<section anchor="ServerImplementationConsiderations" numbered="true" toc=" default">
	<name>Server Implementation Considerations</name>	<name>Server Implementation Considerations</name>
	<t>To assist the clients in recognizing unhandled namespaces, the server should consider implementing the following:</t>	<t>To assist the clients in recognizing unhandled namespaces, the server should consider implementing the following:</t>

	<ol spacing="compact" type="1">	<ol spacing="normal" type="1">
	<li>Monitor for returning unhandled namespace information to clients and report it	<li>Monitor for returning unhandled namespace information to clients and report it

	to the clients out-of-band to EPP so the clients can add support f	to the clients out of band to EPP, so the clients can add support
	or	for
	the unhandled namespaces.	the unhandled namespaces.</li>
	</li>
	<li>Look for the unhandled namespace support in the login services w hen	<li>Look for the unhandled namespace support in the login services w hen

	returning optional unhandled namespace information in General EPP	returning optional unhandled namespace information in general EPP
	Responses.	responses.</li>
	</li>
	</ol>	</ol>
	</section>	</section>
	</section>	</section>
	<section anchor="IANA" numbered="true" toc="default">	<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<section anchor="IANA-XML-Namespace" numbered="true" toc="default">	<section anchor="IANA-XML-Namespace" numbered="true" toc="default">
	<name>XML Namespace</name>	<name>XML Namespace</name>
	<t>	<t>
	This document uses URNs to describe XML namespaces	This document uses URNs to describe XML namespaces
	conforming to a registry mechanism described in <xref target="RFC36 88" format="default"/>.	conforming to a registry mechanism described in <xref target="RFC36 88" format="default"/>.

	The following URI assignment is requested of IANA:	The following URI assignment has been made by IANA.
	</t>	</t>

	<t>Registration request for the unhandled namespaces namespace:</t>	<dl newline="false" spacing="compact">
	<ul empty="true" spacing="compact">	<dt>URI:</dt>
	<li>URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0</li>	<dd>urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0</dd>
	<li>Registrant Contact: IESG</li>	<dt>Registrant Contact:</dt>
	<li>XML: None. Namespace URIs do not represent an XML specification.</	<dd>IESG</dd>
	li>	<dt>XML:</dt>
	</ul>	<dd>None. Namespace URIs do not represent an XML specification.</dd>
		</dl>
	</section>	</section>
	<section anchor="EPP-Extension-Registry" numbered="true" toc="default">	<section anchor="EPP-Extension-Registry" numbered="true" toc="default">
	<name>EPP Extension Registry</name>	<name>EPP Extension Registry</name>
	<t>	<t>

	The EPP operational practice described in this document should be registered	The EPP operational practice described in this document has been registered b
	by	y
	the IANA in the EPP Extension Registry described in <xref target="RFC7451" fo	IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" regis
	rmat="default"/>. The	try described in <xref target="RFC7451" format="default"/>. The
	details of the registration are as follows:	details of the registration are as follows:
	</t>	</t>

	<t>	<dl newline="false" spacing="compact">
	Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled Namespac	<dt>Name of Extension:</dt>
	es"	<dd>"Extensible Provisioning Protocol (EPP) Unhandled Namespaces"</dd>
	</t>	<dt>Document Status:</dt>
	<t>	<dd>Standards Track</dd>
	Document status: Standards Track	<dt>Reference:</dt>
	</t>	<dd>RFC 9038</dd>
	<t>	<dt>Registrant:</dt>
	Reference: (insert reference to RFC version of this document)	<dd>IETF, <iesg@ietf.org></dd>
	</t>	<dt>TLDs:</dt>
	<t>	<dd>Any</dd>
	Registrant Name and Email Address: IETF, <iesg@ietf.org>	<dt>IPR Disclosure:</dt>
	</t>	<dd>None</dd>
	<t>	<dt>Status:</dt>
	TLDs: Any	<dd>Active</dd>
	</t>	<dt>Notes:</dt>
	<t>	<dd>None</dd>
	IPR Disclosure: None	</dl>
	</t>
	<t>
	Status: Active
	</t>
	<t>
	Notes: None
	</t>
	</section>
	</section>
	<section anchor="Implementation" numbered="true" toc="default">
	<name>Implementation Status</name>
	<t>Note to RFC Editor: Please remove this section and the reference to
	<xref target="RFC7942" format="default">RFC 7942</xref> before publicat
	ion.</t>
	<t>This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of
	this Internet-Draft, and is based on a proposal described in <xref target=
	"RFC7942" format="default">RFC
	7942</xref>. The description of implementations in this section is
	intended to assist the IETF in its decision processes in
	progressing drafts to RFCs. Please note that the listing of any
	individual implementation here does not imply endorsement by the
	IETF. Furthermore, no effort has been spent to verify the
	information presented here that was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a
	catalog of available implementations or their features. Readers
	are advised to note that other implementations may exist.</t>
	<t>According to <xref target="RFC7942" format="default">RFC 7942</xref>, "
	this will allow reviewers and working
	groups to assign due consideration to documents that have the
	benefit of running code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented
	protocols more mature. It is up to the individual working groups
	to use this information as they see fit".</t>
	<section numbered="true" toc="default">
	<name>Verisign EPP SDK</name>
	<t>Organization: Verisign Inc.</t>
	<t>Name: Verisign EPP SDK</t>
	<t>Description: The Verisign EPP SDK includes an implementation of the
	unhandled namespaces for the processing of the poll queue messages.</t>
	<t>Level of maturity: Development</t>
	<t>Coverage: All aspects of the protocol are implemented.</t>
	<t>Licensing: GNU Lesser General Public License</t>
	<t>Contact: jgould@verisign.com</t>
	<t>URL: https://www.verisign.com/en_US/channel-resources/domain-registry
	-products/epp-sdks</t>
	</section>
	<section numbered="true" toc="default">
	<name>SWITCH Automated DNSSEC Provisioning Process</name>
	<t>Organization: SWITCH</t>
	<t>Name: Registry of .CH and .LI</t>
	<t>Description: SWITCH uses poll messages to inform the registrar about
	DNSSEC changes at the registry triggered by CDS records. These poll messages are
	enriched with the 'urn:ietf:params:xml:ns:changePoll-1.0' and the 'urn:ietf:par
	ams:xml:ns:secDNS-1.1' extension that are rendered in the poll msg response acco
	rding to this draft.</t>
	<t>Level of maturity: Operational</t>
	<t>Coverage: All aspects of the protocol are implemented.</t>
	<t>Licensing: Proprietary</t>
	<t>Contact: martin.casanova@switch.ch</t>
	<t>URL: https://www.nic.ch/cds</t>
	</section>	</section>
	</section>	</section>
	<section anchor="Security" numbered="true" toc="default">	<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>This document does not provide any	<t>This document does not provide any
	security services beyond those described by <xref target="RFC5730" format= "default">EPP</xref> and protocol layers used by EPP. The security	security services beyond those described by <xref target="RFC5730" format= "default">EPP</xref> and protocol layers used by EPP. The security
	considerations described in these other specifications apply to this	considerations described in these other specifications apply to this

	specification as well. Since the unhandled namespace context is XML that	specification as well. Since the unhandled namespace content is XML that
	is not processed in the first pass by the XML parser,	is not processed in the first pass by the XML parser,
	the client SHOULD validate the XML when the content is processed to protec	the client <bcp14>SHOULD</bcp14> validate the XML when the content is proc
	t against the inclusion of malicious content.</t>	essed to protect against the inclusion of malicious content.</t>
	</section>
	<section anchor="Acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>
	<t>The authors wish to thank the following persons for their feedback and
	suggestions:
	<contact fullname="Thomas Corte"/>,
	<contact fullname="Scott Hollenbeck"/>,
	<contact fullname="Patrick Mevzek"/>,
	and <contact fullname="Marcel Parodi"/>.
	</t>
	</section>	</section>
	</middle>	</middle>

	<!-- ***BACK MATTER *** -->

	<back>	<back>

	<!-- References split into informative and normative -->

	<!-- There are 2 ways to insert reference entries from the citation librarie
	s:
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
	(as shown)
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm
	l"?> here
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.
	xml")

	Both are cited textually in the same manner: by using xref elements.
	If you use the PI option, xml2rfc will, by default, try to find included fi
	les in the same
	directory as the including file. You can also define the XML_LIBRARY enviro
	nment variable
	with a value containing a set of directories to search. These can be eithe
	r in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->

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


	&RFC2119;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>;


	&RFC3688;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.3688.xml"/>;


	&RFC5234;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5234.xml"/>;


	&RFC5730;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5730.xml"/>;


	&RFC5731;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5731.xml"/>;


	&RFC7942;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>;


	&RFC8174;	<reference anchor='W3C.REC-xml11-20060816'
		target='https://www.w3.org/TR/2006/REC-xml11-20060816'>
		<front>
		<title>Extensible Markup Language (XML) 1.1 (Second Edition)</title>

		<author initials='T.' surname='Bray' fullname='Tim Bray'>
		<organization />
		</author>

		<author initials='J.' surname='Paoli' fullname='Jean Paoli'>
		<organization />
		</author>

		<author initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg-McQu
		een'>
		<organization />
		</author>

		<author initials='E.' surname='Maler' fullname='Eve Maler'>
		<organization />
		</author>

		<author initials='F.' surname='Yergeau' fullname='FranÃ§ois Yergeau'>
		<organization />
		</author>

		<author initials='J.' surname='Cowan' fullname='John Cowan'>
		<organization />
		</author>

		<date month='August' day='16' year='2006' />
		</front>

		<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xml11-200
		60816' />
		<format type='HTML' target='https://www.w3.org/TR/2006/REC-xml11-20060816' />
		</reference>

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


	&RFC3735;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.3735.xml"/>;


	&RFC3915;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.3915.xml"/>;


	&RFC5910;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5910.xml"/>;


	&RFC7451;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7451.xml"/>;


	&RFC8590;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8590.xml"/>;

	</references>	</references>
	</references>	</references>

	<section numbered="true" toc="default">
	<name>Change History</name>	<section anchor="Acknowledgements" numbered="false" toc="default">
	<section anchor="version-00-to-01" numbered="true" toc="default">	<name>Acknowledgements</name>
	<name>Change from 00 to 01</name>	<t>The authors wish to thank the following people for their feedback and s
	<ol spacing="compact" type="1">	uggestions:
	<li>Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" refe	<contact fullname="Thomas Corte"/>,
	rence from examples.</li>	<contact fullname="Scott Hollenbeck"/>,
	<li>removed <extension></extension> block from example.</l	<contact fullname="Patrick Mevzek"/>,
	i>	and <contact fullname="Marcel Parodi"/>.
	<li>added SWITCH Automated DNSSEC Provisioning Process at Implementati	</t>
	on Status</li>
	</ol>
	</section>
	<section anchor="version-01-to-02" numbered="true" toc="default">
	<name>Change from 01 to 02</name>
	<ol spacing="compact" type="1">
	<li>Ping update</li>
	</ol>
	</section>
	<section anchor="change-02-to-WG00" numbered="true" toc="default">
	<name>Change from 02 to REGEXT 00</name>
	<ol spacing="compact" type="1">
	<li>Changed to regext working group draft by changing draft-gould-casa
	nova-regext-unhandled-namespaces to draft-ietf-regext-unhandled-namespaces.</li>
	</ol>
	</section>
	<section anchor="change-WG00-to-WG01" numbered="true" toc="default">
	<name>Change from REGEXT 00 to REGEXT 01</name>
	<ol spacing="compact" type="1">
	<li>Added the "Signaling Client and Server Support" section to describ
	e the mechanism to signal support for the BCP by the client and the server.</li>
	<li>Added the IANA Considerations section with the registration of the
	unhandled namespaces
	XML namespace and the registration of the EPP Best Current Practice
	(BCP) in the EPP Extension Registry.</li>
	</ol>
	</section>
	<section anchor="change-WG01-to-WG02" numbered="true" toc="default">
	<name>Change from REGEXT 01 to REGEXT 02</name>
	<ol spacing="compact" type="1">
	<li>Filled in the acknowledgements section.</li>
	<li>Changed the reference from RFC 5730 to RFC 5731 for the transfer e
	xample in section 3.1 "Unhandled Object-Level" Extension.</li>
	<li>Updated the XML namespace to urn:ietf:params:xml:ns:epp:unhandled-
	namespaces-1.0, which removed bcp from the namespace and bumped the version from
	0.1 and 1.0.
	Inclusion of bcp in the XML namespace was discussed at the REGEXT inte
	rim meeting.</li>
	</ol>
	</section>
	<section anchor="change-WG02-to-WG03" numbered="true" toc="default">
	<name>Change from REGEXT 02 to REGEXT 03</name>
	<ol spacing="compact" type="1">
	<li>Converted from xml2rfc v2 to v3.</li>
	<li>Updated Acknowledgements to match the approach taken by the RFC Ed
	itor with draft-ietf-regext-login-security.</li>
	<li>Changed reference of ietf-regext-change-poll to RFC 8590.</li>
	</ol>
	</section>
	<section anchor="change-WG03-to-WG04" numbered="true" toc="default">
	<name>Change from REGEXT 03 to REGEXT 04</name>
	<ol spacing="compact" type="1">
	<li>Changed from Best Current Practice (BCP) to Standards Track based
	on mailing list discussion.</li>
	<li>Revised the dates in the examples to be more up-to-date.</li>
	</ol>
	</section>
	<section anchor="change-WG04-to-WG05" numbered="true" toc="default">
	<name>Change from REGEXT 04 to REGEXT 05</name>
	<ol spacing="compact" type="1">
	<li>Based on feedback from Thomas Corte, added a description of the &l
	t;extValue> element in RFC 5730 and
	it being extended to support returning unhandled namespace informati
	on.</li>
	<li>Based on feedback from Thomas Corte, added a Implementation Consid
	erations section to cover client and server
	implementation recommendations such as monitoring unhandled namespaces
	in the server to report to the clients out-of-band and
	monitoring for responses containing unhanded namespace information in
	the client to proactively add support
	for the unhandled namespaces.</li>
	<li>Moved RFC 3735 and RFC 7451 to informative references to address d
	own reference errors in idnits.</li>
	</ol>
	</section>
	<section anchor="change-WG05-to-WG06" numbered="true" toc="default">
	<name>Change from REGEXT 05 to REGEXT 06</name>
	<ol spacing="compact" type="1">
	<li>Nit updates made based on the feedback provided by the Document Sh
	epherd, David Smith.</li>
	</ol>
	</section>
	<section anchor="change-WG06-to-WG07" numbered="true" toc="default">
	<name>Change from REGEXT 06 to REGEXT 07</name>
	<t>Updates based on the Barry Leiba (AD) feedback:
	</t>
	<ol spacing="compact" type="1">
	<li>Simplified the abstract based on the proposal provided by the AD.<
	/li>
	<li>In section 1.1, updated to use the new BCP 14 boilerplate and add
	a normative reference to RFC 8174.</li>
	<li>In section 1.1, changed "REQUIRED feature of this protocol" to "re
	quired feature of this protocol".</li>
	<li>In section 3, added "by the XML schema" in "disabled by the XML sc
	hema in [RFC5730]" to clarify the statement.</li>
	<li>In section 8.2, changed the Registrant Name from "IESG" to "IETF".
	</li>
	<li>In section 10, changed "The document do not provide" to "This docu
	ment does not provide".</li>
	<li>In section 10, added the sentence "Since the unhandled namespace c
	ontext is XML that is not processed in the first pass by the XML parser,
	the client SHOULD consider validating the XML when the content is pr
	ocessed to protect against the inclusion of malicious content.".</li>
	</ol>
	</section>
	<section anchor="change-WG07-to-WG08" numbered="true" toc="default">
	<name>Change from REGEXT 07 to REGEXT 08</name>
	<ol spacing="compact" type="1">
	<li>Nit updates made based on the feedback provided by Peter Yee.</li>
	<li>Update to the definition of the <value> element based on fee
	dback from Sabrina Tanamal.</li>
	<li>Added a sentence in the Introduction section to cover the poison p
	oll message motivation based on feedback from Qin Wu.</li>
	<li>Changed "does not define new protocol" to "does not define new EPP
	protocol elements" based on feedback from Erik Kline.</li>
	<li>Changed to use "apply" instead of "support" language in Section 3
	based on feedback from Benjamin Kaduk.</li>
	<li>Updated the examples that reference RFC examples to reference the
	RFC section of the example and have the starting XML match based on feedback fro
	m Benjamin Kaduk.</li>
	<li>Changed "SHOULD consider validating" to "SHOULD validate" in the S
	ecurity Considerations section based on feedback from Benjamin Kaduk.</li>
	<li>Moved RFC 3915, RFC 5910, and RFC 8590 as informational references
	based on feedback from Benjamin Kaduk.</li>
	</ol>
	</section>
	</section>	</section>
	</back>	</back>

	<!-- vim: set ts=2 sw=2 expandtab: -->
	</rfc>	</rfc>

End of changes. 88 change blocks.
	557 lines changed or deleted	323 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/