1 Internet Engineering Task Force (IETF)                          J. Gould   
    2 Request for Comments: 9038                                VeriSign, Inc.   
    3 Category: Standards Track                                    M. Casanova   
    4 ISSN: 2070-1721                                                   SWITCH   
    5                                                                 May 2021   
    8       Extensible Provisioning Protocol (EPP) Unhandled Namespaces          
   10 Abstract                                                                   
   12    The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,     
   13    includes a method for the client and server to determine the objects    
   14    to be managed during a session and the object extensions to be used     
   15    during a session.  The services are identified using namespace URIs,    
   16    and an "unhandled namespace" is one that is associated with a service   
   17    not supported by the client.  This document defines an operational      
   18    practice that enables the server to return information associated       
   19    with unhandled namespace URIs and that maintains compliance with the    
   20    negotiated services defined in RFC 5730.                                
   22 Status of This Memo                                                        
   24    This is an Internet Standards Track document.                           
   26    This document is a product of the Internet Engineering Task Force       
   27    (IETF).  It represents the consensus of the IETF community.  It has     
   28    received public review and has been approved for publication by the     
   29    Internet Engineering Steering Group (IESG).  Further information on     
   30    Internet Standards is available in Section 2 of RFC 7841.               
   32    Information about the current status of this document, any errata,      
   33    and how to provide feedback on it may be obtained at                    
   34    https://www.rfc-editor.org/info/rfc9038.                                
   36 Copyright Notice                                                           
   38    Copyright (c) 2021 IETF Trust and the persons identified as the         
   39    document authors.  All rights reserved.                                 
   41    This document is subject to BCP 78 and the IETF Trust's Legal           
   42    Provisions Relating to IETF Documents                                   
   43    (https://trustee.ietf.org/license-info) in effect on the date of        
   44    publication of this document.  Please review these documents            
   45    carefully, as they describe your rights and restrictions with respect   
   46    to this document.  Code Components extracted from this document must    
   47    include Simplified BSD License text as described in Section 4.e of      
   48    the Trust Legal Provisions and are provided without warranty as         
   49    described in the Simplified BSD License.                                
   51 Table of Contents                                                          
   53    1.  Introduction                                                        
   54      1.1.  Conventions Used in This Document                               
   55    2.  Unhandled Namespaces                                                
   56    3.  Use of EPP <extValue> for Unhandled Namespace Data                  
   57      3.1.  Unhandled Object-Level Extension                                
   58      3.2.  Unhandled Command-Response Extension                            
   59    4.  Signaling Client and Server Support                                 
   60    5.  Usage with General EPP Responses                                    
   61    6.  Usage with Poll-Message EPP Responses                               
   62    7.  Implementation Considerations                                       
   63      7.1.  Client Implementation Considerations                            
   64      7.2.  Server Implementation Considerations                            
   65    8.  IANA Considerations                                                 
   66      8.1.  XML Namespace                                                   
   67      8.2.  EPP Extension Registry                                          
   68    9.  Security Considerations                                             
   69    10. References                                                          
   70      10.1.  Normative References                                           
   71      10.2.  Informative References                                         
   72    Acknowledgements                                                        
   73    Authors' Addresses                                                      
   75 1.  Introduction                                                           
   77    The Extensible Provisioning Protocol (EPP), as defined in [RFC5730],    
   78    includes a method for the client and server to determine the objects    
   79    to be managed during a session and the object extensions to be used     
   80    during a session.  The services are identified using namespace URIs.    
   81    How should the server handle service data that needs to be returned     
   82    in the response when the client does not support the required service   
   83    namespace URI, which is referred to as an "unhandled namespace"?  An    
   84    unhandled namespace is a significant issue for the processing of the    
   85    poll messages described in [RFC5730], since poll messages are           
   86    inserted by the server prior to knowing the supported client            
   87    services, and the client needs to be capable of processing all poll     
   88    messages.  Returning an unhandled namespace poll message is not         
   89    compliant with the negotiated services defined in [RFC5730], and        
   90    returning an error makes the unhandled namespace poll message a         
   91    poison message by halting the processing of the poll queue.  An         
   92    unhandled namespace is also an issue for general EPP responses when     
   93    the server has information that it cannot return to the client due to   
   94    the client's supported services.  The server should be able to return   
   95    unhandled namespace information that the client can process later.      
   96    This document defines an operational practice that enables the server   
   97    to return information associated with unhandled namespace URIs and      
   98    that maintains compliance with the negotiated services defined in       
   99    [RFC5730].                                                              
  101 1.1.  Conventions Used in This Document                                    
  103    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  105    "OPTIONAL" in this document are to be interpreted as described in       
  106    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  107    capitals, as shown here.                                                
  109    XML [W3C.REC-xml11-20060816] is case sensitive.  Unless stated          
  110    otherwise, XML specifications and examples provided in this document    
  111    MUST be interpreted in the character case presented in order to         
  112    develop a conforming implementation.                                    
  114    In examples, "S:" represents lines returned by a protocol server.       
  115    Indentation and white space in examples are provided only to            
  116    illustrate element relationships and are not required features of       
  117    this protocol.                                                          
  119    The examples reference XML namespace prefixes that are used for the     
  120    associated XML namespaces.  Implementations MUST NOT depend on the      
  121    example XML namespaces and instead employ a proper namespace-aware      
  122    XML parser and serializer to interpret and output the XML documents.    
  123    The example namespace prefixes used and their associated XML            
  124    namespaces include:                                                     
  126    changePoll:  urn:ietf:params:xml:ns:changePoll-1.0                      
  128    domain:  urn:ietf:params:xml:ns:domain-1.0                              
  130    secDNS:  urn:ietf:params:xml:ns:secDNS-1.1                              
  132    In the template example XML, placeholder content is represented by      
  133    the following variables:                                                
  135    [NAMESPACE-XML]:  XML content associated with a login service           
  136        namespace URI.  An example is the <domain:infData> element          
  137        content in [RFC5731].                                               
  139    [NAMESPACE-URI]:  XML namespace URI associated with the [NAMESPACE-     
  140        XML] XML content.  An example is "urn:ietf:params:xml:ns:domain-    
  141        1.0" in [RFC5731].                                                  
  143 2.  Unhandled Namespaces                                                   
  145    An unhandled namespace is an XML namespace that is associated with a    
  146    response extension that is not included in the client-specified EPP     
  147    login services of [RFC5730].  The EPP login services consist of the     
  148    set of XML namespace URIs included in the <objURI> or <extURI>          
  149    elements of the EPP <login> command [RFC5730].  The services            
  150    supported by the server are included in the <objURI> and <extURI>       
  151    elements of the EPP <greeting> [RFC5730], which should be a superset    
  152    of the login services included in the EPP <login> command.  A server    
  153    may have information associated with a specific namespace that it       
  154    needs to return in the response to a client.  The unhandled             
  155    namespaces problem exists when the server has information that it       
  156    needs to return to the client, but the namespace of the information     
  157    is not supported by the client based on the negotiated EPP <login>      
  158    command services.                                                       
  160 3.  Use of EPP <extValue> for Unhandled Namespace Data                     
  162    In [RFC5730], the <extValue> element is used to provide additional      
  163    error diagnostic information, including the <value> element that        
  164    identifies the client-provided element that caused a server error       
  165    condition and the <reason> element containing the human-readable        
  166    message that describes the reason for the error.  This operational      
  167    practice extends the use of the <extValue> element for the purpose of   
  168    returning unhandled namespace information in a successful response.     
  170    When a server has data to return to the client that the client does     
  171    not support based on the login services, the server MAY return a        
  172    successful response with the data for each unsupported namespace        
  173    moved into an <extValue> element [RFC5730].  The unhandled namespace    
  174    will not cause an error response, but the unhandled namespace data      
  175    will instead be moved to an <extValue> element, along with a reason     
  176    why the unhandled namespace data could not be included in the           
  177    appropriate location of the response.  The <extValue> element will      
  178    not be processed by the XML processor.  The <extValue> element          
  179    contains the following child elements:                                  
  181    <value>:  Contains a child element with the unhandled namespace XML.    
  182        The unhandled namespace MUST be declared in the child element or    
  183        any containing element, including the root element.  XML            
  184        processing of the <value> element is disabled by the XML schema     
  185        in [RFC5730], so the information can safely be returned in the      
  186        <value> element.                                                    
  188    <reason>:  A formatted, human-readable message that indicates the       
  189        reason the unhandled namespace data was not returned in the         
  190        appropriate location of the response.  The formatted reason         
  191        SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar         
  192        [RFC5234] format: NAMESPACE-URI " not in login services", where     
  193        NAMESPACE-URI is the unhandled XML namespace like                   
  194        "urn:ietf:params:xml:ns:domain-1.0" in [RFC5731].                   
  196    This document applies to the handling of unsupported namespaces for     
  197    object-level extensions and command-response extensions [RFC3735].      
  198    This document does not apply to the handling of unsupported             
  199    namespaces for protocol-level extensions or authentication-             
  200    information extensions [RFC3735].  Refer to the following sections on   
  201    how to handle an unsupported object-level extension namespace or an     
  202    unsupported command-response extension namespace.                       
  204 3.1.  Unhandled Object-Level Extension                                     
  206    An object-level extension in [RFC5730] is a child element of the        
  207    <resData> element.  If the client does not handle the namespace of      
  208    the object-level extension, then the <resData> element is removed and   
  209    its object-level extension child element is moved into an <extValue>    
  210    <value> element [RFC5730], with the namespace URI included in the       
  211    corresponding <extValue> <reason> element.  The response becomes a      
  212    general EPP response without the <resData> element.                     
  214    Below is a template response for a supported object-level extension.    
  215    The [NAMESPACE-XML] variable represents the object-level extension      
  216    XML.                                                                    
  218    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  219    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  220    S:  <response>                                                          
  221    S:    <result code="1000">                                              
  222    S:      <msg>Command completed successfully</msg>                       
  223    S:    </result>                                                         
  224    S:    <resData>                                                         
  225    S:      [NAMESPACE-XML]                                                 
  226    S:    </resData>                                                        
  227    S:    <trID>                                                            
  228    S:      <clTRID>ABC-12345</clTRID>                                      
  229    S:      <svTRID>54322-XYZ</svTRID>                                      
  230    S:    </trID>                                                           
  231    S:  </response>                                                         
  232    S:</epp>                                                                
  234    Below is a template for an unhandled namespace response for an          
  235    unsupported object-level extension.  The [NAMESPACE-XML] variable       
  236    represents the object-level extension XML, and the [NAMESPACE-URI]      
  237    variable represents the object-level extension XML namespace URI.       
  239    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  240    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  241    S:  <response>                                                          
  242    S:    <result code="1000">                                              
  243    S:      <msg>Command completed successfully</msg>                       
  244    S:      <extValue>                                                      
  245    S:        <value>                                                       
  246    S:          [NAMESPACE-XML]                                             
  247    S:        </value>                                                      
  248    S:        <reason>                                                      
  249    S:          [NAMESPACE-URI] not in login services                       
  250    S:        </reason>                                                     
  251    S:      </extValue>                                                     
  252    S:    </result>                                                         
  253    S:    <trID>                                                            
  254    S:      <clTRID>ABC-12345</clTRID>                                      
  255    S:      <svTRID>54322-XYZ</svTRID>                                      
  256    S:    </trID>                                                           
  257    S:  </response>                                                         
  258    S:</epp>                                                                
  260    The EPP response is converted from an object response to a general      
  261    EPP response by the server when the client does not support the         
  262    object-level extension namespace URI.                                   
  264    Below is an example of a <transfer> query response (see Section 3.1.3   
  265    of [RFC5731]) converted into an unhandled namespace response.           
  267    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  268    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  269    S:  <response>                                                          
  270    S:    <result code="1000">                                              
  271    S:      <msg>Command completed successfully</msg>                       
  272    S:      <extValue>                                                      
  273    S:        <value>                                                       
  274    S:          <domain:trnData                                             
  275    S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">         
  276    S:            <domain:name>example.com</domain:name>                    
  277    S:            <domain:trStatus>pending</domain:trStatus>                
  278    S:            <domain:reID>ClientX</domain:reID>                        
  279    S:            <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>     
  280    S:            <domain:acID>ClientY</domain:acID>                        
  281    S:            <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>     
  282    S:            <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>     
  283    S:          </domain:trnData>                                           
  284    S:        </value>                                                      
  285    S:        <reason>                                                      
  286    S:          urn:ietf:params:xml:ns:domain-1.0 not in login services     
  287    S:        </reason>                                                     
  288    S:      </extValue>                                                     
  289    S:    </result>                                                         
  290    S:    <trID>                                                            
  291    S:      <clTRID>ABC-12345</clTRID>                                      
  292    S:      <svTRID>54322-XYZ</svTRID>                                      
  293    S:    </trID>                                                           
  294    S:  </response>                                                         
  295    S:</epp>                                                                
  297 3.2.  Unhandled Command-Response Extension                                 
  299    A command-response extension in [RFC5730] is a child element of the     
  300    <extension> element.  If the client does not handle the namespace of    
  301    the command-response extension, the command-response child element is   
  302    moved into an <extValue> <value> element [RFC5730], with the            
  303    namespace URI included in the corresponding <extValue> <reason>         
  304    element.  Afterwards, if there are no additional command-response       
  305    child elements, the <extension> element MUST be removed.                
  307    Below is a template response for a supported command-response           
  308    extension.  The [NAMESPACE-XML] variable represents the command-        
  309    response extension XML.                                                 
  311    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  312    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  313    S:  <response>                                                          
  314    S:    <result code="1000">                                              
  315    S:      <msg>Command completed successfully</msg>                       
  316    S:    </result>                                                         
  317    S:    <extension>                                                       
  318    S:      [NAMESPACE-XML]                                                 
  319    S:    </extension>                                                      
  320    S:    <trID>                                                            
  321    S:      <clTRID>ABC-12345</clTRID>                                      
  322    S:      <svTRID>54322-XYZ</svTRID>                                      
  323    S:    </trID>                                                           
  324    S:  </response>                                                         
  325    S:</epp>                                                                
  327    Below is a template of an unhandled namespace response for an           
  328    unsupported command-response extension.  The [NAMESPACE-XML] variable   
  329    represents the command-response extension XML, and the [NAMESPACE-      
  330    URI] variable represents the command-response extension XML namespace   
  331    URI.                                                                    
  333    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  334    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  335    S:  <response>                                                          
  336    S:    <result code="1000">                                              
  337    S:      <msg>Command completed successfully</msg>                       
  338    S:      <extValue>                                                      
  339    S:        <value>                                                       
  340    S:         [NAMESPACE-XML]                                              
  341    S:        </value>                                                      
  342    S:        <reason>                                                      
  343    S:          [NAMESPACE-URI] not in login services                       
  344    S:        </reason>                                                     
  345    S:      </extValue>                                                     
  346    S:    </result>                                                         
  347    S:    <trID>                                                            
  348    S:      <clTRID>ABC-12345</clTRID>                                      
  349    S:      <svTRID>54322-XYZ</svTRID>                                      
  350    S:    </trID>                                                           
  351    S:  </response>                                                         
  352    S:</epp>                                                                
  354    The EPP response is converted to an unhandled namespace response by     
  355    moving the unhandled command-response extension from under the          
  356    <extension> to an <extValue> element.                                   
  358    Below is example of the Delegation Signer (DS) Data Interface <info>    
  359    response (see Section 5.1.2 of [RFC5910]) converted to an unhandled     
  360    namespace response.                                                     
  362    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  363    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"                           
  364    S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">           
  365    S:  <response>                                                          
  366    S:    <result code="1000">                                              
  367    S:      <msg>Command completed successfully</msg>                       
  368    S:      <extValue>                                                      
  369    S:        <value>                                                       
  370    S:          <secDNS:infData                                             
  371    S:            xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">         
  372    S:            <secDNS:dsData>                                           
  373    S:              <secDNS:keyTag>12345</secDNS:keyTag>                    
  374    S:              <secDNS:alg>3</secDNS:alg>                              
  375    S:              <secDNS:digestType>1</secDNS:digestType>                
  376    S:              <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>     
  377    S:            </secDNS:dsData>                                          
  378    S:          </secDNS:infData>                                           
  379    S:        </value>                                                      
  380    S:        <reason>                                                      
  381    S:          urn:ietf:params:xml:ns:secDNS-1.1 not in login services     
  382    S:        </reason>                                                     
  383    S:      </extValue>                                                     
  384    S:    </result>                                                         
  385    S:    <resData>                                                         
  386    S:      <domain:infData                                                 
  387    S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">             
  388    S:        <domain:name>example.com</domain:name>                        
  389    S:        <domain:roid>EXAMPLE1-REP</domain:roid>                       
  390    S:        <domain:status s="ok"/>                                       
  391    S:        <domain:registrant>jd1234</domain:registrant>                 
  392    S:        <domain:contact type="admin">sh8013</domain:contact>          
  393    S:        <domain:contact type="tech">sh8013</domain:contact>           
  394    S:        <domain:ns>                                                   
  395    S:          <domain:hostObj>ns1.example.com</domain:hostObj>            
  396    S:          <domain:hostObj>ns2.example.com</domain:hostObj>            
  397    S:        </domain:ns>                                                  
  398    S:        <domain:host>ns1.example.com</domain:host>                    
  399    S:        <domain:host>ns2.example.com</domain:host>                    
  400    S:        <domain:clID>ClientX</domain:clID>                            
  401    S:        <domain:crID>ClientY</domain:crID>                            
  402    S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>         
  403    S:        <domain:upID>ClientX</domain:upID>                            
  404    S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>         
  405    S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>         
  406    S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>         
  407    S:        <domain:authInfo>                                             
  408    S:          <domain:pw>2fooBAR</domain:pw>                              
  409    S:        </domain:authInfo>                                            
  410    S:      </domain:infData>                                               
  411    S:    </resData>                                                        
  412    S:    <trID>                                                            
  413    S:      <clTRID>ABC-12345</clTRID>                                      
  414    S:      <svTRID>54322-XYZ</svTRID>                                      
  415    S:    </trID>                                                           
  416    S:  </response>                                                         
  417    S:</epp>                                                                
  419 4.  Signaling Client and Server Support                                    
  421    This document does not define new EPP protocol elements but rather      
  422    specifies an operational practice using the existing EPP protocol,      
  423    where the client and the server can signal support for the              
  424    operational practice using a namespace URI in the login and greeting    
  425    extension services.  The namespace URI                                  
  426    "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to        
  427    signal support for the operational practice.  The client includes the   
  428    namespace URI in an <svcExtension> <extURI> element of the <login>      
  429    command [RFC5730].  The server includes the namespace URI in an         
  430    <svcExtension> <extURI> element of the greeting [RFC5730].              
  432    A client that receives the namespace URI in the server's greeting       
  433    extension services can expect the following supported behavior by the   
  434    server:                                                                 
  436    *  support unhandled namespace object-level extensions and command-     
  437       response extensions in EPP poll messages, per Section 6              
  439    *  support the option of unhandled namespace command-response           
  440       extensions in general EPP responses, per Section 5                   
  442    A server that receives the namespace URI in the client's <login>        
  443    command extension services can expect the following supported           
  444    behavior by the client:                                                 
  446    *  support monitoring the EPP poll messages and general EPP responses   
  447       for unhandled namespaces                                             
  449 5.  Usage with General EPP Responses                                       
  451    The unhandled namespace approach defined in Section 3 MAY be used for   
  452    a general EPP response to an EPP command.  A general EPP response       
  453    includes any EPP response that is not a poll message.  The use of the   
  454    unhandled namespace approach for poll-message EPP responses is          
  455    defined in Section 6.  The server MAY exclude the unhandled namespace   
  456    information in the general EPP response or MAY include it using the     
  457    unhandled namespace approach.                                           
  459    The unhandled namespace approach for general EPP responses SHOULD       
  460    only be applicable to command-response extensions, defined in           
  461    Section 3.2, since the server SHOULD NOT accept an object-level EPP     
  462    command if the client did not include the object-level namespace URI    
  463    in the login services.  An object-level EPP response extension is       
  464    returned when the server successfully executes an object-level EPP      
  465    command extension.  The server MAY return an unhandled object-level     
  466    extension to the client, as defined in Section 3.1.                     
  468    Returning domain name Redemption Grace Period (RGP) data, based on      
  469    [RFC3915], provides an example of applying the unhandled namespace      
  470    approach for a general EPP response.  If the client does not include    
  471    the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login         
  472    services and the domain <info> response of a domain name does have      
  473    RGP information, the server MAY exclude the <rgp:infData> element       
  474    from the EPP response or MAY include it under the <extValue> element,   
  475    per Section 3.2.                                                        
  477    Below is an example of a domain name <info> response [RFC5731]          
  478    converted to an unhandled <rgp:infData> element (see Section 4.1.1 of   
  479    [RFC3915]) included under an <extValue> element:                        
  481    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  482    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"                           
  483    S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"            
  484    S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0               
  485    S:     epp-1.0.xsd">                                                    
  486    S:  <response>                                                          
  487    S:    <result code="1000">                                              
  488    S:      <msg>Command completed successfully</msg>                       
  489    S:      <extValue>                                                      
  490    S:        <value>                                                       
  491    S:          <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"     
  492    S:           xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0         
  493    S:           rgp-1.0.xsd">                                              
  494    S:            <rgp:rgpStatus s="redemptionPeriod"/>                     
  495    S:          </rgp:infData>                                              
  496    S:        </value>                                                      
  497    S:        <reason>                                                      
  498    S:          urn:ietf:params:xml:ns:rgp-1.0 not in login services        
  499    S:        </reason>                                                     
  500    S:      </extValue>                                                     
  501    S:    </result>                                                         
  502    S:    <resData>                                                         
  503    S:      <domain:infData                                                 
  504    S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"              
  505    S:        xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0         
  506    S:        domain-1.0.xsd">                                              
  507    S:        <domain:name>example.com</domain:name>                        
  508    S:        <domain:roid>EXAMPLE1-REP</domain:roid>                       
  509    S:        <domain:status s="pendingDelete"/>                            
  510    S:        <domain:registrant>jd1234</domain:registrant>                 
  511    S:        <domain:contact type="admin">sh8013</domain:contact>          
  512    S:        <domain:contact type="tech">sh8013</domain:contact>           
  513    S:        <domain:ns>                                                   
  514    S:          <domain:hostObj>ns1.example.com</domain:hostObj>            
  515    S:          <domain:hostObj>ns1.example.net</domain:hostObj>            
  516    S:        </domain:ns>                                                  
  517    S:        <domain:host>ns1.example.com</domain:host>                    
  518    S:        <domain:host>ns2.example.com</domain:host>                    
  519    S:        <domain:clID>ClientX</domain:clID>                            
  520    S:        <domain:crID>ClientY</domain:crID>                            
  521    S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>         
  522    S:        <domain:upID>ClientX</domain:upID>                            
  523    S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>         
  524    S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>         
  525    S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>         
  526    S:        <domain:authInfo>                                             
  527    S:          <domain:pw>2fooBAR</domain:pw>                              
  528    S:        </domain:authInfo>                                            
  529    S:      </domain:infData>                                               
  530    S:    </resData>                                                        
  531    S:    <trID>                                                            
  532    S:      <clTRID>ABC-12345</clTRID>                                      
  533    S:      <svTRID>54322-XYZ</svTRID>                                      
  534    S:    </trID>                                                           
  535    S:  </response>                                                         
  536    S:</epp>                                                                
  538 6.  Usage with Poll-Message EPP Responses                                  
  540    The unhandled namespace approach, defined in Section 3, MUST be used    
  541    if there is unhandled namespace information included in a <poll>        
  542    response.  The server inserts poll messages into the client's poll      
  543    queue independent of knowing the supported client login services;       
  544    therefore, there may be unhandled object-level extensions and           
  545    command-response extensions included in a client's poll queue.  In      
  546    [RFC5730], the <poll> command is used by the client to retrieve and     
  547    acknowledge poll messages that have been inserted by the server.  The   
  548    <poll> response is an EPP response that includes the <msgQ> element     
  549    that provides poll queue metadata about the message.  The unhandled     
  550    namespace approach, defined in Section 3, is used for an unhandled      
  551    object-level extension and for each of the unhandled command-response   
  552    extensions attached to the <poll> response.  The resulting <poll>       
  553    response MAY have either or both the object-level extension or          
  554    command-response extensions moved to <extValue> elements, as defined    
  555    in Section 3.                                                           
  557    The change poll message, as defined in Section 3.1.2 of [RFC8590],      
  558    which is an extension of any EPP object, is an example of applying      
  559    the unhandled namespace approach for <poll> responses.  Below are       
  560    examples of converting the domain name <info> response example in       
  561    Section 3.1.2 of [RFC8590] to an unhandled namespace response.  The     
  562    object that will be used in the examples is a domain name object        
  563    [RFC5731].                                                              
  565    Below is a domain name <info> <poll> response [RFC5731] with the        
  566    unhandled <changePoll:changeData> element [RFC8590] included under an   
  567    <extValue> element.                                                     
  569    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  570    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  571    S:  <response>                                                          
  572    S:    <result code="1301">                                              
  573    S:      <msg lang="en-US">                                              
  574    S:        Command completed successfully; ack to dequeue</msg>          
  575    S:      <extValue>                                                      
  576    S:        <value>                                                       
  577    S:          <changePoll:changeData                                      
  578    S:           xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"   
  579    S:           state="after">                                             
  580    S:            <changePoll:operation>update</changePoll:operation>       
  581    S:            <changePoll:date>                                         
  582    S:              2013-10-22T14:25:57.0Z</changePoll:date>                
  583    S:            <changePoll:svTRID>12345-XYZ</changePoll:svTRID>          
  584    S:            <changePoll:who>URS Admin</changePoll:who>                
  585    S:            <changePoll:caseId type="urs">urs123                      
  586    S:            </changePoll:caseId>                                      
  587    S:            <changePoll:reason>URS Lock</changePoll:reason>           
  588    S:          </changePoll:changeData>                                    
  589    S:        </value>                                                      
  590    S:        <reason>                                                      
  591    S:        urn:ietf:params:xml:ns:changePoll-1.0 not in login services   
  592    S:        </reason>                                                     
  593    S:      </extValue>                                                     
  594    S:    </result>                                                         
  595    S:    <msgQ count="201" id="1">                                         
  596    S:      <qDate>2013-10-22T14:25:57.0Z</qDate>                           
  597    S:      <msg>Registry initiated update of domain.</msg>                 
  598    S:    </msgQ>                                                           
  599    S:    <resData>                                                         
  600    S:      <domain:infData                                                 
  601    S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">             
  602    S:        <domain:name>domain.example</domain:name>                     
  603    S:        <domain:roid>EXAMPLE1-REP</domain:roid>                       
  604    S:        <domain:status s="ok"/>                                       
  605    S:        <domain:registrant>jd1234</domain:registrant>                 
  606    S:        <domain:contact type="admin">sh8013</domain:contact>          
  607    S:        <domain:contact type="tech">sh8013</domain:contact>           
  608    S:        <domain:clID>ClientX</domain:clID>                            
  609    S:        <domain:crID>ClientY</domain:crID>                            
  610    S:        <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>         
  611    S:        <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>         
  612    S:      </domain:infData>                                               
  613    S:    </resData>                                                        
  614    S:    <trID>                                                            
  615    S:      <clTRID>ABC-12345</clTRID>                                      
  616    S:      <svTRID>54322-XYZ</svTRID>                                      
  617    S:    </trID>                                                           
  618    S:  </response>                                                         
  619    S:</epp>                                                                
  621    Below is an unhandled domain name <info> <poll> response [RFC5731]      
  622    and the unhandled <changePoll:changeData> element [RFC8590] included    
  623    under an <extValue> element.                                            
  625    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>                
  626    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">                          
  627    S:  <response>                                                          
  628    S:    <result code="1301">                                              
  629    S:      <msg>Command completed successfully; ack to dequeue</msg>       
  630    S:      <extValue>                                                      
  631    S:        <value>                                                       
  632    S:          <domain:infData                                             
  633    S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">         
  634    S:            <domain:name>domain.example</domain:name>                 
  635    S:            <domain:roid>EXAMPLE1-REP</domain:roid>                   
  636    S:            <domain:status s="ok"/>                                   
  637    S:            <domain:registrant>jd1234</domain:registrant>             
  638    S:            <domain:contact type="admin">sh8013</domain:contact>      
  639    S:            <domain:contact type="tech">sh8013</domain:contact>       
  640    S:            <domain:clID>ClientX</domain:clID>                        
  641    S:            <domain:crID>ClientY</domain:crID>                        
  642    S:            <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>     
  643    S:            <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>     
  644    S:          </domain:infData>                                           
  645    S:        </value>                                                      
  646    S:        <reason>                                                      
  647    S:          urn:ietf:params:xml:ns:domain-1.0 not in login services     
  648    S:        </reason>                                                     
  649    S:      </extValue>                                                     
  650    S:      <extValue>                                                      
  651    S:        <value>                                                       
  652    S:          <changePoll:changeData                                      
  653    S:            xmlns:changePoll=                                         
  654    S:              "urn:ietf:params:xml:ns:changePoll-1.0"                 
  655    S:            state="after">                                            
  656    S:            <changePoll:operation>update</changePoll:operation>       
  657    S:            <changePoll:date>                                         
  658    S:              2013-10-22T14:25:57.0Z</changePoll:date>                
  659    S:            <changePoll:svTRID>12345-XYZ</changePoll:svTRID>          
  660    S:            <changePoll:who>URS Admin</changePoll:who>                
  661    S:            <changePoll:caseId type="urs">urs123                      
  662    S:            </changePoll:caseId>                                      
  663    S:            <changePoll:reason>URS Lock</changePoll:reason>           
  664    S:          </changePoll:changeData>                                    
  665    S:        </value>                                                      
  666    S:        <reason>                                                      
  667    S:        urn:ietf:params:xml:ns:changePoll-1.0 not in login services   
  668    S:        </reason>                                                     
  669    S:      </extValue>                                                     
  670    S:    </result>                                                         
  671    S:    <msgQ count="201" id="1">                                         
  672    S:      <qDate>2013-10-22T14:25:57.0Z</qDate>                           
  673    S:      <msg>Registry initiated update of domain.</msg>                 
  674    S:    </msgQ>                                                           
  675    S:    <trID>                                                            
  676    S:      <clTRID>ABC-12345</clTRID>                                      
  677    S:      <svTRID>54322-XYZ</svTRID>                                      
  678    S:    </trID>                                                           
  679    S:  </response>                                                         
  680    S:</epp>                                                                
  682 7.  Implementation Considerations                                          
  684    There are implementation considerations for the client and the server   
  685    to help address the risk of the client ignoring unhandled namespace     
  686    information included in an EPP response that is needed to meet          
  687    technical, policy, or legal requirements.                               
  689 7.1.  Client Implementation Considerations                                 
  691    To reduce the likelihood of a client receiving unhandled namespace      
  692    information, the client should consider implementing the following:     
  694    1.  Ensure that the client presents the complete set of what it         
  695        supports when presenting its login services.  If there are gaps     
  696        between the services supported by the client and the login          
  697        services included in the login command, the client may receive      
  698        unhandled namespace information that the client could have          
  699        supported.                                                          
  701    2.  Support all of the services included in the server greeting         
  702        services that may be included in an EPP response, including the     
  703        <poll> responses.  The client should evaluate the gaps between      
  704        the greeting services and the login services provided in the        
  705        login command to identify extensions that need to be supported.     
  707    3.  Proactively monitor for unhandled namespace information in the      
  708        EPP responses by looking for the inclusion of the <extValue>        
  709        element in successful responses, record the unsupported namespace   
  710        included in the <reason> element, and record the unhandled          
  711        namespace information included in the <value> element for later     
  712        processing.  The unhandled namespace should be implemented by the   
  713        client to ensure that information is processed fully in future      
  714        EPP responses.                                                      
  716 7.2.  Server Implementation Considerations                                 
  718    To assist the clients in recognizing unhandled namespaces, the server   
  719    should consider implementing the following:                             
  721    1.  Monitor for returning unhandled namespace information to clients    
  722        and report it to the clients out of band to EPP, so the clients     
  723        can add support for the unhandled namespaces.                       
  725    2.  Look for the unhandled namespace support in the login services      
  726        when returning optional unhandled namespace information in          
  727        general EPP responses.                                              
  729 8.  IANA Considerations                                                    
  731 8.1.  XML Namespace                                                        
  733    This document uses URNs to describe XML namespaces conforming to a      
  734    registry mechanism described in [RFC3688].  The following URI           
  735    assignment has been made by IANA.                                       
  737    URI:  urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0               
  738    Registrant Contact:  IESG                                               
  739    XML:  None.  Namespace URIs do not represent an XML specification.      
  741 8.2.  EPP Extension Registry                                               
  743    The EPP operational practice described in this document has been        
  744    registered by IANA in the "Extensions for the Extensible Provisioning   
  745    Protocol (EPP)" registry described in [RFC7451].  The details of the    
  746    registration are as follows:                                            
  748    Name of Extension:  "Extensible Provisioning Protocol (EPP) Unhandled   
  749       Namespaces"                                                          
  750    Document Status:  Standards Track                                       
  751    Reference:  RFC 9038                                                    
  752    Registrant:  IETF, <iesg@ietf.org>                                      
  753    TLDs:  Any                                                              
  754    IPR Disclosure:  None                                                   
  755    Status:  Active                                                         
  756    Notes:  None                                                            
  758 9.  Security Considerations                                                
  760    This document does not provide any security services beyond those       
  761    described by EPP [RFC5730] and protocol layers used by EPP.  The        
  762    security considerations described in these other specifications apply   
  763    to this specification as well.  Since the unhandled namespace content   
  764    is XML that is not processed in the first pass by the XML parser, the   
  765    client SHOULD validate the XML when the content is processed to         
  766    protect against the inclusion of malicious content.                     
  768 10.  References                                                            
  770 10.1.  Normative References                                                
  772    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  773               Requirement Levels", BCP 14, RFC 2119,                       
  774               DOI 10.17487/RFC2119, March 1997,                            
  775               <https://www.rfc-editor.org/info/rfc2119>.                   
  777    [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,     
  778               DOI 10.17487/RFC3688, January 2004,                          
  779               <https://www.rfc-editor.org/info/rfc3688>.                   
  781    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax   
  782               Specifications: ABNF", STD 68, RFC 5234,                     
  783               DOI 10.17487/RFC5234, January 2008,                          
  784               <https://www.rfc-editor.org/info/rfc5234>.                   
  786    [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",    
  787               STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,         
  788               <https://www.rfc-editor.org/info/rfc5730>.                   
  790    [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)      
  791               Domain Name Mapping", STD 69, RFC 5731,                      
  792               DOI 10.17487/RFC5731, August 2009,                           
  793               <https://www.rfc-editor.org/info/rfc5731>.                   
  795    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  796               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  797               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  799    [W3C.REC-xml11-20060816]                                                
  800               Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,        
  801               Yergeau, F., and J. Cowan, "Extensible Markup Language       
  802               (XML) 1.1 (Second Edition)", World Wide Web Consortium       
  803               Recommendation REC-xml11-20060816, 16 August 2006,           
  804               <https://www.w3.org/TR/2006/REC-xml11-20060816>.             
  806 10.2.  Informative References                                              
  808    [RFC3735]  Hollenbeck, S., "Guidelines for Extending the Extensible     
  809               Provisioning Protocol (EPP)", RFC 3735,                      
  810               DOI 10.17487/RFC3735, March 2004,                            
  811               <https://www.rfc-editor.org/info/rfc3735>.                   
  813    [RFC3915]  Hollenbeck, S., "Domain Registry Grace Period Mapping for    
  814               the Extensible Provisioning Protocol (EPP)", RFC 3915,       
  815               DOI 10.17487/RFC3915, September 2004,                        
  816               <https://www.rfc-editor.org/info/rfc3915>.                   
  818    [RFC5910]  Gould, J. and S. Hollenbeck, "Domain Name System (DNS)       
  819               Security Extensions Mapping for the Extensible               
  820               Provisioning Protocol (EPP)", RFC 5910,                      
  821               DOI 10.17487/RFC5910, May 2010,                              
  822               <https://www.rfc-editor.org/info/rfc5910>.                   
  824    [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible       
  825               Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,      
  826               February 2015, <https://www.rfc-editor.org/info/rfc7451>.    
  828    [RFC8590]  Gould, J. and K. Feher, "Change Poll Extension for the       
  829               Extensible Provisioning Protocol (EPP)", RFC 8590,           
  830               DOI 10.17487/RFC8590, May 2019,                              
  831               <https://www.rfc-editor.org/info/rfc8590>.                   
  833 Acknowledgements                                                           
  835    The authors wish to thank the following people for their feedback and   
  836    suggestions: Thomas Corte, Scott Hollenbeck, Patrick Mevzek, and        
  837    Marcel Parodi.                                                          
  839 Authors' Addresses                                                         
  841    James Gould                                                             
  842    VeriSign, Inc.                                                          
  843    12061 Bluemont Way                                                      
  844    Reston, VA 20190                                                        
  845    United States of America                                                
  847    Email: jgould@verisign.com                                              
  848    URI:   http://www.verisign.com                                          
  851    Martin Casanova                                                         
  852    SWITCH                                                                  
  853    P.O. Box                                                                
  854    CH-8021 Zurich                                                          
  855    Switzerland                                                             
  857    Email: martin.casanova@switch.ch                                        
  858    URI:   http://www.switch.ch                                             

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.