RFC 9038
Extensible Provisioning Protocol (EPP) Unhandled Namespaces
RFC 9038: Extensible Provisioning Protocol (EPP) Unhandled Namespaces 🎀
Okay bestie, so this is RFC 9038, and it's an IETF doc called Extensible Provisioning Protocol (EPP) Unhandled Namespaces. It's a Standards Track document, which means it's the official Internet Standards kind. ✨ It was written by J. Gould (VeriSign, Inc.) and M. Casanova (SWITCH), it's dated May 2021, and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates. 💅
Abstract 🦋
Okay so EPP, the Extensible Provisioning Protocol defined in RFC 5730, has a way for the client and server to figure out which objects get managed during a session and which object extensions get used during that session. 🌸 The services are named with namespace URIs, and an "unhandled namespace" is one that's tied to a service the client doesn't support. This doc defines an operational practice that lets the server send back info linked to unhandled namespace URIs, and it keeps everything compliant with the negotiated services from RFC 5730. It's giving careful and organized. 💖
Status of This Memo 📜
This one is an Internet Standards Track document. 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. 🧚
Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc9038. 🌈
Copyright Notice ©️
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. 🙈
Table of Contents 🗂️
1. Introduction
1.1. Conventions Used in This Document
2. Unhandled Namespaces
3. Use of EPP <extValue> for Unhandled Namespace Data
3.1. Unhandled Object-Level Extension
3.2. Unhandled Command-Response Extension
4. Signaling Client and Server Support
5. Usage with General EPP Responses
6. Usage with Poll-Message EPP Responses
7. Implementation Considerations
7.1. Client Implementation Considerations
7.2. Server Implementation Considerations
8. IANA Considerations
8.1. XML Namespace
8.2. EPP Extension Registry
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
Okay so EPP, as defined in [RFC5730], has a method for the client and server to decide which objects get managed during a session and which object extensions get used during that session. The services are identified using namespace URIs. 💅 Here's the tricky question: how should the server handle service data that needs to go back in the response when the client doesn't support the required service namespace URI? That's what's called an "unhandled namespace." 😭
It's a big deal for poll messages described in [RFC5730], because the server inserts poll messages before it knows which client services are supported, and the client still needs to be able to process all poll messages. Sending back an unhandled namespace poll message isn't compliant with the negotiated services defined in [RFC5730]. Returning an error is also bad, because it turns the unhandled namespace poll message into a poison message that halts processing of the poll queue. ☠️ Unhandled namespaces are also a problem for general EPP responses when the server has info it can't return to the client because of the client's supported services. The server should be able to return unhandled namespace info that the client can process later. ✨
This document defines an operational practice that lets the server return info associated with unhandled namespace URIs, and it keeps everything compliant with the negotiated services defined in [RFC5730]. 🦋
⚠️ Heads up: returning an error for an unhandled namespace poll message turns it into a poison message, because it halts processing of the poll queue. That's why this doc exists!
1.1. Conventions Used in This Document 🧠
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💖
XML [W3C.REC-xml11-20060816] is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. Case matters, so be extra careful, bestie! 🙈
In examples, "S:" represents lines returned by a protocol server. Indentation and white space in examples are only there to show how elements relate to each other. They aren't required features of this protocol. 🎀
The examples reference XML namespace prefixes that are used for the associated XML namespaces. Implementations MUST NOT depend on the example XML namespaces. Instead, they should use 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:
changePoll: urn:ietf:params:xml:ns:changePoll-1.0
domain: urn:ietf:params:xml:ns:domain-1.0
secDNS: urn:ietf:params:xml:ns:secDNS-1.1In the template example XML, placeholder content is represented by the following variables:
[NAMESPACE-XML]: XML content associated with a login service namespace URI. An example is the<domain:infData>element content in [RFC5731].[NAMESPACE-URI]: XML namespace URI associated with the[NAMESPACE-XML]XML content. An example is"urn:ietf:params:xml:ns:domain-1.0"in [RFC5731].
2. Unhandled Namespaces 🎀
An unhandled namespace is an XML namespace that's linked to a response extension, but that response extension isn't included in the client-specified EPP login services of [RFC5730]. 🧁 The EPP login services are the set of XML namespace URIs included in the <objURI> or <extURI> elements of the EPP <login> command [RFC5730]. The services the server supports are listed in the <objURI> and <extURI> elements of the EPP <greeting> [RFC5730], which should be a superset of the login services included in the EPP <login> command. 👑
A server may have info tied to a specific namespace that it needs to send back in the response to a client. The unhandled namespaces problem shows up when the server has info it needs to return to the client, but the namespace of that info isn't supported by the client based on the negotiated EPP <login> command services. 😭
3. Use of EPP <extValue> for Unhandled Namespace Data 💖
In [RFC5730], the <extValue> element gives additional error diagnostic info. It includes the <value> element, which identifies the client-provided element that caused a server error condition, and the <reason> element, which holds the human-readable message describing why the error happened. 🔍 This operational practice stretches the use of the <extValue> element so it can carry unhandled namespace info inside a successful response. It's giving creative problem-solving. 🧚
When a server has data to return to the client that the client doesn't support based on the login services, the server MAY return a successful response. In that response, the data for each unsupported namespace gets moved into an <extValue> element [RFC5730]. The unhandled namespace won't cause an error response. Instead, its data gets moved to an <extValue> element, along with a reason explaining why that data couldn't be included in the appropriate location of the response. 🌸 The XML processor won't process the <extValue> element. The <extValue> element contains the following child elements:
<value>: Contains a child element with the unhandled namespace XML. The unhandled namespace MUST be declared in the child element or in any containing element, including the root element. XML processing of the<value>element is disabled by the XML schema in [RFC5730], so the info can safely be returned in the<value>element. 🛡️<reason>: A formatted, human-readable message that indicates the reason the unhandled namespace data wasn't returned in the appropriate location of the response. The formatted reason SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format:
NAMESPACE-URI " not in login services"where NAMESPACE-URI is the unhandled XML namespace, like "urn:ietf:params:xml:ns:domain-1.0" in [RFC5731]. 🥰
This document applies to handling unsupported namespaces for object-level extensions and command-response extensions [RFC3735]. 🦋 This document does not apply to handling unsupported namespaces for protocol-level extensions or authentication-information extensions [RFC3735]. Refer to the following sections on how to handle an unsupported object-level extension namespace or an unsupported command-response extension namespace. ✨
3.1. Unhandled Object-Level Extension ✨
okay so an object-level extension from [RFC5730] is a child element of the <resData> element 🎀 If the client doesn't handle that extension's namespace, the <resData> element gets removed and its object-level extension child gets moved into an <extValue> <value> element [RFC5730]. The namespace URI goes in the matching <extValue> <reason> element 💅 Once that's done, the response is a general EPP response with no <resData> element at all.
Here's a template for a supported object-level extension. The [NAMESPACE-XML] variable stands for the object-level extension XML 🌸
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>Next up is a template for an unhandled namespace response to an unsupported object-level extension 🦋 Here, [NAMESPACE-XML] is the object-level extension XML, and [NAMESPACE-URI] is that extension's XML namespace URI.
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>The server does the conversion 🧚 When the client doesn't support the object-level extension namespace URI, the EPP response goes from an object response to a general EPP response.
Here's an example of a <transfer> query response (see Section 3.1.3 of [RFC5731]) that got converted into an unhandled namespace response 🍓
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>3.2. Unhandled Command-Response Extension 💜
a command-response extension from [RFC5730] is a child element of the <extension> element. If the client doesn't handle that extension's namespace, the command-response child element gets moved into an <extValue> <value> element [RFC5730], and the namespace URI goes in the matching <extValue> <reason> element. After that, if there are no other command-response child elements left, the <extension> element MUST be removed 🫶
Here's a template for a supported command-response extension. The [NAMESPACE-XML] variable stands for the command-response extension XML ✨
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>And here's a template for an unhandled namespace response to an unsupported command-response extension 🌈 [NAMESPACE-XML] is the command-response extension XML, and [NAMESPACE-URI] is that extension's XML namespace URI.
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>So the EPP response turns into an unhandled namespace response by lifting the unhandled command-response extension out from under <extension> and putting it in an <extValue> element 🎀
Below is an example of a Delegation Signer (DS) Data Interface <info> response (see Section 5.1.2 of [RFC5910]) converted to an unhandled namespace response 🔥
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>4. Signaling Client and Server Support 🦋
this document doesn't invent new EPP protocol elements 🙈 Instead, it describes an operational practice that uses the EPP protocol that already exists. The client and the server can signal that they support this practice by 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 the one used to signal support for the practice 👑 The client puts that URI in an <svcExtension> <extURI> element of the <login> command [RFC5730], and the server puts it in an <svcExtension> <extURI> element of the greeting [RFC5730].
A client that gets the namespace URI in the server's greeting extension services can expect the server to do the following:
- support unhandled namespace object-level extensions and command-response extensions in EPP poll messages, per Section 6
- support the option of unhandled namespace command-response extensions in general EPP responses, per Section 5
A server that gets the namespace URI in the client's <login> command extension services can expect the client to do the following:
- support monitoring the EPP poll messages and general EPP responses for unhandled namespaces 🧚
5. Usage with General EPP Responses ✨
Okay bestie, so the unhandled namespace approach from Section 3 MAY be used for a general EPP response to an EPP command 💅. A general EPP response is basically any EPP response that is not a poll message. Poll-message responses get their own rules in Section 6 🎀. The server MAY exclude the unhandled namespace information in the general EPP response or MAY include it using the unhandled namespace approach 🦋.
Now the approach for general EPP responses SHOULD only be applicable to command-response extensions, defined in Section 3.2 🌸. The reason is that the server SHOULD NOT 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 shows up when the server successfully runs an object-level EPP command extension ✨. The server MAY return an unhandled object-level extension to the client, as defined in Section 3.1 💜.
Returning domain name Redemption Grace Period (RGP) data, based on [RFC3915], is an iconic example of 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 login services, and the domain <info> response of a domain name does have RGP information, the server MAY exclude the <rgp:infData> element from the EPP response or MAY include it under the <extValue> element, per Section 3.2 🧚.
Here's an example of a domain name <info> response [RFC5731] converted to an unhandled <rgp:infData> element (see Section 4.1.1 of [RFC3915]) included under an <extValue> element 🍓:
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>6. Usage with Poll-Message EPP Responses 📬
The unhandled namespace approach, defined in Section 3, MUST be used if there is unhandled namespace information included in a <poll> response 🚨. The server drops poll messages into the client's poll queue without knowing which client login services are supported 🫶. That means there may be unhandled object-level extensions and command-response extensions sitting in a client's poll queue 😭. In [RFC5730], the <poll> command is how the client retrieves and acknowledges the poll messages the server has inserted 💌. The <poll> response is an EPP response that includes the <msgQ> element, which gives poll queue metadata about the message 📋. The unhandled namespace approach, defined in Section 3, is used for an unhandled object-level extension and for each of the unhandled command-response extensions attached to the <poll> response 🧩. The resulting <poll> response MAY have either or both the object-level extension or command-response extensions moved to <extValue> elements, as defined in Section 3 🌈.
The change poll message, as defined in Section 3.1.2 of [RFC8590], is an extension of any EPP object, and it's a perfect example of the unhandled namespace approach for <poll> responses 🔥. Below are examples of converting the domain name <info> response example in Section 3.1.2 of [RFC8590] into an unhandled namespace response. The object used in these examples is a domain name object [RFC5731] 🦋.
Here's a domain name <info> <poll> response [RFC5731] with the unhandled <changePoll:changeData> element [RFC8590] included under an <extValue> element 💖:
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>And here's an unhandled domain name <info> <poll> response [RFC5731] along with the unhandled <changePoll:changeData> element [RFC8590] included under an <extValue> element 🎀:
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>7. Implementation Considerations 🛠️
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. 🥺💜
7.1. Client Implementation Considerations 💅
okay bestie, so if a client wants to avoid getting unhandled namespace info (aka stuff it doesn't know how to handle 💀), the client should consider doing the following:
- Make sure the client presents its full set of supported services when it logs in 🔐. If there are gaps between what the client supports and the login services in the login command, the client may receive unhandled namespace information that it could have supported. Not ideal, not me 😤
- Support all of the services in the server greeting that could show up in an EPP response, including the
<poll>responses 📬. The client should look at the gaps between the greeting services and the login services from the login command to figure out which extensions it still needs to support. It's giving detective energy 🕵️♀️ - Proactively monitor for unhandled namespace information in EPP responses 👀 by looking for the
<extValue>element in successful responses. Then record the unsupported namespace from the<reason>element, and record the unhandled namespace information from the<value>element so it can be processed later 🗂️. The unhandled namespace should be implemented by the client so that the information gets fully processed in future EPP responses. Main character glow-up arc 🦋✨
7.2. Server Implementation Considerations 🌸
so now the server side! To help clients recognize unhandled namespaces, the server should consider doing the following:
- Keep an eye on when it returns unhandled namespace information to clients, and tell the clients about it out of band to EPP 📣. That way the clients can add support for those unhandled namespaces. Communication is everything, babe 🫶
- Look for the unhandled namespace support in the login services when it returns optional unhandled namespace information in general EPP responses 🔍. Lowkey the whole point of checking the login services first 💜
8. IANA Considerations 🧚
8.1. XML Namespace 🎀
okay so this document uses URNs to describe XML namespaces, following a registry mechanism described in [RFC3688] 📚. IANA has made the following URI assignment:
URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.8.2. EPP Extension Registry 🍓
IANA has registered this EPP operational practice in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451] ✨. Here's the registration, bestie:
Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled
Namespaces"
Document Status: Standards Track
Reference: RFC 9038
Registrant: IETF, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None9. Security Considerations 💀🔒
okay this section is SERIOUS, so read it carefully 🙈. This document does not provide any security services beyond those described by EPP [RFC5730] and the protocol layers EPP uses. The security considerations in those other specifications apply to this specification too 🛡️.
Here's the big one: the unhandled namespace content is XML that is not processed in the first pass by the XML parser 😱. So the client SHOULD validate the XML when the content gets processed, to protect against malicious content sneaking in. Do not skip this, periodt 🚫💅
Validate that XML, bestie. Unhandled content is not checked on the first pass, so it's on the client to check it before processing. No cap, this is the part that keeps you safe 🫶
10. References 📚
10.1. Normative References 🌷
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-xml11-20060816]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
Yergeau, F., and J. Cowan, "Extensible Markup Language
(XML) 1.1 (Second Edition)", World Wide Web Consortium
Recommendation REC-xml11-20060816, 16 August 2006,
<https://www.w3.org/TR/2006/REC-xml11-20060816>.10.2. Informative References 🦋
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
Provisioning Protocol (EPP)", RFC 3735,
DOI 10.17487/RFC3735, March 2004,
<https://www.rfc-editor.org/info/rfc3735>.
[RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
the Extensible Provisioning Protocol (EPP)", RFC 3915,
DOI 10.17487/RFC3915, September 2004,
<https://www.rfc-editor.org/info/rfc3915>.
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910,
DOI 10.17487/RFC5910, May 2010,
<https://www.rfc-editor.org/info/rfc5910>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>.
[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the
Extensible Provisioning Protocol (EPP)", RFC 8590,
DOI 10.17487/RFC8590, May 2019,
<https://www.rfc-editor.org/info/rfc8590>.Acknowledgements 🫶
The authors wish to thank these lovely people for their feedback and suggestions: Thomas Corte, Scott Hollenbeck, Patrick Mevzek, and Marcel Parodi 💖🌈
Authors' Addresses 🎀
James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: jgould@verisign.com
URI: http://www.verisign.com
Martin Casanova
SWITCH
P.O. Box
CH-8021 Zurich
Switzerland
Email: martin.casanova@switch.ch
URI: http://www.switch.ch📦 where this page comes from
- ietf: rfc9038 2021-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms