Registry Maintenance Notifications through Extensible Provisioning Protocol (EPP) poll response with JSON payload
draft-sattler-epp-poll-maintenance-response-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Tobias Sattler | ||
| Last updated | 2017-10-27 | ||
| Replaced by | draft-sattler-epp-registry-maintenance | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sattler-epp-poll-maintenance-response-03
Internet Engineering Task Force T. Sattler
Internet-Draft October 28, 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-03
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
7.3. date-time Values . . . . . . . . . . . . . . . . . . . . 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:
DNRR: Domain Name Registrar
DNRY: Domain Name Registry
EPP: Extensible Provisioning Protocol
JSON: JavaScript Object Notation
NTFY: Domain Name Registry Maintenance Notification
UUID: Universally Unique Identifier
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:ssTZ
end: end of maintenance according ISO 8601 [RFC3339]
YYYY-MM-DDThh:mm:ssTZ
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.
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: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
}
}
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 <poll> response with mixed message content and without
object-specific information:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ count="4" id="12346">
S: <qDate>2017-02-08T22:10:00.0Z</qDate>
S: <msg lang="en">
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: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: "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: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: ]}
S: </msg>
S: </msgQ>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
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].
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 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)
", RFC 3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646"
, RFC3629, November 2003,
<https://www.rfc-editor.org/info/rfc3629>
[RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2015,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014,
<https://www.rfc-editor.org/info/rfc7159>.
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 <poll> 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]