Internet Engineering Task Force T. Sattler Internet-Draft November 22, 2017 Intended status: Standard Track Expires: April 21, 2018 JSON response to provide Registry Maintenance Notifications within an Extensible Provisioning Protocol (EPP) poll response draft-sattler-epp-poll-maintenance-response-06 Abstract This document describes the JSON response which can be included in an Extensible Provisioning Protocol (EPP) response to provide Domain Name Registry Maintenance Notifications to Domain Name Registrars. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 April 21, 2018. Copyright Notice Copyright (c) 2017 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. Sattler Expires April 21, 2018 [Page 1] Internet-Draft Maintenance JSON Response November 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 2 2. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 3 3. Common Data Structures . . . . . . . . . . . . . . . . . . . 4 3.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Systems . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Intervention . . . . . . . . . . . . . . . . . . . . . . 5 3.4. TLDs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 4.1. EPP Command. . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Internationalisation Considerations . . . . . . . . . . . . . 7 7.1. Character Encoding . . . . . . . . . . . . . . . . . . . 7 7.2. Internationalised Domain Names . . . . . . . . . . . . . 7 7.3. Date-Time Values . . . . . . . . . . . . . . . . . . . . 7 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Motivations for using JSON . . . . . . . . . . . . . 9 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 10 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 10 B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10 B.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 10 B.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 10 B.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 10 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document describes the JSON [RFC7159] response which can be included in an Extensible Provisioning Protocol (EPP) [RFC5730] response to provide Domain Name Registry Maintenance Notifications to Domain Name Registrars. 1.1. Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when specified in their uppercase forms. The following list describes terminology and definitions used throughout this document: DNRR: Domain Name Registrar DNRY: Domain Name Registry EPP: Extensible Provisioning Protocol Sattler Expires April 21, 2018 [Page 2] Internet-Draft Maintenance JSON Response November 2017 JSON: JavaScript Object Notation NTFY: Domain Name Registry Maintenance Notification UUID: Universally Unique Identifier 2. Common Data Types JSON [RFC7159] defines the data types of a number, character string, boolean, array, object, and null. This section describes the semantics and/or syntax reference for common, JSON character strings used in this document. notifications: an array containing a single NTFY id: a string containing the NTFY ID to identify it. MUST be an UUID according [RFC4122], SHOULD NOT be changed if it gets postponed or updated purpose: a string indicating the purpose of this NTFY; MUST either be 'announce', 'change', 'cancel'. If it is cancel then everything besides id is OPTIONAL. systems: an array of objects containing name, host and impact name: a string indicating the name of affected system host: a string indicating the affected maintained system (host or IP address). hostname SHOULD be Punycode according [RFC3492]. IPv4 addresses SHOULD be dotted-decimal notation. An example of this textual representation is "192.0.2.0". IPv6 addresses SHOULD be according [RFC5952]. An example of this textual representation is "2001:db8::1:0:0:1". impact: a string impact containing the level per affected system; values are either 'partial' or 'blackout' environment: a string representing the affected maintained systems; values are 'production', 'ote', 'staging' or 'dev' start: a string containing the start of maintenance according ISO 8601 [RFC3339] YYYY-MM-DDThh:mm:ssTZ end: a string containing the end of maintenance according ISO 8601 [RFC3339] YYYY-MM-DDThh:mm:ssTZ Sattler Expires April 21, 2018 [Page 3] Internet-Draft Maintenance JSON Response November 2017 reason: a string denoting the reason for this maintenance, MAY be empty remark: a string containing an URI to detailed maintenance description, MAY be empty tlds: an array of strings containing all affected top -level domains Punycode encoded according [RFC3492] intervention: an array of booleans containing connection and implementation connection: a boolean indicating if DNRR needs to do something that is connection related, such as a reconnect. implementation: a boolean indicating if DNRR needs to do something that is implementation related, such as code changes. 3. Common Data Structures This section defines common data structures used in responses. 3.1. Notification The data structure named "notification" is an array and contains a single NTFY. An example "notification" data structure: "notification":{ "id":"2e6df9b0-4092-4491-bcc8-9fb2166dcee6", "purpose":"announce", "systems":[{ "name":"EPP", "host":"epp.registry.example", "impact":"blackout" }], "environment":"production", "start":"2017-04-30T06:00:00Z", "end":"2017-04-30T07:00:00Z", "reason":"planned maintenance", "remark":"https://www.registry.example/notice?123", "tlds":["example","test"], "intervention":{ "connection":false, "implementation":false } } 3.2. Systems Sattler Expires April 21, 2018 [Page 4] Internet-Draft Maintenance JSON Response November 2017 The data structure named "systems" is an array of objects, indicating the systems affected by the maintenance. An example "systems" data structure: "systems": [ { "name":"EPP", "host":"epp.registry.example", "impact":"partial" }, { "name":"WHOIS", "host":"whois.registry.example", "impact":"partial" }, { "name":"Portal", "host":"https://portal.registry.example", "impact":"blackout" } ] 3.3. Intervention The data structure named "intervention" is an array of booleans, each indicating if the DNRR needs to do something. An example "intervention" data structure: "intervention":{ "connection":true, "implementation":false } 3.4. TLDs The data structure named "tlds" is an array of strings indicating the affected top level domains of the DNRY. An example "intervention" data structure: "tlds":[ "example", "test" ] 4. EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in [RFC5730]. Sattler Expires April 21, 2018 [Page 5] Internet-Draft Maintenance JSON Response November 2017 4.1. EPP Command According to EPP [RFC5730], the response to an EPP command allows mixed content and also be returned without object information. Below is an example response with JSON. S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2017-02-08T22:10:00.0Z S: S: {"maintenance":[ S: {"notification":{ S: "id":"2e6df9b0-4092-4491-bcc8-9fb2166dcee6", S: "purpose":"announce", S: "systems":[{"name":"EPP","host":"epp.registry.example", S: "impact":"blackout"}], S: "environment":"production", S: "start":"2017-04-30T06:00:00Z", S: "end":"2017-04-30T07:00:00Z", S: "reason":"planned maintenance", S: "remark":"https://www.registry.example/notice?123", S: "tlds":["example","test"], S: "intervention": S: {"connection":false,"implementation":false} S: }}, S: {"notification":{ S: "id":"91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f", S: "purpose":"change", S: "systems":[{"name":"EPP","host":"epp.registry.example", S: "impact":"partial"}, S: {"name":"WHOIS","host":"whois.registry.example", S: "impact":"partial"}, S: {"name":"Portal", S: "host":"https://portal.registry.example", S: "impact":"blackout"}], S: "environment":"production", S: "start":"2017-06-15T04:30:00Z", S: "end":"2017-06-15T05:30:00Z", S: "reason":"planned maintenance", S: "remark":"https://www.registry.example/notice?456", S: "tlds":["example"], S: "intervention": S: {"connection":true,"implementation":false} S: }} S: {"notification":{ S: "id":"644e9b83-5087-4aa7-9b41-0170a0f3e00f", S: "purpose":"cancel" S: }} S: ]} Sattler Expires April 21, 2018 [Page 6] Internet-Draft Maintenance JSON Response November 2017 S: S: S: S: ABC-12346 S: 54321-XYZ S: S: S: 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations This specification models information serialized in JSON format. As JSON is a subset of JavaScript, implementations are advised to follow the security considerations outlined in Section 6 of [RFC7159] to prevent code injection. Implementers should be aware of the security considerations specified in [RFC5730]. 7. Internationalisation Considerations 7.1. Character Encoding The default text encoding for JSON responses is UTF-8 [RFC3629], and all servers and clients MUST support UTF-8. 7.2. Internationalised Domain Names Affected TLDs as mention in Section 2 SHOULD be provided in Punycode according [RFC3492]. 7.3. Date-Time Values All date-time values presented via MUST be expressed in Universal Coordinated Time using the Gregorian calendar. JSON schema allows use of time zone identifiers to indicate offsets from the zero meridian, but this option MUST NOT be used. The extended date-time form using upper case "T" and "Z" characters defined in ISO 8601 [RFC3339] MUST be used to represent date-time values. Sattler Expires April 21, 2018 [Page 7] Internet-Draft Maintenance JSON Response November 2017 8. Implementation Status Note to RFC Editor: Please remove this section and the reference to [RFC7942] before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Add implementation details once available. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646" , RFC3629, November 2003, [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, . [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, . Sattler Expires April 21, 2018 [Page 8] Internet-Draft Maintenance JSON Response November 2017 9.2. Informative References [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) ", RFC 3492, March 2003, . [RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2015, . [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, . [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of Running Code: The Implementation Status Section", RFC 7942, July 2016, Appendix A. Motivations for using JSON This section addresses a common question regarding the use of JSON over other data formats, most notably XML. It is often pointed out that DNRY and DNRR support the EPP [RFC5730] standard, which is an XML serialised protocol. The logic is that since EPP is a common protocol in the industry, it follows that XML would be a more natural choice. While that being true, the intent to use JSON is to use the already approved and reliable EPP command and its capabilities to transport mixed content without object information instead of creating a new EPP extension. The adoption of a new extension would need more time and might not be more beneficial. Sattler Expires April 21, 2018 [Page 9] Internet-Draft Maintenance JSON Response November 2017 Appendix B. Change History B.1. Change from 00 to 01 Removed JSON Schema. Clarified unique id with UUID. Added Common Data Structures for better explanation. Fixed EPP poll response example. Added und fixed References. B.2. Change from 01 to 02 Clarified host field. Added TLDs to Common Data Structure. Added Internationalisation Considerations. Changed authors address and contact details. B.3. Change from 02 to 03 Added date-time Values to Internationalisation Considerations. Sorted Terminology and Definitions alphabetically. Changed start and end date-time. Changed Reference URI to HTTPS. B.4. Change from 03 to 04 Added Acknowledgements. Clarified UUID field to be not changed at all. Clarified environment field with production, ote, staging and dev. Clarified connection and implementation fields. Fixed writing of systems field. Removed author's private address. Moved this draft from Experimental to Standard Track. B.5. Change from 04 to 05 Changed title of this draft to be more specific. Added Change Log. Split References into Normative and Informative References. Clarified Common Data Types. Rephrased Abstract and Introduction. Added Implementation Status section. B.6. Change from 05 to 06 Added IANA Considerations. Changed URIs from http to https. Added new main section 4. EPP Command Mapping. Added new JSON field purpose for announce, change or cancel of a maintenance notification. Sattler Expires April 21, 2018 [Page 10] Internet-Draft Maintenance JSON Response November 2017 Appendix C. Acknowledgements The author wishes to thank the following persons for their feedback and suggestions: * Neal McPherson of 1&1 Internet * Jody Kolker and Roger Carney of GoDaddy * Raymond Zylstra of Neustar * Andreas Huber of united-domains * Craig Marchant of VentraIP Author's Address Tobias Sattler Email: tobias.sattler@me.com URI: https://tobiassattler.com Sattler Expires April 21, 2018 [Page 11]