idnits 2.17.1 draft-sattler-epp-poll-maintenance-response-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 4, 2017) is 2334 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Sattler 2 Internet-Draft December 4, 2017 3 Intended status: Standard Track 4 Expires: May 3, 2018 6 JSON response to provide Registry Maintenance Notifications 7 within an Extensible Provisioning Protocol (EPP) poll response 8 draft-sattler-epp-poll-maintenance-response-07 10 Abstract 11 This document describes the JSON response which can be included in an 12 Extensible Provisioning Protocol (EPP) response to provide 13 Domain Name Registry Maintenance Notifications to Domain Name 14 Registrars. 16 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 This Internet-Draft will expire on May 3, 2018. 32 Copyright Notice 33 Copyright (c) 2017 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 48 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 2 49 2. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Common Data Structures . . . . . . . . . . . . . . . . . . . 4 51 3.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. Systems . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.3. Intervention . . . . . . . . . . . . . . . . . . . . . . 5 54 3.4. TLDs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. EPP Command. . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 7. Internationalisation Considerations . . . . . . . . . . . . . 7 60 7.1. Character Encoding . . . . . . . . . . . . . . . . . . . 7 61 7.2. Internationalised Domain Names . . . . . . . . . . . . . 7 62 7.3. Date-Time Values . . . . . . . . . . . . . . . . . . . . 7 63 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Appendix A. Motivations for using JSON . . . . . . . . . . . . . 9 68 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10 69 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 10 70 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 10 71 B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10 72 B.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 10 73 B.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 10 74 B.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 10 75 B.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 11 76 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 This document describes the JSON [RFC7159] response which can be 82 included in an Extensible Provisioning Protocol (EPP) [RFC5730] 83 response to provide Domain Name Registry Maintenance 84 Notifications to Domain Name Registrars. 86 1.1. Terminology and Definitions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119] when 91 specified in their uppercase forms. 93 The following list describes terminology and definitions used 94 throughout this document: 96 DNRR: Domain Name Registrar 98 DNRY: Domain Name Registry 99 EPP: Extensible Provisioning Protocol 101 JSON: JavaScript Object Notation 103 NTFY: Domain Name Registry Maintenance Notification 105 UUID: Universally Unique Identifier 107 2. Common Data Types 109 JSON [RFC7159] defines the data types of a number, character string, 110 boolean, array, object, and null. This section describes the 111 semantics and/or syntax reference for common, JSON character strings 112 used in this document. 114 maintenance: an array containing specification and one or more 115 notifications 117 specification: a string containing the URI to this document to 118 provide more details about this poll message and 119 to facilitate the adoption. 121 notification: an object containing a single NTFY 123 id: a string containing the NTFY ID to identify it. 124 MUST be an UUID according [RFC4122], SHOULD NOT 125 be changed if it gets postponed or updated 127 purpose: a string indicating the purpose of this NTFY; MUST 128 either be 'create', 'update', 'delete'. If it 129 is delete then everything besides id is OPTIONAL. 131 systems: an array of objects containing name, host and 132 impact 134 name: a string indicating the name of affected system 136 host: a string indicating the affected maintained system 137 (host or IP address). 138 hostname SHOULD be Punycode according [RFC3492]. 139 IPv4 addresses SHOULD be dotted-decimal notation. 140 An example of this textual representation is 141 "192.0.2.0". 142 IPv6 addresses SHOULD be according [RFC5952]. 143 An example of this textual representation is 144 "2001:db8::1:0:0:1". 146 impact: a string impact containing the level per affected 147 system; values are either 'partial' or 'blackout' 149 environment: a string representing the affected maintained 150 systems; values are 'production', 'ote', 'staging' 151 or 'dev' 153 start: a string containing the start of maintenance 154 according ISO 8601 [RFC3339] 155 YYYY-MM-DDThh:mm:ssTZ 157 end: a string containing the end of maintenance 158 according ISO 8601 [RFC3339] 159 YYYY-MM-DDThh:mm:ssTZ 161 reason: a string denoting the reason for this maintenance, 162 MUST either be 'planned' or 'emergency' 164 remark: a string containing an URI to detailed maintenance 165 description, MAY be empty 167 tlds: an array of strings containing all affected top 168 -level domains Punycode encoded according [RFC3492] 170 intervention: an object of booleans containing connection and 171 implementation 173 connection: a boolean indicating if DNRR needs to do 174 something that is connection related, such as a 175 reconnect. 177 implementation: a boolean indicating if DNRR needs to do 178 something that is implementation related, such as 179 code changes. 181 3. Common Data Structures 183 This section defines common data structures used in responses. 185 3.1. Notification 187 The data structure named "notification" is an object and contains a 188 single NTFY. 190 An example "notification" data structure: 192 "notification":{ 193 "id":"2e6df9b0-4092-4491-bcc8-9fb2166dcee6", 194 "purpose":"create", 195 "systems":[{ 196 "name":"EPP", 197 "host":"epp.registry.example", 198 "impact":"blackout" 199 }], 200 "environment":"production", 201 "start":"2017-04-30T06:00:00Z", 202 "end":"2017-04-30T07:00:00Z", 203 "reason":"planned", 204 "remark":"https://www.registry.example/notice?123", 205 "tlds":["example","test"], 206 "intervention":{ 207 "connection":false, 208 "implementation":false 209 } 210 } 212 3.2. Systems 214 The data structure named "systems" is an array of objects, indicating 215 the systems affected by the maintenance. 217 An example "systems" data structure: 219 "systems": 220 [ 221 { 222 "name":"EPP", 223 "host":"epp.registry.example", 224 "impact":"partial" 225 }, 226 { 227 "name":"WHOIS", 228 "host":"whois.registry.example", 229 "impact":"partial" 230 }, 231 { 232 "name":"Portal", 233 "host":"https://portal.registry.example", 234 "impact":"blackout" 235 } 236 ] 238 3.3. Intervention 240 The data structure named "intervention" is an object of booleans, 241 each indicating if the DNRR needs to do something. 243 An example "intervention" data structure: 245 "intervention":{ 246 "connection":true, 247 "implementation":false 248 } 250 3.4. TLDs 252 The data structure named "tlds" is an array of strings indicating the 253 affected top level domains of the DNRY. 255 An example "tlds" data structure: 257 "tlds":[ 258 "example", 259 "test" 260 ] 262 4. EPP Command Mapping 264 A detailed description of the EPP syntax and semantics can be found 265 in [RFC5730]. 267 4.1. EPP Command 269 According to EPP [RFC5730], the response to an EPP command 270 allows mixed content and also be returned without object information. 272 Below is an example response with JSON. 274 S: 275 S: 276 S: 277 S: 278 S: Command completed successfully; ack to dequeue 279 S: 280 S: 281 S: 2017-02-08T22:10:00.0Z 282 S: 283 S: {"maintenance":[ 284 S: {"specification":"https://datatracker.ietf.org/doc/ 285 S: draft-sattler-epp-poll-maintenance-response/"}, 286 S: {"notification":{ 287 S: "id":"2e6df9b0-4092-4491-bcc8-9fb2166dcee6", 288 S: "purpose":"create", 289 S: "systems":[{"name":"EPP","host":"epp.registry.example", 290 S: "impact":"blackout"}], 291 S: "environment":"production", 292 S: "start":"2017-04-30T06:00:00Z", 293 S: "end":"2017-04-30T07:00:00Z", 294 S: "reason":"planned", 295 S: "remark":"https://www.registry.example/notice?123", 296 S: "tlds":["example","test"], 297 S: "intervention": 298 S: {"connection":false,"implementation":false} 299 S: }}, 300 S: {"notification":{ 301 S: "id":"91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f", 302 S: "purpose":"update", 303 S: "systems":[{"name":"EPP","host":"epp.registry.example", 304 S: "impact":"partial"}, 305 S: {"name":"WHOIS","host":"whois.registry.example", 306 S: "impact":"partial"}, 307 S: {"name":"Portal", 308 S: "host":"https://portal.registry.example", 309 S: "impact":"blackout"}], 310 S: "environment":"production", 311 S: "start":"2017-06-15T04:30:00Z", 312 S: "end":"2017-06-15T05:30:00Z", 313 S: "reason":"emergency", 314 S: "remark":"https://www.registry.example/notice?456", 315 S: "tlds":["example"], 316 S: "intervention": 317 S: {"connection":true,"implementation":false} 318 S: }}, 319 S: {"notification":{ 320 S: "id":"644e9b83-5087-4aa7-9b41-0170a0f3e00f", 321 S: "purpose":"delete" 322 S: }} 323 S: ]} 324 S: 325 S: 326 S: 327 S: ABC-12346 328 S: 54321-XYZ 329 S: 330 S: 331 S: 333 5. IANA Considerations 335 This document has no actions for IANA. 337 6. Security Considerations 339 This specification models information serialized in JSON format. As 340 JSON is a subset of JavaScript, implementations are advised to follow 341 the security considerations outlined in Section 6 of [RFC7159] to 342 prevent code injection. 344 Implementers should be aware of the security considerations specified 345 in [RFC5730]. 347 7. Internationalisation Considerations 349 7.1. Character Encoding 351 The default text encoding for JSON responses is UTF-8 [RFC3629], and 352 all servers and clients MUST support UTF-8. 354 7.2. Internationalised Domain Names 356 Affected TLDs as mention in Section 2 SHOULD be provided in Punycode 357 according [RFC3492]. 359 7.3. Date-Time Values 361 All date-time values presented via MUST be expressed in Universal 362 Coordinated Time using the Gregorian calendar. JSON schema allows use 363 of time zone identifiers to indicate offsets from the zero meridian, 364 but this option MUST NOT be used. The extended date-time form using 365 upper case "T" and "Z" characters defined in ISO 8601 [RFC3339] MUST 366 be used to represent date-time values. 368 8. Implementation Status 370 Note to RFC Editor: Please remove this section and the reference to 371 [RFC7942] before publication. 373 This section records the status of known implementations of the 374 protocol defined by this specification at the time of posting of this 375 Internet-Draft, and is based on a proposal described in [RFC7942]. 376 The description of implementations in this section is intended to 377 assist the IETF in its decision processes in progressing drafts to 378 RFCs. Please note that the listing of any individual implementation 379 here does not imply endorsement by the IETF. Furthermore, no effort 380 has been spent to verify the information presented here that was 381 supplied by IETF contributors. This is not intended as, and must not 382 be construed to be, a catalog of available implementations or their 383 features. Readers are advised to note that other implementations may 384 exist. 386 According to [RFC7942], "this will allow reviewers and working groups 387 to assign due consideration to documents that have the benefit of 388 running code, which may serve as evidence of valuable experimentation 389 and feedback that have made the implemented protocols more mature. 390 It is up to the individual working groups to use this information as 391 they see fit". 393 Add implementation details once available. 395 9. References 397 9.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997, 401 . 403 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646" 404 , RFC3629, November 2003, 405 407 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 408 STD 69, RFC 5730, August 2009, 409 . 411 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 412 Interchange Format", RFC 7159, March 2014, 413 . 415 9.2. Informative References 417 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 418 Internet: Timestamps", RFC 3339, July 2002, 419 . 421 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 422 for Internationalized Domain Names in Applications (IDNA) 423 ", RFC 3492, March 2003, 424 . 426 [RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally 427 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 428 2015, 429 . 431 [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 432 Address Text Representation", RFC 5952, August 2010, 433 . 435 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 436 Running Code: The Implementation Status Section", RFC 437 7942, July 2016, 438 440 Appendix A. Motivations for using JSON 442 This section addresses a common question regarding the use of JSON 443 over other data formats, most notably XML. 445 It is often pointed out that DNRY and DNRR support the EPP 446 [RFC5730] standard, which is an XML serialised protocol. The logic 447 is that since EPP is a common protocol in the industry, it follows 448 that XML would be a more natural choice. 450 While that being true, the intent to use JSON is to use the already 451 approved and reliable EPP command and its capabilities to 452 transport mixed content without object information instead of 453 creating a new EPP extension. The adoption of a new extension would 454 need more time and might not be more beneficial. 456 Appendix B. Change History 458 B.1. Change from 00 to 01 460 Removed JSON Schema. Clarified unique id with UUID. Added 461 Common Data Structures for better explanation. Fixed EPP poll 462 response example. Added und fixed References. 464 B.2. Change from 01 to 02 466 Clarified host field. Added TLDs to Common Data Structure. Added 467 Internationalisation Considerations. Changed authors address and 468 contact details. 470 B.3. Change from 02 to 03 472 Added date-time Values to Internationalisation Considerations. 473 Sorted Terminology and Definitions alphabetically. Changed start 474 and end date-time. Changed Reference URI to HTTPS. 476 B.4. Change from 03 to 04 478 Added Acknowledgements. Clarified UUID field to be not changed at 479 all. Clarified environment field with production, ote, staging and 480 dev. Clarified connection and implementation fields. Fixed writing 481 of systems field. Removed author's private address. Moved this 482 draft from Experimental to Standard Track. 484 B.5. Change from 04 to 05 486 Changed title of this draft to be more specific. Added Change Log. 487 Split References into Normative and Informative References. Clarified 488 Common Data Types. Rephrased Abstract and Introduction. Added 489 Implementation Status section. 491 B.6. Change from 05 to 06 493 Added IANA Considerations. Changed URIs from http to https. Added 494 new main section 4. EPP Command Mapping. Added new JSON field purpose 495 for announce, change or cancel of a maintenance notification. 497 B.7. Change from 06 to 07 499 Fixed typo in section 3.4. and added missing comma in the example of 500 section 4.1. Added the field specification to help facilitate the 501 adoption of this document. Changed possible purposes to create, 502 update and delete to be closer to the EPP syntax. Cleaned 503 whitespaces. Updated Acknowledgements. 505 Appendix C. Acknowledgements 507 The author wishes to thank the following persons for their feedback 508 and suggestions (sorted alphabetically by company): 510 * Neal McPherson of 1&1 Internet 511 * Christopher Martens of Donuts 512 * Jody Kolker and Roger Carney of GoDaddy 513 * Raymond Zylstra of Neustar 514 * Andreas Huber of united-domains 515 * Craig Marchant of VentraIP 517 Author's Address 519 Tobias Sattler 521 Email: tobias.sattler@me.com 522 URI: https://tobiassattler.com