Internet Engineering Task Force T. Sattler Internet-Draft October 27, 2017 Intended status: Experimental Expires: November 30, 2017 Registry Maintenance Notifications through Extensible Provisioning Protocol (EPP) poll response with JSON payload draft-sattler-epp-poll-maintenance-response-02 Abstract This document describes the JSON payload of an Extensible Provisioning Protocol (EPP) poll 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 http://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." 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 (http://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 November 30, 2017 [Page 1] Internet-Draft Maintenance JSON Response October 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 poll response . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Internationalisation Considerations . . . . . . . . . . . . . 7 7.1. Character Encoding . . . . . . . . . . . . . . . . . . . 7 7.2. Internationalised Domain Names . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Motivations for using JSON . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document describes the JSON [RFC7159] payload of an Extensible Provisioning Protocol (EPP) [RFC5730] poll 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: EPP: Extensible Provisioning Protocol DNRY: Domain Name Registry DNRR: Domain Name Registrar JSON: JavaScript Object Notation NTFY: Domain Name Registry Maintenance Notification Sattler Expires November 30, 2017 [Page 2] Internet-Draft Maintenance JSON Response October 2017 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: contains a single NTFY id: UUID according [RFC4122] for each NTFY, SHOULD NOT be changed if it gets postponed systems: contains name, host and impact name: name of affected system host: affected maintained system (host or ip). 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: impact level per affected sytem; values are either 'partial' or 'blackout' environment: environment of affected maintained system start: start of maintenance according ISO 8601 [RFC3339] YYYY-MM-DDThh:mm:ssTZD end: end of maintenance according ISO 8601 [RFC3339] YYYY-MM-DDThh:mm:ssTZD reason: free text why it is necessary, MAY be empty remark: URI to detailed maintenance description, MAY be empty tlds: contains affected top-level domains punycode encoded according [RFC3492] intervention: contains connection and implementation connection: true or false - indicates if DNRR needs to do something that is connection related implementation: true or false - indicates if DNRR needs to do something that is implementation related Sattler Expires November 30, 2017 [Page 3] Internet-Draft Maintenance JSON Response October 2017 3. Common Data Structures This section defines common data structures used in responses and object classes. 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", "system":[{ "name":"EPP", "host":"epp.registry.example", "impact":"blackout" }], "environment":"production", "start":"2017-04-30T06:00:00+00:00", "end":"2017-04-30T07:00:00+00:00", "reason":"planned maintenance", "remark":"http//portal.registry.example/maintenance-desc", "tlds":["example","test"], "intervention":{ "connection":false, "implementation":false } } Sattler Expires November 30, 2017 [Page 4] Internet-Draft Maintenance JSON Response October 2017 3.2. Systems The data structure named "systems" is an array of strings, 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 boolean, 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 poll response According to EPP [RFC5730], the EPP poll response allows mixed content and also be returned without object information. Sattler Expires November 30, 2017 [Page 5] Internet-Draft Maintenance JSON Response October 2017 Example response with mixed message content and without object-specific information: 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: "system":[{"name":"EPP","host":"epp.registry.example", S: "impact":"blackout"}], S: "environment":"production", S: "start":"2017-04-30T06:00:00+00:00", S: "end":"2017-04-30T07:00:00+00:00", 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: "system":[{"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:00+00:00", S: "end":"2017-06-15T05:30:00+00:00", S: "reason":"planned maintenance", S: "remark":"https://www.registry.example/notice?123", S: "tlds":["example"], S: "intervention": S: {"connection":true,"implementation":false} S: }} S: ]} S: S: S: S: ABC-12346 S: 54321-XYZ S: S: S: Sattler Expires November 30, 2017 [Page 6] Internet-Draft Maintenance JSON Response October 2017 5. IANA Considerations 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 in RDAP 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]. Sattler Expires November 30, 2017 [Page 7] Internet-Draft Maintenance JSON Response October 2017 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646" , RFC3629, November 2003, [RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2015, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, . [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, . Sattler Expires November 30, 2017 [Page 8] Internet-Draft Maintenance JSON Response October 2017 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. Author's Address Tobias Sattler Hauptstr. 5 85586 Poing DE Email: tobias.sattler@me.com URI: https://tobiassattler.com Sattler Expires November 30, 2017 [Page 9]