<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-regext-unhandled-namespaces" target="https://datatracker.ietf.org/doc/html/draft-ietf-regext-unhandled-namespaces-03">
   <front>
      <title>Extensible Provisioning Protocol (EPP) Unhandled Namespaces</title>
      <author initials="J." surname="Gould" fullname="James Gould">
         <organization>VeriSign, Inc.</organization>
      </author>
      <author initials="M." surname="Casanova" fullname="Martin Casanova">
         <organization>SWITCH</organization>
      </author>
      <date month="September" day="8" year="2020" />
      <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.
   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.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-regext-unhandled-namespaces-03" />
   
</reference>
