Extensible Provisioning Protocol (EPP) Unhandled Namespaces
Extracted elements (21)
Client implementation guidance recommends proactively monitoring for <extValue> in successful responses, recording unsupported namespaces from <reason> elements, and storing unhandled data from <value> elements for later processing, rather than discarding them, so the client can add support for those namespaces going forward.
Server implementation guidance recommends out-of-band reporting to clients when unhandled namespace data is returned, so clients can add support. Servers should also check for the unhandled namespace support signal in client login services before returning optional unhandled namespace information in general EPP responses.
This document reuses the existing <extValue> element from RFC 5730 (originally intended only for error diagnostics) rather than defining new EPP protocol elements. This allows signaling via an existing extension point while maintaining backward compatibility with RFC 5730.
Unhandled namespaces are a critical problem for EPP poll messages because the server inserts poll messages before knowing the client's supported services, and returning an error for an unhandled namespace would make the poll message a 'poison message' that halts queue processing. Wrapping unhandled data in <extValue> avoids both non-compliance and queue stalls.
Implementations MUST NOT depend on example XML namespace prefixes and must instead use a proper namespace-aware XML parser and serializer, since namespace prefix assignments are not normative in XML.
This document applies only to object-level extensions and command-response extensions as defined in RFC 3735. It does NOT apply to protocol-level extensions or authentication-information extensions, which must be handled differently.
For an unhandled command-response extension (a child of <extension>), if there are no additional command-response child elements after moving the unhandled one, the <extension> element MUST be removed.
For general EPP responses (non-poll), the unhandled namespace approach MAY be used; the server MAY exclude the unhandled namespace information or MAY include it using the <extValue> mechanism.
The <reason> element SHOULD follow the ABNF format: NAMESPACE-URI " not in login services", where NAMESPACE-URI is the unhandled XML namespace (e.g., "urn:ietf:params:xml:ns:domain-1.0 not in login services").
The unhandled namespace approach for general EPP responses SHOULD only apply to command-response extensions, since the server SHOULD NOT accept an object-level EPP command if the client did not include the object-level namespace URI in login services.
The unhandled namespace approach MUST be used if there is unhandled namespace information included in a <poll> response. Because poll messages are inserted independent of the client's login services, the server must use <extValue> wrapping for any unhandled object-level or command-response extensions in poll responses.
The unhandled namespace MUST be declared in the child element of <value> or any containing element, including the root element, when placing unhandled namespace data inside <extValue><value>.
When a server has data to return that the client does not support based on login services, the server MAY return a successful response with the data for each unsupported namespace moved into an <extValue> element, along with a <reason> element explaining why the data could not be returned in the normal location.
A server that includes "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" in its greeting signals that it supports unhandled namespace wrapping for both poll messages and general responses. A client that includes this URI in its login signals it will monitor responses for <extValue> elements carrying unhandled namespace data.
An 'unhandled namespace' is an XML namespace associated with a response extension not included in the client-specified EPP login services (i.e., not listed in <objURI> or <extURI> elements of the EPP <login> command). The server may have information in such a namespace that it cannot return in the standard location of the response.
For an unhandled object-level extension (a child of <resData>), the <resData> element is removed and the object-level extension child element is moved into an <extValue><value> element, converting the response from an object response to a general EPP response.
The <extValue> element, originally defined in RFC 5730 for error diagnostic information, is extended by this operational practice to carry unhandled namespace data in successful responses. It contains a <value> child (with the unhandled namespace XML) and a <reason> child (human-readable explanation). XML processing of <value> is disabled by the RFC 5730 schema.
The namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to signal support for this operational practice. The client includes it in <svcExtension><extURI> of the <login> command; the server includes it in <svcExtension><extURI> of the greeting.
IANA has registered "Extensible Provisioning Protocol (EPP) Unhandled Namespaces" in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry (RFC 7451), with Standards Track status, applicable to any TLD, and Active status.
IANA has registered the XML namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" in the IETF XML Registry (RFC 3688), with IESG as the registrant contact.
Since unhandled namespace content is XML not processed in the first pass by the XML parser, the client SHOULD validate the XML when the content is eventually processed, to protect against the inclusion of malicious content embedded in <extValue><value> elements.