idnits 2.17.1 draft-lozano-ietf-regext-registrar-expiration-date-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2016) is 2740 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) ** Downref: Normative reference to an Informational RFC: RFC 3735 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Standards Track October 24, 2016 5 Expires: April 27, 2017 7 Registrar Registration Expiration Date Extension Mapping for the 8 Extensible Provisioning Protocol (EPP) 9 draft-lozano-ietf-regext-registrar-expiration-date-00 11 Abstract 13 This document describes an Extensible Provisioning Protocol (EPP) 14 extension mapping for the provisioning and management of the 15 registrar registration expiration date for domain names stored in a 16 shared central repository. Specified in XML, this mapping extends 17 the EPP domain name mapping. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 27, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Object Elements . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Synchronize Registry and Registrar Expiration Date . . . 3 57 2.2. Registrar Registration Expiration Date . . . . . . . . . 4 58 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. EPP Query commands . . . . . . . . . . . . . . . . . . . 4 60 3.2. EPP Transform commands . . . . . . . . . . . . . . . . . 6 61 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. rrExDate Schema . . . . . . . . . . . . . . . . . . . . . 10 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 7. Internationalization Considerations . . . . . . . . . . . . . 12 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 9.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 This document describes an extension mapping for version 1.0 of the 75 Extensible Provisioning Protocol (EPP) described in RFC [RFC5730]. 76 This mapping, an extension of the domain name mapping described in 77 RFC [RFC5731], is specified using the Extensible Markup Language 78 (XML) 1.0 [W3C.REC-xml] and XML Schema notation 79 ([W3C.REC-xmlschema-1] [W3C.REC-xmlschema-2]). 81 The EPP core protocol specification [RFC5730] provides a complete 82 description of EPP command and response structures. A thorough 83 understanding of the base protocol specification is necessary to 84 understand the mapping described in this document. 86 This document is written following the Guidelines for Extending the 87 Extensible Provisioning Protocol as defined in [RFC3735]. 89 This extension is defined in order to support the Internet 90 Corporation for Assigned Names and Numbers (ICANN) Thick Whois Policy 91 Recommendation [ThickWhoisPolicy] that allows gTLD domain name 92 registries to display the registrar registration expiration date in 93 the Registration Data Directory Service (e.g. Whois, RDAP). 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 In examples, "C:" represents lines sent by a protocol client, and 102 "S:" represents lines returned by a protocol server. "////" is used 103 to note element values that have been shortened to better fit page 104 boundaries. Indentation and white space in examples is provided only 105 to illustrate element relationships and is not a mandatory feature of 106 this protocol. 108 XML is case sensitive. Unless stated otherwise, XML specifications 109 and examples provided in this document MUST be interpreted in the 110 character case presented in order to develop a conforming 111 implementation. 113 rrExDate-1.0 is used as an abbreviation for 114 urn:ietf:params:xml:ns:rrExDate-1.0. The XML namespace prefix 115 "rrExDate" is used, but implementations MUST NOT depend on it and 116 instead employ a proper namespace-aware XML parser and serializer to 117 interpret and output the XML documents. 119 2. Object Elements 121 This extension adds additional elements to the EPP domain name 122 mapping [RFC5731]. Only those new elements are described here. 124 2.1. Synchronize Registry and Registrar Expiration Date 126 A element MUST contain a "flag" attribute. 127 The "flag" attribute contains an XML Schema boolean value. 129 A value of "true" or "1" (one) indicates that the registrar 130 registration expiration date shall have the same value as the 131 registry expiration date of the domain object () at 132 all times. 134 A value of "false" or "0" (zero) indicates that the registrar 135 registration expiration date is defined in . 137 A value of "false" or "0" (zero) without an 138 element indicates that the registrar registration expiration date 139 is not defined, or shall be removed, as the case may be. 141 2.2. Registrar Registration Expiration Date 143 An OPTIONAL element is used by the registrar to 144 specify the value of the registrar registration expiration date. The 145 element MUST NOT be included, if the "flag" 146 attribute in is set to "true" or "1" 147 (one). 149 3. EPP Command Mapping 151 A detailed description of the EPP syntax and semantics can be found 152 in the EPP core protocol specification [RFC5730]. The command 153 mappings described here are specifically for use in provisioning and 154 managing of the registrar registration expiration date via EPP. 156 3.1. EPP Query commands 158 EPP provides three commands to retrieve object information: 159 to determine if an object is known to the server, to retrieve 160 detailed information associated with an object, and to 161 retrieve object transfer status information. 163 3.1.1. EPP command 165 This extension does not add any elements to the EPP command 166 or response described in the EPP domain mapping [RFC5731]. 168 3.1.2. EPP command 170 This extension does not add any elements to the EPP command, 171 but does include elements in the response. 173 After an info command has been processed successfully, the server 174 MUST include a object in the 175 section of the EPP response. 177 Example response for a domain object: 179 S: 180 S: 182 S: 183 S: 184 S: Command completed successfully 185 S: 186 S: 187 S: 189 S: example.com 190 S: EXAMPLE1-REP 191 S: 192 S: jd1234 193 S: sh8013 194 S: sh8013 195 S: 196 S: ns1.example.com 197 S: ns1.example.net 198 S: 199 S: ClientX 200 S: ClientY 201 S: 1999-04-03T22:00:00.0Z 202 S: ClientX 203 S: 1999-12-03T09:00:00.0Z 204 S: 2005-04-03T22:00:00.0Z 205 S: 2000-04-08T09:00:00.0Z 206 S: 207 S: 2fooBAR 208 S: 209 S: 210 S: 211 S: 212 S: 214 S: 215 S: 216 S: 2004-04-03T22:00:00.0Z 217 S: 218 S: 219 S: 220 S: 221 S: 222 S: ABC-12345 223 S: 54322-XYZ 224 S: 225 S: 226 S: 227 3.1.3. EPP command 229 This extension does not add any elements to the EPP 230 command or response described in the EPP domain mapping 231 [RFC5731]. 233 3.2. EPP Transform commands 235 The following general requirements apply to the , , 236 , and commands: 238 A server MUST return a 2004 response code when receiving an EPP 239 transform command that includes this extension with a value in the 240 element that precedes the creation date of the 241 domain object (). 243 A server MUST return a 2002 response code when receiving an EPP 244 transform command that includes this extension with a 245 element, and a value of "true" or "1" (one) in 246 the "flag" attribute in the element. 248 3.2.1. EPP command 250 This extension defines additional elements for the EPP 251 command. The general requirements for EPP transform commands 252 described above apply to the EPP command. 254 This extension does not add any elements to the EPP response 255 described in the EPP domain mapping [RFC5731]. 257 Example command: 259 C: 260 C: 262 C: 263 C: 264 C: 266 C: example.com 267 C: 2 268 C: 269 C: ns1.example.net 270 C: ns2.example.net 271 C: 272 C: jd1234 273 C: sh8013 274 C: sh8013 275 C: 276 C: 2fooBAR 277 C: 278 C: 279 C: 280 C: 281 C: 283 C: 284 C: 285 C: 2004-04-03T22:00:00.0Z 286 C: 287 C: 288 C: 289 C: 290 C: ABC-12345 291 C: 292 C: 294 Example command that sets the registrar registration 295 expiration date to the expiration date of the domain object 296 (), if the domain is successfully created: 298 C: 299 C: 301 C: 302 C: 303 C: 305 C: example.com 306 C: 2 307 C: 308 C: ns1.example.net 309 C: ns2.example.net 310 C: 311 C: jd1234 312 C: sh8013 313 C: sh8013 314 C: 315 C: 2fooBAR 316 C: 317 C: 318 C: 319 C: 320 C: 322 C: 323 C: 324 C: 325 C: ABC-12345 326 C: 327 C: 329 3.2.2. EPP command 331 This extension does not add any elements to the EPP command 332 or response described in the EPP domain mapping [RFC5731]. 334 3.2.3. EPP command 336 This extension defines additional elements for the EPP 337 command. The general requirements for EPP transform commands 338 described above apply to the EPP command. 340 This extension does not add any elements to the EPP response 341 described in the EPP domain mapping [RFC5731]. 343 Example command: 345 C: 346 C: 348 C: 349 C: 350 C: 352 C: example.com 353 C: 2000-04-03 354 C: 5 355 C: 356 C: 357 C: 358 C: 360 C: 361 C: 362 C: 2005-04-03T22:00:00.0Z 363 C: 364 C: 365 C: 366 C: 367 C: ABC-12345 368 C: 369 C: 371 3.2.4. EPP command 373 This extension does not add any elements to the EPP 374 command or response described in the EPP domain mapping 375 [RFC5731]. 377 3.2.5. EPP command 379 This extension defines additional elements for the EPP 380 command. The general requirements for EPP transform commands 381 described above apply to the EPP command. 383 This extension does not add any elements to the EPP response 384 described in the EPP domain mapping [RFC5731]. 386 Example command: 388 C: 389 C: 391 C: 392 C: 393 C: 395 C: example.com 396 C: 397 C: 398 C: 399 C: 401 C: 402 C: 403 C: 2006-04-03T22:00:00.0Z 404 C: 405 C: 406 C: 407 C: 408 C: ABC-12345 409 C: 410 C: 412 4. Formal Syntax 414 An EPP object mapping is specified in XML Schema notation. The 415 formal syntax presented here is a complete schema representation of 416 the object mapping suitable for automated validation of EPP XML 417 instances. 419 4.1. rrExDate Schema 421 Copyright (c) 2016 IETF Trust and the persons identified as authors 422 of the code. All rights reserved. 424 Redistribution and use in source and binary forms, with or without 425 modification, is permitted pursuant to, and subject to the license 426 terms contained in, the Simplified BSD License set forth in 427 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 428 Documents (http://trustee.ietf.org/license-info). 430 BEGIN 431 432 436 437 438 Extensible Provisioning Protocol v1.0 domain name extension 439 schema for implementing the ICANN thick whois policy. 440 441 442 444 445 446 447 448 449 451 452 453 454 455 456 457 458 END 460 5. Acknowledgements 462 The author would like to acknowledge the following individuals for 463 their contributions to this document: Patrick Mevzek and Klaus 464 Malorny. 466 6. IANA Considerations 468 This document uses URNs to describe XML namespaces and XML schemas 469 conforming to a registry mechanism described in [RFC3688]. Two URI 470 assignments have been registered by the IANA. 472 Registration request for the rrExDate namespace: 474 URI: urn:ietf:params:xml:ns:rrExDate-1.0" 476 Registrant Contact: IESG 477 XML: None. Namespace URIs do not represent an XML specification. 479 Registration request for the rrExDate schema: 481 URI: urn:ietf:params:xml:schema:rrExDate-1.0" 483 Registrant Contact: IESG 485 XML: See the "Formal Syntax" section of this document. 487 7. Internationalization Considerations 489 The internationalization considerations of EPP described in [RFC5730] 490 apply to this specification as well. 492 8. Security Considerations 494 The mapping extensions described in this document do not provide any 495 security services beyond those described by EPP [RFC5730], the EPP 496 domain name mapping [RFC5731], and protocol layers used by EPP. The 497 security considerations described in these other specifications apply 498 to this specification as well. 500 9. References 502 9.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 510 DOI 10.17487/RFC3688, January 2004, 511 . 513 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 514 Provisioning Protocol (EPP)", RFC 3735, 515 DOI 10.17487/RFC3735, March 2004, 516 . 518 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 519 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 520 . 522 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 523 Domain Name Mapping", STD 69, RFC 5731, 524 DOI 10.17487/RFC5731, August 2009, 525 . 527 [W3C.REC-xml] 528 W3C, "Extensible Markup Language (XML) 1.0 (Second 529 Edition)", Oct 2000, . 531 [W3C.REC-xmlschema-1] 532 W3C, "XML Schema Part 1: Structures Second Edition", Oct 533 2004, . 535 [W3C.REC-xmlschema-2] 536 W3C, "XML Schema Part 2: Structures Second Edition", Oct 537 2004, . 539 9.2. Informative References 541 [ThickWhoisPolicy] 542 ICANN, "GNSO Council Policy Recommendations for a new 543 Consensus Policy on Thick Whois", Oct 2013, 544 . 547 Author's Address 549 Gustavo Lozano 550 ICANN 551 12025 Waterfront Drive, Suite 300 552 Los Angeles 90292 553 US 555 Phone: +1.3103015800 556 Email: gustavo.lozano@icann.org