--- 1/draft-ietf-regext-unhandled-namespaces-03.txt	2020-10-21 08:13:18.253643748 -0700
+++ 2/draft-ietf-regext-unhandled-namespaces-04.txt	2020-10-21 08:13:18.281644142 -0700
@@ -1,19 +1,19 @@
 
 Network Working Group                                         J.G. Gould
 Internet-Draft                                            VeriSign, Inc.
-Intended status: Best Current Practice                     M.C. Casanova
-Expires: 12 March 2021                                            SWITCH
-                                                        8 September 2020
+Intended status: Standards Track                           M.C. Casanova
+Expires: 24 April 2021                                            SWITCH
+                                                         21 October 2020
 
       Extensible Provisioning Protocol (EPP) Unhandled Namespaces
-               draft-ietf-regext-unhandled-namespaces-03
+               draft-ietf-regext-unhandled-namespaces-04
 
 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
@@ -33,21 +33,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at https://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 12 March 2021.
+   This Internet-Draft will expire on 24 April 2021.
 
 Copyright Notice
 
    Copyright (c) 2020 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, as they describe your rights
@@ -76,20 +76,21 @@
    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
    10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
    11. Normative References  . . . . . . . . . . . . . . . . . . . .  18
    Appendix A.  Change History . . . . . . . . . . . . . . . . . . .  19
      A.1.  Change from 00 to 01  . . . . . . . . . . . . . . . . . .  19
      A.2.  Change from 01 to 02  . . . . . . . . . . . . . . . . . .  19
      A.3.  Change from 02 to REGEXT 00 . . . . . . . . . . . . . . .  19
      A.4.  Change from REGEXT 00 to REGEXT 01  . . . . . . . . . . .  19
      A.5.  Change from REGEXT 01 to REGEXT 02  . . . . . . . . . . .  19
      A.6.  Change from REGEXT 02 to REGEXT 03  . . . . . . . . . . .  20
+     A.7.  Change from REGEXT 03 to REGEXT 04  . . . . . . . . . . .  20
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20
 
 1.  Introduction
 
    The Extensible Provisioning Protocol (EPP), as defined in [RFC5730],
    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
@@ -263,24 +263,24 @@
    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:reDate>2020-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:acDate>2020-06-11T22:00:00.0Z</domain:acDate>
+   S:            <domain:exDate>2021-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>
@@ -388,46 +388,46 @@
    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:upDate>2020-12-03T09:00:00.0Z</domain:upDate>
+   S:        <domain:exDate>2021-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 does not define new protocol but a Best Current
-   Practice (BCP) using the existing EPP protocol, where the client and
-   the server can signal support for the BCP 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 used to
-   signal support for the BCP.  The client includes the namespace URI in
-   an <svcExtension> <extURI> element of the [RFC5730] <login> Command.
-   The server includes the namespace URI in an <svcExtension> <extURI>
-   element of the [RFC5730] Greeting.
+   This document does not define new protocol but an operational
+   practice using the existing EPP protocol, where the client and the
+   server can signal support for the operational practice 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 used to signal support for the operational practice.  The client
+   includes the namespace URI in an <svcExtension> <extURI> element of
+   the [RFC5730] <login> Command.  The server includes the namespace URI
+   in an <svcExtension> <extURI> element of the [RFC5730] Greeting.
 
    A client that receives the namespace URI in the server's Greeting
    extension services, can expect the following supported behavior by
    the server:
 
    1.  Support unhandled namespace object-level extensions and command-
        response extensions in EPP poll messages, per Section 6.
    2.  Support the option of unhandled namespace command-response
        extensions in general EPP responses, per Section 5.
 
@@ -497,22 +497,22 @@
    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:upDate>2020-12-03T09:00:00.0Z</domain:upDate>
+   S:        <domain:exDate>2021-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>
@@ -552,57 +552,57 @@
    S:  <response>
    S:    <result code="1301">
    S:      <msg>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-11-22T05:00:00.000Z</changePoll:date>
+   S:              2020-11-22T05:00:00.000Z</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
    S:      count="15"
    S:      id="1"
    S:    >
-   S:      <qDate>2018-08-24T19:21:51.087Z</qDate>
+   S:      <qDate>2020-11-22T05:00:00.000Z</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>change-poll.tld</domain:name>
    S:        <domain:roid>EXAMPLE1-REP</domain:roid>
    S:        <domain:status s="serverUpdateProhibited"/>
    S:        <domain:status s="serverDeleteProhibited"/>
    S:        <domain:status s="serverTransferProhibited"/>
    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-05-03T04:00:00.000Z</domain:crDate>
    S:        <domain:upID>ClientZ</domain:upID>
-   S:        <domain:upDate>2013-11-22T05:00:00.000Z</domain:upDate>
-   S:        <domain:exDate>2014-05-03T04:00:00.000Z</domain:exDate>
+   S:        <domain:upDate>2020-11-22T05:00:00.000Z</domain:upDate>
+   S:        <domain:exDate>2021-05-03T04:00:00.000Z</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>
 
    Unhandled [RFC5731] domain name <info> <poll> message response and
@@ -623,53 +623,53 @@
    S:            <domain:status s="serverUpdateProhibited"/>
    S:            <domain:status s="serverDeleteProhibited"/>
    S:            <domain:status s="serverTransferProhibited"/>
    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-05-03T04:00:00.000Z</domain:crDate>
    S:            <domain:upID>ClientZ</domain:upID>
-   S:            <domain:upDate>2013-11-22T05:00:00.000Z</domain:upDate>
-   S:            <domain:exDate>2014-05-03T04:00:00.000Z</domain:exDate>
+   S:            <domain:upDate>2020-11-22T05:00:00.000Z</domain:upDate>
+   S:            <domain:exDate>2021-05-03T04:00:00.000Z</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="urn:ietf:params:xml:ns:changePoll-1.0"
    S:            state="after">
    S:            <changePoll:operation>update</changePoll:operation>
    S:            <changePoll:date>
-   S:              2013-11-22T05:00:00.000Z</changePoll:date>
+   S:              2020-11-22T05:00:00.000Z</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
    S:      count="15"
    S:      id="1"
    S:    >
-   S:      <qDate>2018-08-24T19:23:12.822Z</qDate>
+   S:      <qDate>2020-11-22T05:00:00.000Z</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.  IANA Considerations
@@ -681,28 +681,28 @@
    assignment is requested of IANA:
 
    Registration request for the unhandled namespaces namespace:
 
       URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0
       Registrant Contact: IESG
       XML: None.  Namespace URIs do not represent an XML specification.
 
 7.2.  EPP Extension Registry
 
-   The EPP Best Current Practice (BCP) described in this document should
-   be registered by the IANA in the EPP Extension Registry described in
+   The EPP operational practice described in this document should be
+   registered by the IANA in the EPP Extension Registry described in
    [RFC7451].  The details of the registration are as follows:
 
    Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled
    Namespaces"
 
-   Document status: Best Current Practice
+   Document status: Standards Track
 
    Reference: (insert reference to RFC version of this document)
 
    Registrant Name and Email Address: IESG, <iesg@ietf.org>
 
    TLDs: Any
 
    IPR Disclosure: None
 
    Status: Active
@@ -885,20 +885,26 @@
        and 1.0.  Inclusion of bcp in the XML namespace was discussed at
        the REGEXT interim meeting.
 
 A.6.  Change from REGEXT 02 to REGEXT 03
 
    1.  Converted from xml2rfc v2 to v3.
    2.  Updated Acknowledgements to match the approach taken by the RFC
        Editor with draft-ietf-regext-login-security.
    3.  Changed reference of ietf-regext-change-poll to RFC 8590.
 
+A.7.  Change from REGEXT 03 to REGEXT 04
+
+   1.  Changed from Best Current Practice (BCP) to Standards Track based
+       on mailing list discussion.
+   2.  Revised the dates in the examples to be more up-to-date.
+
 Authors' Addresses
 
    James Gould
    VeriSign, Inc.
    12061 Bluemont Way
    Reston, VA 20190
    United States of America
 
    Email: jgould@verisign.com
    URI:   http://www.verisigninc.com