idnits 2.17.1 draft-hollenbeck-epp-rgp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 15, 2003) is 7645 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) == Unused Reference: '8' is defined on line 623, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Obsolete informational reference (is this intentional?): RFC 2279 (ref. '9') (Obsoleted by RFC 3629) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 Expires: November 13, 2003 May 15, 2003 6 Redemption Grace Period Mapping for the Extensible Provisioning 7 Protocol 8 draft-hollenbeck-epp-rgp-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 13, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes an Extensible Provisioning Protocol (EPP) 39 extension mapping for the management of Domain Name System (DNS) 40 domain names subject to the Redemption Grace Period (RGP) policies 41 defined by the Internet Corporation for Assigned Names and Numbers 42 (ICANN). Specified in XML, this mapping extends the EPP domain name 43 mapping to provide additional features required for RGP processing. 45 Conventions Used In This Document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [1]. 51 In examples, "C:" represents lines sent by a protocol client and "S:" 52 represents lines returned by a protocol server. Indentation and 53 white space in examples is provided only to illustrate element 54 relationships and is not a REQUIRED feature of this specification. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Changes from Previous Version . . . . . . . . . . . . . . . 3 60 2. Redemption Grace Period State Diagram . . . . . . . . . . . 4 61 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . 6 62 3.1 Status Values . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . 7 64 4.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.1 EPP Command . . . . . . . . . . . . . . . . . . . . 7 66 4.1.2 EPP Command . . . . . . . . . . . . . . . . . . . . . 7 67 4.1.3 EPP Command . . . . . . . . . . . . . . . . . . . 9 68 4.2 EPP Transform Commands . . . . . . . . . . . . . . . . . . . 9 69 4.2.1 EPP Command . . . . . . . . . . . . . . . . . . . . 9 70 4.2.2 EPP Command . . . . . . . . . . . . . . . . . . . . 9 71 4.2.3 EPP Command . . . . . . . . . . . . . . . . . . . . 9 72 4.2.4 EPP Command . . . . . . . . . . . . . . . . . . . 11 73 4.2.5 EPP Command . . . . . . . . . . . . . . . . . . . . 11 74 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. Internationalization Considerations . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . 16 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 Normative References . . . . . . . . . . . . . . . . . . . . 18 80 Informative References . . . . . . . . . . . . . . . . . . . 19 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 82 Intellectual Property and Copyright Statements . . . . . . . 21 84 1. Introduction 86 This document describes an extension mapping for version 1.0 of the 87 Extensible Provisioning Protocol (EPP). This mapping, an extension 88 of the domain name mapping described in [2], is specified using the 89 Extensible Markup Language (XML) 1.0 as described in [3] and XML 90 Schema notation as described in [4] and [5]. 92 The EPP core protocol specification [6] provides a complete 93 description of EPP command and response structures. A thorough 94 understanding of the base protocol specification is necessary to 95 understand the mapping described in this document. 97 Over the course of several months in 2002, the Internet Corporation 98 for Assigned Names and Numbers (ICANN) developed an implementation 99 proposal [11] to provide a "grace period" for Domain Name System 100 (DNS) domain name recovery (or redemption) before a domain name is 101 purged from the repository of the authoritative registry for the 102 domain name. This mapping extends the EPP domain command to 103 initiate the redemption process for a domain name that has entered 104 the Redemption Grace Period (RGP) and it extends the EPP domain 105 response to identify the status of domains that have entered 106 the RGP. 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 to develop a conforming implementation. 112 1.1 Changes from Previous Version 114 (Note to RFC editor: please remove this section completely before 115 publication as an RFC.) 117 None, this is the initial version. 119 2. Redemption Grace Period State Diagram 121 The Redemption Grace Period (RGP) involves several domain state 122 transitions as a domain name moves through the redemption process: 124 1. A domain is initially in the EPP "ok" status, or some other 125 status that allows processing of the EPP command. 127 2. A command is received and processed for the domain 128 name. 130 3. RGP begins once the command is processed successfully. 131 The EPP status changes to "pendingDelete", and the RGP status is 132 initialized to "redemptionPeriod". The domain remains in this 133 state until either a operation is requested or the 134 redemption period elapses. 136 4. A operation can be requested using the extended EPP 137 command. Go to step 8 if the redemption period elapses 138 before a request is received. 140 5. If the is successful, the Registry waits to receive a 141 restore report from the registrar for a period of time defined 142 by the Registry. The EPP status remains "pendingDelete" (TBD: 143 should it instead change back to "ok"?) and the RGP status 144 changes to "pendingRestore". (TBD: should the report be 145 submitted through the protocol (as part of the ) or an 146 out-of-band facility such as a web site?) 148 6. The domain name returns to the redemption period state (state 3) 149 if a restore report is not received. 151 7. If a restore report is received the EPP status returns to "ok" 152 (or whatever it was prior to processing the command), 153 and the RGP status is removed completely. 155 8. The redemption period elapses before a request is 156 received. 158 9. The EPP status remains "pendingDelete" and the RGP status 159 changes to "pendingDelete". The domain name remains in this 160 state for a period of time defined by the Registry. 162 10. The domain name is purged once the pending delete period 163 elapses. 165 11. The domain name is available for re-registration. 167 | 168 | 169 v 170 +----------------------+ (2) +----------------------+ 171 |EPP: ok (1)| |EPP: pendingDelete (3)| 172 |RGP: N/A |--------->|RGP: redemptionPeriod | 173 +----------------------+ +----------------------+ 174 ^ (4) | ^ | 175 | | | No (8) | 176 | +-----------+ | | 177 | | | | 178 | v | v 179 | +----------------------+ | +----------------------+ 180 | |EPP: pendingDelete (5)| | |EPP: pendingDelete (9)| 181 | |RGP: pendingRestore |---------+ |RGP: pendingDelete | 182 | +----------------------+ Report +----------------------+ 183 | | not (6) | 184 | (7) | Received Purge (10) | 185 | Report Received | | 186 +--------------------+ v 187 +----------------------+ 188 | Purged (11)| 189 | | 190 +----------------------+ 192 Figure 1: RGP State Diagram 194 3. Object Attributes 196 This extension adds additional elements to the domain name mapping 197 described in the EPP domain mapping [2]. Only new element 198 descriptions are described here. 200 3.1 Status Values 202 This extension defines three new status values to represent the 203 different states that a domain can be in as a result of redemption 204 grace period processing. These are: 206 redemptionPeriod: This status value is used to describe a domain 207 for which a command has been received, but the domain has 208 not yet been purged because an opportunity exists to restore the 209 domain and abort the deletion process. The amount of time that a 210 domain can stay in this status before being entering purge 211 processing is a matter of registry policy. 213 pendingRestore: This status value is used to describe a domain 214 that is in the process of being restored after being in the 215 redemptionPeriod state. The amount of time that a domain can stay 216 in this status before being returned to the redemptionPeriod state 217 is a matter of registry policy. 219 pendingDelete: This status value is used to describe a domain that 220 has entered the purge processing state after completing the 221 redemptionPeriod state. The amount of time that a domain can stay 222 in this status before being being purged is a matter of registry 223 policy. A domain in this status MUST also be in the pendingDelete 224 status described in the EPP domain mapping [2]. 226 4. EPP Command Mapping 228 A detailed description of the EPP syntax and semantics can be found 229 in the EPP core protocol specification [6]. The command mappings 230 described here are specifically for use in implementing redemption 231 grace period processes via EPP. 233 4.1 EPP Query Commands 235 EPP provides three commands to retrieve object information: 236 to determine if an object is known to the server, to retrieve 237 detailed information associated with an object, and to 238 retrieve object transfer status information. 240 4.1.1 EPP Command 242 This extension does not add any elements to the EPP command 243 or response described in the EPP domain mapping [2]. 245 4.1.2 EPP Command 247 This extension does not add any elements to the EPP command 248 described in the EPP domain mapping [2]. Additional elements are 249 defined for the response. 251 When an command has been processed successfully, the EPP 252 element MUST contain child elements as described in [2]. 253 In addition, the EPP element MUST contain a child 254 element that identifies the RGP namespace and the 255 location of the RGP schema. The element contains a 256 single element that contains a single attribute "s" 257 whose value describes the current RGP status of the domain. Possible 258 status values are described in section Section 3.1. 260 Example response for "redemptionPeriod" status: 262 S: 263 S: 267 S: 268 S: 269 S: Command completed successfully 270 S: 271 S: 272 S: 276 S: example.com 277 S: EXAMPLE1-REP 278 S: 279 S: jd1234 280 S: sh8013 281 S: sh8013 282 S: 283 S: ns1.example.com 284 S: ns1.example.net 285 S: 286 S: ns1.example.com 287 S: ns2.example.com 288 S: ClientX 289 S: ClientY 290 S: 1999-04-03T22:00:00.0Z 291 S: ClientX 292 S: 1999-12-03T09:00:00.0Z 293 S: 2005-04-03T22:00:00.0Z 294 S: 2000-04-08T09:00:00.0Z 295 S: 296 S: 2fooBAR 297 S: 298 S: 299 S: 300 S: 301 S: 304 S: 305 S: 306 S: 307 S: 308 S: ABC-12345 309 S: 54322-XYZ 310 S: 311 S: 312 S: 314 Example response extension for "pendingRestore" status (note 315 that only the extension element changes from the first example): 317 S: 318 S: 321 S: 322 S: 323 S: 325 Example response extension for "pendingDelete" status (note 326 that only the extension element changes from the first example): 328 S: 329 S: 332 S: 333 S: 334 S: 336 4.1.3 EPP Command 338 This extension does not add any elements to the EPP 339 command or response described in the EPP domain mapping 340 [2]. 342 4.2 EPP Transform Commands 344 EPP provides five commands to transform objects: to create 345 an instance of an object, to delete an instance of an 346 object, to extend the validity period of an object, 347 to manage object sponsorship changes, and to 348 change information associated with an object. 350 4.2.1 EPP Command 352 This extension does not add any elements to the EPP command 353 or response described in the EPP domain mapping [2]. 355 4.2.2 EPP Command 357 This extension does not add any elements to the EPP command 358 or response described in the EPP domain mapping [2]. 360 4.2.3 EPP Command 362 This extension defines additional elements for the EPP 363 command and response described in the EPP domain mapping [2]. 365 The EPP command provides a transform operation that allows a 366 client to extend the registration period a domain object. In 367 addition to the EPP command elements described in the EPP domain 368 mapping [2], the command MUST contain an element. The 369 element MUST contain a child element that 370 identifies the RGP namespace and the location of the RGP schema. The 371 element contains a single element that 372 contains no child elements of its own. 374 Example command: 376 C: 377 C: 381 C: 382 C: 383 C: 387 C: example.com 388 C: 2003-05-18 389 C: 1 390 C: 391 C: 392 C: 393 C: 396 C: 397 C: 398 C: 399 C: ABC-12345 400 C: 401 C: 403 When an extended command has been processed successfully, the 404 EPP response is as described in the EPP domain mapping [2] except 405 that an extension element is added to describe RGP status as a result 406 of processing the command. The extension element contains a 407 single child element () that itself contains a single child 408 element () that contains a single attribute "s" whose 409 value MUST be "pendingRestore" if the request has been 410 accepted. 412 Example response: 414 S: 415 S: 419 S: 420 S: 421 S: Command completed successfully 422 S: 423 S: 424 S: 428 S: example.com 429 S: 2004-05-18T22:00:00.0Z 430 S: 431 S: 432 S: 433 S: 436 S: 437 S: 438 S: 439 S: 440 S: ABC-12345 441 S: 54322-XYZ 442 S: 443 S: 444 S: 446 4.2.4 EPP Command 448 This extension does not add any elements to the EPP 449 command or response described in the EPP domain mapping 450 [2]. 452 4.2.5 EPP Command 454 This extension does not add any elements to the EPP command 455 or response described in the EPP domain mapping [2]. 457 5. Formal Syntax 459 An EPP object mapping is specified in XML Schema notation. The 460 formal syntax presented here is a complete schema representation of 461 the object mapping suitable for automated validation of EPP XML 462 instances. The BEGIN and END tags are not part of the schema; they 463 are used to note the beginning and ending of the schema for URI 464 registration purposes. 466 BEGIN 467 469 474 475 476 Extensible Provisioning Protocol v1.0 477 domain name extension schema for redemption grace period (RGP) 478 processing. 479 480 482 485 487 490 491 492 493 494 496 499 500 502 505 506 507 508 509 511 515 516 517 518 520 522 523 524 526 527 528 529 530 531 532 534 537 538 END 540 6. Internationalization Considerations 542 EPP is represented in XML, which provides native support for encoding 543 information using the Unicode character set and its more compact 544 representations including UTF-8 [9]. Conformant XML processors 545 recognize both UTF-8 and UTF-16 [10]. Though XML includes provisions 546 to identify and use other character encodings through use of an 547 "encoding" attribute in an declaration, use of UTF-8 is 548 RECOMMENDED in environments where parser encoding support 549 incompatibility exists. 551 As an extension of the EPP domain mapping [2], the elements, element 552 content, attributes, and attribute values described in this document 553 MUST inherit the internationalization conventions used to represent 554 higher-layer domain and core protocol structures present in an XML 555 instance that includes this extension. 557 7. IANA Considerations 559 This document uses URNs to describe XML namespaces and XML schemas 560 conforming to a registry mechanism described in [7]. Two URI 561 assignments are requested. 563 Registration request for the RGP namespace: 565 URI: urn:ietf:params:xml:ns:RGP-1.0 567 Registrant Contact: See the "Author's Address" section of this 568 document. 570 XML: None. Namespace URIs do not represent an XML specification. 572 Registration request for the RGP XML schema: 574 URI: urn:ietf:params:xml:schema:RGP-1.0 576 Registrant Contact: See the "Author's Address" section of this 577 document. 579 XML: See the "Formal Syntax" section of this document. 581 8. Security Considerations 583 The mapping extensions described in this document do not provide any 584 security services beyond those described by EPP [6], the EPP domain 585 name mapping [2], and protocol layers used by EPP. The security 586 considerations described in these other specifications apply to this 587 specification as well. 589 9. Acknowledgements 591 The author would like to thank the following people who have provided 592 significant contributions to the development of this document: 594 TBD. 596 Normative References 598 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 599 Levels", BCP 14, RFC 2119, March 1997. 601 [2] Hollenbeck, S., "Extensible Provisioning Protocol Domain Name 602 Mapping", draft-ietf-provreg-epp-domain-07 (work in progress), 603 April 2003. 605 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 606 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 607 October 2000, . 609 [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 610 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 611 . 613 [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C 614 REC-xmlschema-2, May 2001, . 616 [6] Hollenbeck, S., "Extensible Provisioning Protocol", 617 draft-ietf-provreg-epp-09 (work in progress), March 2003. 619 [7] Mealling, M., "The IETF XML Registry", 620 draft-mealling-iana-xmlns-registry-04 (work in progress), July 621 2002. 623 [8] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 624 REC-xml-names, January 1999, . 627 Informative References 629 [9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 630 2279, January 1998. 632 [10] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 633 RFC 2781, February 2000. 635 URIs 637 [11] 639 Author's Address 641 Scott Hollenbeck 642 VeriSign, Inc. 643 21345 Ridgetop Circle 644 Dulles, VA 20166-6503 645 US 647 EMail: shollenbeck@verisign.com 649 Intellectual Property Statement 651 The IETF takes no position regarding the validity or scope of any 652 intellectual property or other rights that might be claimed to 653 pertain to the implementation or use of the technology described in 654 this document or the extent to which any license under such rights 655 might or might not be available; neither does it represent that it 656 has made any effort to identify any such rights. Information on the 657 IETF's procedures with respect to rights in standards-track and 658 standards-related documentation can be found in BCP-11. Copies of 659 claims of rights made available for publication and any assurances of 660 licenses to be made available, or the result of an attempt made to 661 obtain a general license or permission for the use of such 662 proprietary rights by implementors or users of this specification can 663 be obtained from the IETF Secretariat. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights which may cover technology that may be required to practice 668 this standard. Please address the information to the IETF Executive 669 Director. 671 Full Copyright Statement 673 Copyright (C) The Internet Society (2003). All Rights Reserved. 675 This document and translations of it may be copied and furnished to 676 others, and derivative works that comment on or otherwise explain it 677 or assist in its implementation may be prepared, copied, published 678 and distributed, in whole or in part, without restriction of any 679 kind, provided that the above copyright notice and this paragraph are 680 included on all such copies and derivative works. However, this 681 document itself may not be modified in any way, such as by removing 682 the copyright notice or references to the Internet Society or other 683 Internet organizations, except as needed for the purpose of 684 developing Internet standards in which case the procedures for 685 copyrights defined in the Internet Standards process must be 686 followed, or as required to translate it into languages other than 687 English. 689 The limited permissions granted above are perpetual and will not be 690 revoked by the Internet Society or its successors or assignees. 692 This document and the information contained herein is provided on an 693 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 694 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 695 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 696 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 697 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Acknowledgement 701 Funding for the RFC Editor function is currently provided by the 702 Internet Society.