Extensible Provisioning Protocol (EPP) Unhandled Namespaces
draft-gould-casanova-regext-unhandled-namespaces-02
Document | Type |
Replaced Internet-Draft
(regext WG)
Expired & archived
|
|
---|---|---|---|
Authors | James Gould , Martin Casanova | ||
Last updated | 2020-02-14 (Latest revision 2019-09-24) | ||
Replaced by | draft-ietf-regext-unhandled-namespaces | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Adopted by a WG | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-ietf-regext-unhandled-namespaces | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
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. 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 an unhandled namespace? An unhandled namespace is a significant issue for the processing of RFC 5730 poll messages, 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. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)