--- 1/draft-ietf-regext-unhandled-namespaces-02.txt 2020-09-08 06:13:09.268443603 -0700 +++ 2/draft-ietf-regext-unhandled-namespaces-03.txt 2020-09-08 06:13:09.296443991 -0700 @@ -1,19 +1,19 @@ -Network Working Group J. Gould +Network Working Group J.G. Gould Internet-Draft VeriSign, Inc. -Intended status: Best Current Practice M. Casanova -Expires: February 1, 2021 SWITCH - July 31, 2020 +Intended status: Best Current Practice M.C. Casanova +Expires: 12 March 2021 SWITCH + 8 September 2020 Extensible Provisioning Protocol (EPP) Unhandled Namespaces - draft-ietf-regext-unhandled-namespaces-02 + draft-ietf-regext-unhandled-namespaces-03 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,63 +33,63 @@ 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 February 1, 2021. + This Internet-Draft will expire on 12 March 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 and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + 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 + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Unhandled Namespaces . . . . . . . . . . . . . . . . . . . . 4 3. Use of EPP for Unhandled Namespace Data . . . . . 4 3.1. Unhandled Object-Level Extension . . . . . . . . . . . . 5 3.2. Unhandled Command-Response Extension . . . . . . . . . . 7 4. Signaling Client and Server Support . . . . . . . . . . . . . 10 5. Usage with General EPP Responses . . . . . . . . . . . . . . 10 6. Usage with Poll Message EPP Responses . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 17 8.2. SWITCH Automated DNSSEC Provisioning Process . . . . . . 17 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 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 . . . . . . . . . . . 20 - A.5. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 20 + 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 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 @@ -529,29 +531,28 @@ poll messages that have been inserted by the server. The message response is an EPP response that includes the element that provides poll queue meta-data about the message. The unhandled namespace approach, defined in Section 3, is used for an unhandled object-level extension and for each of the unhandled command-response extensions attached to the message response. The resulting EPP message response MAY have either or both the object-level extension or command-response extensions moved to elements, as defined in Section 3. - The Change Poll Message, as defined in [I-D.ietf-regext-change-poll], - which is an extension of any EPP object, is an example of applying - the unhandled namespace approach for EPP message responses. - The object that will be used in the examples is a [RFC5731] domain - name object. + The Change Poll Message, as defined in [RFC8590], which is an + extension of any EPP object, is an example of applying the unhandled + namespace approach for EPP message responses. The object that + will be used in the examples is a [RFC5731] domain name object. [RFC5731] domain name message response with the - unhandled [I-D.ietf-regext-change-poll] - element included under an element: + unhandled [RFC8590] element included under an + element: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: Unhandled [RFC5731] domain name message response and - the unhandled [I-D.ietf-regext-change-poll] - element included under an element: + the unhandled [RFC8590] element included + under an element: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: @@ -778,33 +779,24 @@ 9. Security Considerations The document do not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well. 10. Acknowledgements The authors wish to thank the following persons for their feedback - and suggestions: - - o Scott Hollenbeck - o Patrick Mevzek - o Marcel Parodi + and suggestions: Scott Hollenbeck, Patrick Mevzek, and Marcel Parodi. 11. Normative References - [I-D.ietf-regext-change-poll] - Gould, J. and K. Feher, "Change Poll Extension for the - Extensible Provisioning Protocol (EPP)", draft-ietf- - regext-change-poll-12 (work in progress), January 2019. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible @@ -839,20 +831,25 @@ [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . + [RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the + Extensible Provisioning Protocol (EPP)", RFC 8590, + DOI 10.17487/RFC8590, May 2019, + . + Appendix A. Change History A.1. Change from 00 to 01 1. Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" reference from examples. 2. removed block from example. 3. added SWITCH Automated DNSSEC Provisioning Process at Implementation Status @@ -872,37 +869,45 @@ describe the mechanism to signal support for the BCP by the client and the server. 2. Added the IANA Considerations section with the registration of the unhandled namespaces XML namespace and the registration of the EPP Best Current Practice (BCP) in the EPP Extension Registry. A.5. Change from REGEXT 01 to REGEXT 02 1. Filled in the acknowledgements section. + 2. Changed the reference from RFC 5730 to RFC 5731 for the transfer example in section 3.1 "Unhandled Object-Level" Extension. 3. Updated the XML namespace to urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0, which removed bcp from the namespace and bumped the version from 0.1 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. + Authors' Addresses James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 - US + United States of America Email: jgould@verisign.com URI: http://www.verisigninc.com Martin Casanova SWITCH P.O. Box - Zurich, ZH 8021 - CH + CH-8021 Zurich + Switzerland Email: martin.casanova@switch.ch URI: http://www.switch.ch