<?xml version='1.0' encoding='utf-8'?> <!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.org/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 -->"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"category="std"docName="draft-ietf-regext-unhandled-namespaces-08" number="9038" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"version="3" consensus="true"> <!-- ***** FRONT MATTER ***** -->version="3"> <front> <titleabbrev="unhandledNamespaces">abbrev="Unhandled Namespaces"> Extensible Provisioning Protocol (EPP) Unhandled Namespaces</title> <seriesInfoname="Internet-Draft" value="draft-ietf-regext-unhandled-namespaces-08"/>name="RFC" value="9038"/> <author fullname="James Gould" surname="Gould"> <organization>VeriSign, Inc.</organization> <address> <postal> <street>12061 Bluemont Way</street> <city>Reston</city> <region>VA</region> <code>20190</code><country>US</country><country>United States of America</country> </postal> <email>jgould@verisign.com</email><uri>http://www.verisigninc.com</uri><uri>http://www.verisign.com</uri> </address> </author> <author fullname="Martin Casanova" surname="Casanova"> <organization>SWITCH</organization> <address> <postal> <street>P.O. Box</street> <city>Zurich</city> <code>8021</code><country>CH</country><country>Switzerland</country> </postal> <email>martin.casanova@switch.ch</email> <uri>http://www.switch.ch</uri> </address> </author> <dateday="19" month="February"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> <t>The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and thatis compliantmaintains compliance with the negotiated services defined in RFC 5730.</t> </abstract> </front> <middle> <section numbered="true" toc="default"> <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 determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs. How should the server handle service data that needs to be returned in the response when the client does not support the required service namespace URI, which is referred to as anunhandled namespace?"unhandled namespace"? An unhandled namespace is a significant issue for the processing of the poll messages described in <xref target="RFC5730"format="default"/> poll messages,format="default"/>, since poll messages are inserted by the server prior to knowing the supported client services, and the client needs to be capable of processing all poll messages. Returning an unhandled namespace poll message is not compliant with the negotiated services defined in <xref target="RFC5730"format="default"/>format="default"/>, and returning an error makes the unhandled namespace poll message a poison message by halting the processing of the poll queue. An unhandled namespace is also an issuealsofor general EPP responses when the server has information that it cannot return to the client due to the client's supported services. The server should be able to return unhandled namespace information that the client can process later. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and thatis compliantmaintains compliance with the negotiated services defined in <xref target="RFC5730" format="default"/>.</t> <section numbered="true" toc="default"> <name>Conventions Used in This Document</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>XML <xref target="W3C.REC-xml11-20060816"/> is case sensitive. Unless stated otherwise, XML specifications and examples provided in this documentMUST<bcp14>MUST</bcp14> be interpreted in the character case presented in order to develop a conforming implementation.</t> <t>In examples, "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are notarequiredfeaturefeatures of this protocol. </t> <t>The examples reference XML namespace prefixes that are used for the associated XML namespaces. ImplementationsMUST NOT<bcp14>MUST NOT</bcp14> depend on the example XML namespaces and instead employ a proper 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> <dl newline="false"spacing="compact"spacing="normal" indent="4"><dt>"changePoll":</dt><dt>changePoll:</dt> <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><dt>"secDNS":</dt><dt>secDNS:</dt> <dd>urn:ietf:params:xml:ns:secDNS-1.1</dd> </dl> <t>In the template example XML, placeholder content is represented by the following variables:</t> <dl newline="false"spacing="compact"spacing="normal" indent="4"><dt>"[NAMESPACE-XML]":</dt><dt>[NAMESPACE-XML]:</dt> <dd>XML content associated with a login service namespace URI. An example is the <domain:infData> element content in <xref target="RFC5731" format="default"/>.</dd><dt>"[NAMESPACE-URI]":</dt><dt>[NAMESPACE-URI]:</dt> <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="RFC5731" format="default"/>.</dd> </dl> </section> </section> <section anchor="unhandledNamespace" numbered="true" toc="default"> <name>Unhandled Namespaces</name> <t>AnUnhandled Namespaceunhandled namespace is an XML namespace that is associated with a response extension that is not included in the client-specified EPP login services of <xref target="RFC5730" format="default"/>. The EPP login servicesconsistsconsist of the set of XML namespace URIs included in the <objURI> or <extURI> elements of the<xref target="RFC5730" format="default"/>EPP <login>command.command <xref target="RFC5730" format="default"/>. The services supported by the server are included in the <objURI> and <extURI> elements of the EPP <greeting> <xref target="RFC5730"format="default"/> EPP <greeting>,format="default"/>, which should be 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 has information that it needs to return to theclientclient, but the namespace of the information is not supported by the client based on the negotiated EPP <login> command services.</t> </section> <section anchor="extValueApproach" numbered="true" toc="default"> <name>Use of EPP <extValue> for Unhandled Namespace Data</name> <t>In <xref target="RFC5730" format="default"/>, the <extValue> element is used to provide additional error diagnostic information, including the <value> element that identifies the client-provided element that caused a server error condition and the <reason> element containing the human-readable message that describes the reason for the error. This operational practice extends the use of the <extValue> element for the purpose of returning 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, the serverMAY<bcp14>MAY</bcp14> return a successfulresponse,response with the data for each unsupported namespace moved into an <extValue> element <xref target="RFC5730"format="default"/> <extValue> element.format="default"/>. The unhandled namespace will not cause an error response, but the unhandled namespace data will instead be moved to an <extValue> element, along with a reason why the unhandled namespace data could not be included in the appropriate location of the response. The <extValue> elementXMLwill not be processed by the XML processor. The <extValue> element contains the following child elements: </t> <dl newline="false"spacing="compact"spacing="normal" indent="4"> <dt><value>:</dt> <dd>Contains achild-elementchild element with the unhandled namespace XML. The unhandled namespaceMUST<bcp14>MUST</bcp14> be declared in the child element or any containingelementelement, including the root element. XML processing of the <value> element is disabled by the XML schema in <xref target="RFC5730" format="default"/>, so the information can safely be returned in the <value> element.</dd> <dt><reason>:</dt> <dd>Aformattedformatted, human-readable message that indicates the reason the unhandled namespace data was not returned in the appropriate location of the response. The formatted reasonSHOULD<bcp14>SHOULD</bcp14> follow the <xref target="RFC5234" format="default">Augmented Backus-Naur Form (ABNF) grammar</xref> format: NAMESPACE-URI"not" not in login services", where NAMESPACE-URI is the unhandled XML namespace like "urn:ietf:params:xml:ns:domain-1.0"forin <xref target="RFC5731" format="default"/>.</dd> </dl> <t>This document applies to the handling of unsupported namespaces for<xref target="RFC3735" format="default"/>object-level extensions and command-responseextensions.extensions <xref target="RFC3735" format="default"/>. This document does not apply to the handling of unsupported namespaces for<xref target="RFC3735" format="default"/>protocol-level extensions orauthentication information extensions.authentication-information extensions <xref target="RFC3735" format="default"/>. Refer to the following sections on how to handle an unsupported object-level extension namespace or an unsupported command-response extension namespace.</t> <section anchor="objectLevelExtension" numbered="true" toc="default"> <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 handle the namespace of the object-level extension, then the <resData> element is removed and its object-level extension child element is moved intoa <xref target="RFC5730" format="default"/>an <extValue> <value>element,element <xref target="RFC5730" format="default"/>, with the namespace URI included in the corresponding <extValue> <reason> element. The response becomes a general EPP response without the <resData> element.</t> <tkeepWithNext="true">TemplatekeepWithNext="true">Below is a template response for a supported object-level extension. 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:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: [NAMESPACE-XML] S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>]]></artwork>]]></sourcecode> <tkeepWithNext="true">TemplatekeepWithNext="true">Below is a template for an unhandled namespace response for an unsupported object-level extension. The [NAMESPACE-XML] variable represents the object-level extensionXMLXML, and the [NAMESPACE-URI] 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:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: <extValue> S: <value> S: [NAMESPACE-XML] S: </value> S: <reason> S: [NAMESPACE-URI] not in login services S: </reason> S: </extValue> S: </result> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>]]></artwork>]]></sourcecode> <t>The EPP response is converted from an object response to a general EPP response by the server when the client does not support the object-level extension namespaceURI. BelowURI.</t> <t keepWithNext="true">Below is an example ofconverting thea <transfer> query responseexample in Section 3.1.3 of(see <xref target="RFC5731"format="default"/> to an unhandled namespace response.</t> <t keepWithNext="true"><xref target="RFC5731" format="default"/> example <transfer> query responsesectionFormat="of" section="3.1.3"/>) converted into an unhandled namespaceresponse:</t> <artwork name="" type="" align="left" alt=""><![CDATA[response.</t> <sourcecode type="xml"><![CDATA[ S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: <extValue> S: <value> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example.com</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>ClientX</domain:reID> S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate> S: <domain:acID>ClientY</domain:acID> S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: </domain:trnData> S: </value> S: <reason> S: urn:ietf:params:xml:ns:domain-1.0 not in login services S: </reason> S: </extValue> S: </result> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>]]></artwork>]]></sourcecode> </section> <section anchor="commandResponseLevelExtension" numbered="true" toc="default"> <name>Unhandled Command-Response Extension</name> <t>A command-response extension in <xref target="RFC5730" format="default"/> is a child element of the <extension> element. If the client does not handle the namespace of the command-response extension, the command-response child element is moved into an<xref target="RFC5730" format="default"/><extValue> <value>element,element <xref target="RFC5730" format="default"/>, with the namespace URI included in the corresponding <extValue> <reason> element.If after moving the command-response child elementAfterwards, if there are no additional command-response child elements, the <extension> elementMUST<bcp14>MUST</bcp14> be removed.</t> <tkeepWithNext="true">TemplatekeepWithNext="true">Below is a template response for a supported command-response extension. The [NAMESPACE-XML] variable represents the command-response 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:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: [NAMESPACE-XML] S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>]]></artwork>]]></sourcecode> <tkeepWithNext="true">TemplatekeepWithNext="true">Below is a template of an unhandled namespace response for an unsupported command-response extension. The [NAMESPACE-XML] variable represents the command-response extensionXMLXML, and the [NAMESPACE-URI] variable represents the command-response 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:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: <extValue> S: <value> S: [NAMESPACE-XML] S: </value> S: <reason> S: [NAMESPACE-URI] not in login services S: </reason> S: </extValue> S: </result> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>]]></artwork>]]></sourcecode> <t>The EPP response is converted to an unhandled namespace response by moving the unhandled command-response extension from under the <extension> to an <extValue>element. Belowelement.</t> <t keepWithNext="true">Below is example ofconvertingtheDSDelegation Signer (DS) Data Interface <info> responseexample in Section 5.1.2 of(see <xref target="RFC5910"format="default"/>sectionFormat="of" section="5.1.2"/>) converted to an unhandled namespace response.</t><t keepWithNext="true"><xref target="RFC5910" format="default"/> DS Data Interface <info> response converted into an unhandled namespace response:</t> <artwork name="" type="" align="left" alt=""><![CDATA[<sourcecode type="xml"><![CDATA[ S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: <extValue> S: <value> S: <secDNS:infData S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S: <secDNS:dsData> S: <secDNS:keyTag>12345</secDNS:keyTag> S: <secDNS:alg>3</secDNS:alg> S: <secDNS:digestType>1</secDNS:digestType> S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> S: </secDNS:dsData> S: </secDNS:infData> S: </value> S: <reason> S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services S: </reason> S: </extValue> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example.com</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns2.example.com</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:upID>ClientX</domain:upID> S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response>S:</epp>]]></artwork>S:</epp> ]]></sourcecode> </section> </section> <section anchor="signal-client-server-support" numbered="true" toc="default"> <name>Signaling Client and Server Support</name> <t>This document does not define new EPP protocol elements but rather specifies an operational practice using the existing EPP protocol, where the client and the server can signal support for the operational practice 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 client includes the namespace URI in an <svcExtension> <extURI> element of the <login> command <xref target="RFC5730"format="default"/> <login> Command.format="default"/>. The server includes the namespace URI in an <svcExtension> <extURI> element of the greeting <xref target="RFC5730"format="default"/> Greeting.</t>format="default"/>.</t> <t>A client that receives the namespace URI in the server'sGreetinggreeting extension services can expect the following supported behavior by the server: </t><ol spacing="compact" type="1"> <li>Support<ul spacing="normal"> <li>support unhandled namespace object-level extensions and command-response extensions in EPP poll messages, per <xref target="usagePollMessages"format="default"/>.</li> <li>Supportformat="default"/></li> <li>support the option of unhandled namespace command-response extensions in general EPP responses, per <xref target="usageGeneralResponses"format="default"/>.</li> </ol>format="default"/></li> </ul> <t>A server that receives the namespace URI in the client's <login>Commandcommand extension services can expect the following supported behavior by the client: </t><ol spacing="compact" type="1"> <li>Support<ul spacing="normal"> <li>support monitoring the EPP poll messages and general EPP responses for unhandlednamespaces.</li> </ol>namespaces</li> </ul> </section> <section anchor="usageGeneralResponses" numbered="true" toc="default"> <name>Usage with General EPP Responses</name> <t>The unhandled namespace approach defined in <xref target="extValueApproach" format="default"/>MAY<bcp14>MAY</bcp14> be used for a general EPP response to an EPP command. A general EPP response includes anynon-poll messageEPPresponse.response that is not a poll message. The use of the unhandled namespace approach forpoll messagepoll-message EPP responses is defined in <xref target="usagePollMessages" format="default"/>. The serverMAY<bcp14>MAY</bcp14> exclude the unhandled namespace information in the general EPP response orMAY<bcp14>MAY</bcp14> include it using the unhandled namespace approach.</t> <t>The unhandled namespace approach for general EPP responsesSHOULD<bcp14>SHOULD</bcp14> only be applicable to command-response extensions, defined in <xref target="commandResponseLevelExtension" format="default"/>, since the serverSHOULD NOT<bcp14>SHOULD NOT</bcp14> accept an object-level EPP command if the client did not include the object-level namespace URI in the login services. An object-level EPP response extension is returned when the server successfully executes an object-level EPP command extension. The serverMAY<bcp14>MAY</bcp14> return an unhandled object-level extension to theclientclient, as defined in <xref target="objectLevelExtension" format="default"/>.</t> <t>Returning domain name Redemption Grace Period (RGP) data, based on <xref target="RFC3915" format="default"/>, provides an example of applying the unhandled namespace approach for a general EPP response. If the client does not include the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the loginservices,services and the domain <info> response of a domain name does have RGP information, the serverMAY<bcp14>MAY</bcp14> exclude the <rgp:infData> element from the EPP response orMAY<bcp14>MAY</bcp14> include it under the <extValue>elementelement, per <xref target="commandResponseLevelExtension"format="default"/>. Belowformat="default"/>.</t> <t keepWithNext="true">Below is an example ofconverting thea domain name <info> responseexample in Section 4.1.2 of<xreftarget="RFC3915"target="RFC5731" format="default"/> converted to an unhandlednamespace response.</t> <t keepWithNext="true"><xref target="RFC5731" format="default"/> domain name <info> response with the unhandled <xref target="RFC3915" format="default"/><rgp:infData> element (see <xref target="RFC3915" sectionFormat="of" section="4.1.1"/>) 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:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: <extValue> S: <value> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 S: rgp-1.0.xsd"> S: <rgp:rgpStatus s="redemptionPeriod"/> S: </rgp:infData> S: </value> S: <reason> S: urn:ietf:params:xml:ns:rgp-1.0 not in login services S: </reason> S: </extValue> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="pendingDelete"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns1.example.net</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:upID>ClientX</domain:upID> S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response>S:</epp>]]></artwork>S:</epp> ]]></sourcecode> </section> <section anchor="usagePollMessages" numbered="true" toc="default"> <name>Usage withPoll MessagePoll-Message EPP Responses</name> <t>The unhandled namespace approach, defined in <xref target="extValueApproach" format="default"/>,MUST<bcp14>MUST</bcp14> be used if there is unhandled namespace information included inan EPPa <poll>messageresponse. The server inserts poll messages into the client's poll queue independent of knowing the supported client loginservices, thereforeservices; therefore, there may be unhandled object-level extensions and command-response extensions included in a client's poll queue. In <xref target="RFC5730" format="default"/>, the <poll> command is used by the client to retrieve and acknowledge poll messages that have been inserted by the server. The <poll>messageresponse is an EPP response that includes the <msgQ> element that provides poll queuemeta-datametadata about the message. The unhandled namespace approach, defined in <xref target="extValueApproach" format="default"/>, is used for an unhandled object-level extension and for each of the unhandled command-response extensions attached to the <poll>messageresponse. The resultingEPP<poll>messageresponseMAY<bcp14>MAY</bcp14> have either or both the object-level extension or command-response extensions moved to <extValue> elements, as defined in <xref target="extValueApproach" format="default"/>.</t> <t>TheChange Poll Message,change poll message, as defined inSection 3.1.2 of<xref target="RFC8590"format="default"/>,sectionFormat="of" section="3.1.2"/>, which is an extension of any EPP object, is an example of applying the unhandled namespace approach forEPP<poll>messageresponses. Below are examples of converting the domain name <info> response example inSection 3.1.2 of<xref target="RFC8590"format="default"/>sectionFormat="of" section="3.1.2"/> to an unhandled namespace response. The object that will be used in the examples is a<xref target="RFC5731" format="default"/>domain nameobject.</t> <t keepWithNext="true"><xrefobject <xref target="RFC5731"format="default"/>format="default"/>.</t> <t keepWithNext="true">Below is a domain name <info> <poll>messageresponse <xref target="RFC5731" format="default"/> with the unhandled <changePoll:changeData> element <xref target="RFC8590" format="default"/><changePoll:changeData> elementincluded under an <extValue>element: </t> <artwork name="" type="" align="left" alt=""><![CDATA[element.</t> <sourcecode type="xml"><![CDATA[ S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg lang="en-US"> S: Command completed successfully; ack to dequeue</msg> S: <extValue> S: <value> S: <changePoll:changeData S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0" S: state="after"> S: <changePoll:operation>update</changePoll:operation> S: <changePoll:date> S: 2013-10-22T14:25:57.0Z</changePoll:date> S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID> S: <changePoll:who>URS Admin</changePoll:who> S: <changePoll:caseId type="urs">urs123 S: </changePoll:caseId> S: <changePoll:reason>URS Lock</changePoll:reason> S: </changePoll:changeData> S: </value> S: <reason> S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services S: </reason> S: </extValue> S: </result> S: <msgQ count="201" id="1"> S: <qDate>2013-10-22T14:25:57.0Z</qDate> S: <msg>Registry initiated update of domain.</msg> S: </msgQ> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate> S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response>S:</epp>]]></artwork>S:</epp> ]]></sourcecode> <tkeepWithNext="true">Unhandled <xref target="RFC5731" format="default"/>keepWithNext="true">Below is an unhandled domain name <info> <poll>messageresponse <xref target="RFC5731" format="default"/> and the unhandled <changePoll:changeData> element <xref target="RFC8590" format="default"/><changePoll:changeData> elementincluded under an <extValue>element: </t> <artwork name="" type="" align="left" alt=""><![CDATA[element.</t> <sourcecode type="xml"><![CDATA[ S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: <extValue> S: <value> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate> S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate> S: </domain:infData> S: </value> S: <reason> S: urn:ietf:params:xml:ns:domain-1.0 not in login services S: </reason> S: </extValue> S: <extValue> S: <value> S: <changePoll:changeData S: xmlns:changePoll= S: "urn:ietf:params:xml:ns:changePoll-1.0" S: state="after"> S: <changePoll:operation>update</changePoll:operation> S: <changePoll:date> S: 2013-10-22T14:25:57.0Z</changePoll:date> S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID> S: <changePoll:who>URS Admin</changePoll:who> S: <changePoll:caseId type="urs">urs123 S: </changePoll:caseId> S: <changePoll:reason>URS Lock</changePoll:reason> S: </changePoll:changeData> S: </value> S: <reason> S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services S: </reason> S: </extValue> S: </result> S: <msgQ count="201" id="1"> S: <qDate>2013-10-22T14:25:57.0Z</qDate> S: <msg>Registry initiated update of domain.</msg> S: </msgQ> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response>S:</epp>]]></artwork>S:</epp> ]]></sourcecode> </section> <section anchor="ImplementationConsiderations" numbered="true" toc="default"> <name>Implementation Considerations</name> <t>There are implementation considerations for the client and the server to help address the risk of the client ignoring unhandled namespace information included in an EPP response that is needed to meet technical, policy, or legal requirements. </t> <section anchor="ClientImplementationConsiderations" numbered="true" toc="default"> <name>Client Implementation Considerations</name> <t>To reduce the likelihood of a client receiving unhandled namespace information, the client should consider implementing the following:</t> <olspacing="compact" type="1">spacing="normal"> <li>Ensure that the client presents the complete set of what it supports when presenting its login services. If there are gaps between the services supported by the client and the login services included in the login command, the client may receive unhandled namespace information that the client could have supported. </li> <li>Support all of the services included in the server greeting services that may be included in an EPP response, including thepoll queue<poll> responses. The client should evaluate the gaps between the greeting services and the login services provided in the login command to identify extensions that need to be supported.</li> <li>Proactively monitor for unhandled namespace information in the EPP responses by looking for the inclusion of the <extValue> element in successful responses,recordingrecord the unsupported namespace included in the <reason> element, andrecordingrecord the unhandled namespace information included in the <value> element for later processing. The unhandled namespace should be implemented by the client to ensure that information is processed fully in future EPP responses.</li> </ol> </section> <section anchor="ServerImplementationConsiderations" numbered="true" toc="default"> <name>Server Implementation Considerations</name> <t>To assist the clients in recognizing unhandled namespaces, the server should consider implementing the following:</t> <olspacing="compact"spacing="normal" type="1"> <li>Monitor for returning unhandled namespace information to clients and report it to the clientsout-of-bandout of band toEPPEPP, so the clients can add support for the unhandlednamespaces. </li>namespaces.</li> <li>Look for the unhandled namespace support in the login services when returning optional unhandled namespace information inGeneralgeneral EPPResponses. </li>responses.</li> </ol> </section> </section> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="IANA-XML-Namespace" numbered="true" toc="default"> <name>XML Namespace</name> <t> This document uses URNs to describe XML namespaces conforming to a registry mechanism described in <xref target="RFC3688" format="default"/>. The following URI assignmentis requested of IANA:has been made by IANA. </t><t>Registration request for the unhandled namespaces namespace:</t> <ul empty="true"<dl newline="false" spacing="compact"><li>URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0</li> <li>Registrant Contact: IESG</li> <li>XML: None.<dt>URI:</dt> <dd>urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0</dd> <dt>Registrant Contact:</dt> <dd>IESG</dd> <dt>XML:</dt> <dd>None. Namespace URIs do not represent an XMLspecification.</li> </ul>specification.</dd> </dl> </section> <section anchor="EPP-Extension-Registry" numbered="true" toc="default"> <name>EPP Extension Registry</name> <t> The EPP operational practice described in this documentshould behas been registered bytheIANA in theEPP Extension Registry"Extensions for the Extensible Provisioning Protocol (EPP)" registry described in <xref target="RFC7451" format="default"/>. The details of the registration are as follows: </t><t> Name<dl newline="false" spacing="compact"> <dt>Name ofExtension: "ExtensibleExtension:</dt> <dd>"Extensible Provisioning Protocol (EPP) UnhandledNamespaces" </t> <t> Document status: Standards Track </t> <t> Reference: (insert reference to RFC version of this document) </t> <t> Registrant Name and Email Address: IETF, <iesg@ietf.org> </t> <t> TLDs: Any </t> <t> IPR Disclosure: None </t> <t> Status: Active </t> <t> Notes: None </t>Namespaces"</dd> <dt>Document Status:</dt> <dd>Standards Track</dd> <dt>Reference:</dt> <dd>RFC 9038</dd> <dt>Registrant:</dt> <dd>IETF, <iesg@ietf.org></dd> <dt>TLDs:</dt> <dd>Any</dd> <dt>IPR Disclosure:</dt> <dd>None</dd> <dt>Status:</dt> <dd>Active</dd> <dt>Notes:</dt> <dd>None</dd> </dl> </section> </section> <sectionanchor="Implementation"anchor="Security" 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 publication.</t><name>Security Considerations</name> <t>Thissection records the status of known implementations of thedocument does not provide any security services beyond those described by <xref target="RFC5730" format="default">EPP</xref> and protocoldefinedlayers used by EPP. The security considerations described in these other specifications apply to this specificationatas well. Since thetime of posting of this Internet-Draft, andunhandled namespace content isbased on a proposal described in <xref target="RFC7942" format="default">RFC 7942</xref>. The description of implementations in this sectionXML that isintended to assist the IETF in its decision processesnot processed inprogressing drafts to RFCs. Please note thatthelisting 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:params:xml:ns:secDNS-1.1' extension that are rendered in the poll msg response according 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 anchor="Security" numbered="true" toc="default"> <name>Security Considerations</name> <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 considerations described in these other specifications apply to this specification as well. Since the unhandled namespace context is XML that is not processed in the first passfirst pass by the XML parser, the clientSHOULD<bcp14>SHOULD</bcp14> validate the XML when the content is processed to protect against the inclusion of malicious content.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <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-McQueen'> <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-20060816' /> <format type='HTML' target='https://www.w3.org/TR/2006/REC-xml11-20060816' /> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3735.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3915.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5910.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8590.xml"/> </references> </references> <section anchor="Acknowledgements"numbered="true"numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors wish to thank the followingpersonspeople for their feedback and suggestions: <contact fullname="Thomas Corte"/>, <contact fullname="Scott Hollenbeck"/>, <contact fullname="Patrick Mevzek"/>, and <contact fullname="Marcel Parodi"/>. </t> </section></middle> <!-- *****BACK MATTER ***** --> <back> <!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 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.xml"?> 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 files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references> <name>References</name> <references> <name>Normative References</name> &RFC2119; &RFC3688; &RFC5234; &RFC5730; &RFC5731; &RFC7942; &RFC8174; </references> <references> <name>Informative References</name> &RFC3735; &RFC3915; &RFC5910; &RFC7451; &RFC8590; </references> </references> <section numbered="true" toc="default"> <name>Change History</name> <section anchor="version-00-to-01" numbered="true" toc="default"> <name>Change from 00 to 01</name> <ol spacing="compact" type="1"> <li>Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" reference from examples.</li> <li>removed <extension></extension> block from example.</li> <li>added SWITCH Automated DNSSEC Provisioning Process at Implementation 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-casanova-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 describe 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 example 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 interim 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 Editor 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 <extValue> element in RFC 5730 and it being extended to support returning unhandled namespace information.</li> <li>Based on feedback from Thomas Corte, added a Implementation Considerations 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 down 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 Shepherd, 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 "required feature of this protocol".</li> <li>In section 3, added "by the XML schema" in "disabled by the XML schema 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 document does not provide".</li> <li>In section 10, added the sentence "Since the unhandled namespace context 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 processed 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 feedback from Sabrina Tanamal.</li> <li>Added a sentence in the Introduction section to cover the poison poll 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 from Benjamin Kaduk.</li> <li>Changed "SHOULD consider validating" to "SHOULD validate" in the Security 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></back><!-- vim: set ts=2 sw=2 expandtab: --></rfc>