idnits 2.17.1 draft-hollenbeck-epp-rgp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 982. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 998), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (April 5, 2004) is 7323 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: '9' is defined on line 935, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3730 (ref. '1') (Obsoleted by RFC 4930) ** Obsolete normative reference: RFC 3731 (ref. '2') (Obsoleted by RFC 4931) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 954 (ref. '10') (Obsoleted by RFC 3912) -- Obsolete informational reference (is this intentional?): RFC 2279 (ref. '11') (Obsoleted by RFC 3629) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 12 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: October 4, 2004 April 5, 2004 6 Domain Registry Grace Period Mapping 7 for the Extensible Provisioning Protocol 8 draft-hollenbeck-epp-rgp-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 4, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes an Extensible Provisioning Protocol (EPP) 41 extension mapping for the management of Domain Name System (DNS) 42 domain names subject to "grace period" policies defined by the 43 Internet Corporation for Assigned Names and Numbers (ICANN). Grace 44 period policies exist to allow protocol actions to be reversed or 45 otherwise revoked during a short period of time after the protocol 46 action has been performed. Specified in XML, this mapping extends 47 the EPP domain name mapping to provide additional features required 48 for grace period processing. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Conventions Used In This Document . . . . . . . . . . . . 4 54 2. Redemption Grace Period State Diagram . . . . . . . . . . . . 4 55 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1 Status Values . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2 Whois Data and Supporting Information . . . . . . . . . . 7 58 3.3 Dates and Times . . . . . . . . . . . . . . . . . . . . . 7 59 3.4 Client Statements . . . . . . . . . . . . . . . . . . . . 7 60 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 61 4.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . . 7 62 4.1.1 EPP Command . . . . . . . . . . . . . . . . . 7 63 4.1.2 EPP Command . . . . . . . . . . . . . . . . . . 8 64 4.1.3 EPP Command . . . . . . . . . . . . . . . . 11 65 4.2 EPP Transform Commands . . . . . . . . . . . . . . . . . . 11 66 4.2.1 EPP Command . . . . . . . . . . . . . . . . . 11 67 4.2.2 EPP Command . . . . . . . . . . . . . . . . . 11 68 4.2.3 EPP Command . . . . . . . . . . . . . . . . . 11 69 4.2.4 EPP Command . . . . . . . . . . . . . . . . 11 70 4.2.5 EPP Command . . . . . . . . . . . . . . . . . 11 71 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6. Internationalization Considerations . . . . . . . . . . . . . 18 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 78 10.2 Informative References . . . . . . . . . . . . . . . . . . . 20 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 80 Intellectual Property and Copyright Statements . . . . . . . . 22 82 1. Introduction 84 This document describes an extension mapping for version 1.0 of the 85 Extensible Provisioning Protocol (EPP) described in RFC 3730 [1]. 86 This mapping, an extension of the domain name mapping described in 87 RFC 3731 [2], is specified using the Extensible Markup Language (XML) 88 1.0 [3] and XML Schema notation ([4], [5]). 90 The EPP core protocol specification [1] provides a complete 91 description of EPP command and response structures. A thorough 92 understanding of the base protocol specification is necessary to 93 understand the mapping described in this document. 95 Over the course of several months in 2002, The Internet Corporation 96 for Assigned Names and Numbers (ICANN) developed an implementation 97 proposal to provide a "grace period" for Domain Name System (DNS) 98 domain name recovery (or redemption) before a domain name is purged 99 from the repository of the authoritative registry for the domain 100 name. This mapping extends the EPP domain command to 101 initiate the redemption process for a domain name that has entered 102 the Redemption Grace Period (RGP) and it extends the EPP domain 103 response to identify the status of domains that have entered 104 various grace periods defined by ICANN policy. 106 In March 2003, ICANN published a task force report describing other 107 domain registry grace periods related to EPP operations. This 108 mapping describes extension status values to note the grace periods 109 described in the report, including: 111 o An "add grace period" after the initial registration of a domain 112 name. If the domain name is deleted by the registrar during this 113 period, the registry provides a credit to the registrar for the 114 cost of the registration. 116 o An "auto-renew grace period" after a domain name registration 117 period expires and is extended (renewed) automatically by the 118 registry. If the domain name is deleted by the registrar during 119 this period, the registry provides a credit to the registrar for 120 the cost of the renewal. 122 o A "renew grace period" after a domain name registration period is 123 explicitly extended (renewed) by the registrar. If the domain 124 name is deleted by the registrar during this period, the registry 125 provides a credit to the registrar for the cost of the renewal. 127 o A "transfer grace period" after the successful transfer of domain 128 name registration sponsorship from one registrar to another 129 registrar. If the domain name is deleted by the new sponsoring 130 registrar during this period, the registry provides a credit to 131 the registrar for the cost of the transfer. 133 Each grace period exists for a specific period of time that is 134 typically measured in days. The duration of each grace period is a 135 matter of registry operational policy that is not addressed in the 136 document. 138 1.1 Conventions Used In This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [6]. 144 In examples, "C:" represents lines sent by a protocol client and "S:" 145 represents lines returned by a protocol server. Indentation and 146 white space in examples is provided only to illustrate element 147 relationships and is not a REQUIRED feature of this specification. 149 XML is case sensitive. Unless stated otherwise, XML specifications 150 and examples provided in this document MUST be interpreted in the 151 character case presented to develop a conforming implementation. 153 2. Redemption Grace Period State Diagram 155 The Redemption Grace Period (RGP) involves several domain state 156 transitions as a domain name moves through the redemption process: 158 1. A domain is initially in the EPP "ok" status, or some other 159 status that allows processing of the EPP command. 161 2. A command is received and processed for the domain 162 name. 164 3. RGP begins once the command is processed successfully. 165 The EPP status changes to "pendingDelete", and the RGP status is 166 initialized to "redemptionPeriod". The domain remains in this 167 state until either a operation is requested or the 168 redemption period elapses. 170 4. A operation can be requested using the extended EPP 171 command. Go to step 8 if the redemption period elapses 172 before a request is received. 174 5. If the is successful, the Registry waits to receive a 175 restore report from the registrar for a period of time defined 176 by the Registry. The EPP status remains "pendingDelete" and the 177 RGP status changes to "pendingRestore". While this extension 178 defines a method to deliver a restore report via EPP, an 179 out-of-band mechanism (such as a web site) can also be used to 180 deliver restore reports. 182 6. The domain name returns to the redemption period state (state 3) 183 if a restore report is not received. 185 7. If a restore report is received the EPP status returns to "ok" 186 (or whatever it was prior to processing the command), 187 and the RGP status is removed completely. 189 8. The redemption period elapses before a request is 190 received. 192 9. The EPP status remains "pendingDelete" and the RGP status 193 changes to "pendingDelete". The domain name remains in this 194 state for a period of time defined by the Registry. 196 10. The domain name is purged once the pending delete period 197 elapses. 199 11. The domain name is available for re-registration. 201 Figure 1: RGP State Diagram 203 | 204 v 205 +----------------------+ (2) +----------------------+ 206 |EPP: ok (1)| |EPP: pendingDelete (3)| 207 |RGP: N/A |--------->|RGP: redemptionPeriod | 208 +----------------------+ +----------------------+ 209 ^ (4) | ^ | 210 | | | No (8) | 211 | +-----------+ | | 212 | | | | 213 | v | v 214 | +----------------------+ | +----------------------+ 215 | |EPP: pendingDelete (5)| | |EPP: pendingDelete (9)| 216 | |RGP: pendingRestore |---------+ |RGP: pendingDelete | 217 | +----------------------+ Report +----------------------+ 218 | | not (6) | 219 | (7) | Received Purge (10) | 220 | Report Received | | 221 +--------------------+ v 222 +----------------------+ 223 | Purged (11)| 224 | | 225 +----------------------+ 227 3. Object Attributes 229 This extension adds additional elements to the EPP domain name 230 mapping [2]. Only new element descriptions are described here. 232 3.1 Status Values 234 This extension defines new status values to represent the different 235 states that a domain name can be in as a result of grace period 236 processing. These are: 238 addPeriod: This grace period is provided after the initial 239 registration of a domain name. If the domain name is deleted by 240 the registrar during this period, the registry provides a credit 241 to the registrar for the cost of the registration. 243 autoRenewPeriod: This grace period is provided after a domain name 244 registration period expires and is extended (renewed) 245 automatically by the registry. If the domain name is deleted by 246 the registrar during this period, the registry provides a credit 247 to the registrar for the cost of the renewal. 249 renewPeriod: This grace period is provided after a domain name 250 registration period is explicitly extended (renewed) by the 251 registrar. If the domain name is deleted by the registrar during 252 this period, the registry provides a credit to the registrar for 253 the cost of the renewal. 255 transferPeriod: This grace period is provided after the successful 256 transfer of domain name registration sponsorship from one 257 registrar to another registrar. If the domain name is deleted by 258 the new sponsoring registrar during this period, the registry 259 provides a credit to the registrar for the cost of the transfer. 261 redemptionPeriod: This status value is used to describe a domain 262 for which a command has been received, but the domain has 263 not yet been purged because an opportunity exists to restore the 264 domain and abort the deletion process. 266 pendingRestore: This status value is used to describe a domain 267 that is in the process of being restored after being in the 268 redemptionPeriod state. 270 pendingDelete: This status value is used to describe a domain that 271 has entered the purge processing state after completing the 272 redemptionPeriod state. A domain in this status MUST also be in 273 the pendingDelete status described in the EPP domain mapping [2]. 275 3.2 Whois Data and Supporting Information 277 This extension allows a client to provide copies of whois [10] data 278 and supporting information in a restore report as required by the RGP 279 process. No specific format is required by this extension; both free 280 text and XML markup MAY be used. 282 Operators of whois servers might find it useful to provide grace 283 period status values in their responses to whois queries. This 284 information can be useful to people who want to understand the 285 operations that can be performed on a domain name at any give time. 287 3.3 Dates and Times 289 Date and time attribute values MUST be represented in Universal 290 Coordinated Time (UTC) using the Gregorian calendar. The extended 291 date-time form using upper case "T" and "Z" characters defined in RFC 292 3339 [7] MUST be used to represent date-time values as XML Schema 293 does not support truncated date-time forms or lower case "T" and "Z" 294 characters. 296 3.4 Client Statements 298 The RGP process requires a client to make two statements regarding 299 the data included in a restore report. No specific format is 300 required by this extension; both free text and XML markup MAY be 301 used. English is the default language used within the statements, 302 but other languages MAY be used. 304 4. EPP Command Mapping 306 A detailed description of the EPP syntax and semantics can be found 307 in the EPP core protocol specification [1]. The command mappings 308 described here are specifically for use in implementing redemption 309 grace period processes via EPP. 311 4.1 EPP Query Commands 313 EPP provides three commands to retrieve object information: 314 to determine if an object is known to the server, to retrieve 315 detailed information associated with an object, and to 316 retrieve object transfer status information. 318 4.1.1 EPP Command 320 This extension does not add any elements to the EPP command 321 or response described in the EPP domain mapping [2]. 323 4.1.2 EPP Command 325 This extension does not add any elements to the EPP command 326 described in the EPP domain mapping [2]. Additional elements are 327 defined for the response. 329 When an command has been processed successfully, the EPP 330 element MUST contain child elements as described in [2]. 331 In addition, the EPP element MUST contain a child 332 element that identifies the registry grace period 333 namespace and the location of the registry grace period schema. The 334 element contains a single element that 335 contains a single attribute "s" whose value describes the current 336 grace period status of the domain. Possible status values are 337 described in section Section 3.1. 339 Example response for "addPeriod" status: 341 S: 342 S: 346 S: 347 S: 348 S: Command completed successfully 349 S: 350 S: 351 S: 355 S: example.com 356 S: EXAMPLE1-REP 357 S: 358 S: jd1234 359 S: sh8013 360 S: sh8013 361 S: 362 S: ns1.example.com 363 S: ns1.example.net 364 S: 365 S: ns1.example.com 366 S: ns2.example.com 367 S: ClientX 368 S: ClientX 369 S: 2003-11-26T22:00:00.0Z 370 S: 2005-11-26T22:00:00.0Z 371 S: 372 S: 2fooBAR 373 S: 374 S: 375 S: 376 S: 377 S: 380 S: 381 S: 382 S: 383 S: 384 S: ABC-12345 385 S: 54322-XYZ 386 S: 387 S: 388 S: 390 Example response for "redemptionPeriod" status: 392 S: 393 S: 397 S: 398 S: 399 S: Command completed successfully 400 S: 401 S: 402 S: 406 S: example.com 407 S: EXAMPLE1-REP 408 S: 409 S: jd1234 410 S: sh8013 411 S: sh8013 412 S: 413 S: ns1.example.com 414 S: ns1.example.net 415 S: 416 S: ns1.example.com 417 S: ns2.example.com 418 S: ClientX 419 S: ClientY 420 S: 1999-04-03T22:00:00.0Z 421 S: ClientX 422 S: 1999-12-03T09:00:00.0Z 423 S: 2005-04-03T22:00:00.0Z 424 S: 2000-04-08T09:00:00.0Z 425 S: 426 S: 2fooBAR 427 S: 428 S: 429 S: 430 S: 431 S: 434 S: 435 S: 436 S: 437 S: 438 S: ABC-12345 439 S: 54322-XYZ 440 S: 441 S: 442 S: 444 Example response extension for "pendingRestore" status (note 445 that only the extension element changes from the first example): 447 S: 448 S: 451 S: 452 S: 453 S: 455 Example response extension for "pendingDelete" status (note 456 that only the extension element changes from the first example): 458 S: 459 S: 462 S: 463 S: 464 S: 466 4.1.3 EPP Command 468 This extension does not add any elements to the EPP 469 command or response described in the EPP domain mapping 470 [2]. 472 4.2 EPP Transform Commands 474 EPP provides five commands to transform objects: to create 475 an instance of an object, to delete an instance of an 476 object, to extend the validity period of an object, 477 to manage object sponsorship changes, and to 478 change information associated with an object. 480 4.2.1 EPP Command 482 This extension does not add any elements to the EPP command 483 or response described in the EPP domain mapping [2]. 485 4.2.2 EPP Command 487 This extension does not add any elements to the EPP command 488 or response described in the EPP domain mapping [2]. 490 4.2.3 EPP Command 492 This extension does not add any elements to the EPP command 493 or response described in the EPP domain mapping [2]. 495 4.2.4 EPP Command 497 This extension does not add any elements to the EPP 498 command or response described in the EPP domain mapping 499 [2]. 501 4.2.5 EPP Command 503 This extension defines additional elements to extend the EPP 504 command and response described in the EPP domain mapping [2] for 505 redemption grace period processing. 507 The EPP command provides a transform operation that allows a 508 client to change the state of a domain object. The registry grace 509 period extension modifies base update processing to support 510 redemption of domain names for which a command has been 511 processed, but the name has not yet been purged. 513 Section 3.2.5 of the EPP domain mapping describes the elements that 514 have to be specified within an command. The requirement to 515 provide at least one , , or 516 element is updated by this extension such that at least one empty 517 , , or element MUST be present 518 if this extension is specified within an command. This 519 requirement is updated to disallow the possibility of modifying a 520 domain object as part of redemption grace period recovery processing. 522 In addition to the EPP command elements described in the EPP domain 523 mapping [2], the command MUST contain an 524 element. The element MUST contain a child 525 element that identifies the registry grace period namespace and the 526 location of the registry grace period schema. The 527 element contains a single element that contains an 528 OPTIONAL element that MAY be used to deliver a 529 redemption grace period restore report. 531 The element contains a REQUIRED "op" attribute that 532 describes the redemption grace period operation being requested. Two 533 values are defined: "request" is used to identify a restore request 534 that does not include a restore report, and "report" is used to 535 identify a restore request that contains a restore report. A report 536 MAY be submitted more than once if corrections are required. If the 537 value of the "op" attribute is "request" an element MUST 538 NOT be present. If the value of the "op" attribute is "report" an 539 element MUST be present. 541 The element contains the following child elements: 543 - An element that contains a copy of the whois [10] 544 data that existed for the domain name prior to the domain name 545 being deleted. This element MAY contain both text and XML markup. 547 - An element that contains a copy of the whois [10] 548 data that exists for the domain name at the time the restore 549 report is submitted. This element MAY contain both text and XML 550 markup. 552 - An element that contains the date and time when the 553 domain name delete request was sent to the server. 555 - An element that contains the date and time when the 556 original command was sent to the server. 558 - An element that contains a brief explanation of 559 the reason for restoring the domain name. 561 - An element that contains a text statement that the 562 client has not restored the domain name in order to assume the 563 rights to use or sell the domain name for itself or for any third 564 party. Supporting information related to this statement MAY be 565 supplied in the element described below. An OPTIONAL 566 "lang" attribute MAY be present to identify the language if 567 English (value "en") is not used to represent the statement. 569 - A second element that contains a text statement 570 that the information in the restore report is factual to the best 571 of the client's knowledge. An OPTIONAL "lang" attribute MAY be 572 present to identify the language if English (value "en") is not 573 used to represent the statement. 575 - An OPTIONAL element that contains any information 576 needed to support the statements provided by the client. This 577 element MAY contain both text and XML markup. 579 More detailed information describing the information required to be 580 provided in a restore report is available from ICANN. 582 Example command without a restore report: 584 C: 585 C: 589 C: 590 C: 591 C: 595 C: example.com 596 C: 597 C: 598 C: 599 C: 600 C: 603 C: 604 C: 605 C: 606 C: ABC-12345 607 C: 608 C: 609 Example command with a restore report: 611 C: 612 C: 616 C: 617 C: 618 C: 622 C: example.com 623 C: 624 C: 625 C: 626 C: 627 C: 630 C: 631 C: 632 C: Pre-delete whois data goes here. 633 C: Both XML and free text are allowed. 634 C: Post-restore whois data goes here. 635 C: Both XML and free text are allowed. 636 C: 2003-07-10T22:00:00.0Z 637 C: 2003-07-20T22:00:00.0Z 638 C: Registrant error. 639 C: This registrar has not restored the 640 C: Registered Name in order to assume the rights to use 641 C: or sell the Registered Name for itself or for any 642 C: third party. 643 C: The information in this report is 644 C: true to best of this registrar's knowledge, and this 645 C: registrar acknowledges that intentionally supplying 646 C: false information in this report shall constitute an 647 C: incurable material breach of the 648 C: Registry-Registrar Agreement. 649 C: Supporting information goes 650 C: here. 651 C: 652 C: 653 C: 654 C: 655 C: ABC-12345 656 C: 657 C: 659 When an extended command without a restore report has been 660 processed successfully, the EPP response is as described in the EPP 661 domain mapping [2] except that an extension element is added to 662 describe grace period status as a result of processing the 663 command. The extension element contains a single child element 664 () that itself contains a single child element () 665 that contains a single attribute "s" whose value MUST be 666 "pendingRestore" if the request has been accepted. 668 Example "restore request" response: 670 S: 671 S: 675 S: 676 S: 677 S: Command completed successfully 678 S: 679 S: 680 S: 683 S: 684 S: 685 S: 686 S: 687 S: ABC-12345 688 S: 54321-XYZ 689 S: 690 S: 691 S: 693 When an extended command with a restore report has been 694 processed successfully, the EPP response is as described in the EPP 695 domain mapping [2] with no registry grace period extension. Registry 696 grace period extension is not required because acceptance of the 697 restore report completes redemption grace period processing. 699 5. Formal Syntax 701 An EPP object mapping is specified in XML Schema notation. The 702 formal syntax presented here is a complete schema representation of 703 the object mapping suitable for automated validation of EPP XML 704 instances. The BEGIN and END tags are not part of the schema; they 705 are used to note the beginning and ending of the schema for URI 706 registration purposes. 708 BEGIN 709 711 716 717 718 Extensible Provisioning Protocol v1.0 719 domain name extension schema for registry grace period 720 processing. 721 722 724 727 729 733 734 735 736 737 739 740 741 743 744 745 747 751 752 753 754 755 756 758 759 760 761 762 763 764 765 767 769 770 772 773 774 775 776 778 779 780 781 783 784 785 786 787 789 790 791 792 793 795 798 799 801 804 805 806 807 808 810 815 816 817 818 820 821 822 823 825 826 827 828 829 830 831 832 833 834 835 837 840 841 END 843 6. Internationalization Considerations 845 EPP is represented in XML, which provides native support for encoding 846 information using the Unicode character set and its more compact 847 representations including UTF-8 [11]. Conformant XML processors 848 recognize both UTF-8 and UTF-16 [12]. Though XML includes provisions 849 to identify and use other character encodings through use of an 850 "encoding" attribute in an declaration, use of UTF-8 is 851 RECOMMENDED in environments where parser encoding support 852 incompatibility exists. 854 As an extension of the EPP domain mapping [2], the elements, element 855 content, attributes, and attribute values described in this document 856 MUST inherit the internationalization conventions used to represent 857 higher-layer domain and core protocol structures present in an XML 858 instance that includes this extension. 860 7. IANA Considerations 862 This document uses URNs to describe XML namespaces and XML schemas 863 conforming to a registry mechanism described in RFC 3688 [8]. Two URI 864 assignments are requested. 866 Registration request for the registry grace period namespace: 868 URI: urn:ietf:params:xml:ns:rgp-1.0 870 Registrant Contact: See the "Author's Address" section of this 871 document. 873 XML: None. Namespace URIs do not represent an XML specification. 875 Registration request for the registry grace period XML schema: 877 URI: urn:ietf:params:xml:schema:rgp-1.0 879 Registrant Contact: See the "Author's Address" section of this 880 document. 882 XML: See the "Formal Syntax" section of this document. 884 8. Security Considerations 886 The mapping extensions described in this document do not provide any 887 security services beyond those described by EPP [1], the EPP domain 888 name mapping [2], and protocol layers used by EPP. The security 889 considerations described in these other specifications apply to this 890 specification as well. 892 As with other domain object updates, redemption of a deleted domain 893 object MUST be restricted to the sponsoring client. Any attempt to 894 recover a deleted domain object by any client other than the 895 sponsoring client MUST be rejected with an appropriate EPP 896 authorization error. 898 9. Acknowledgements 900 The author would like to thank the following people who have provided 901 significant contributions to the development of this document: 903 James Gould, Antony Perkov, and Janusz Sienkiewicz. 905 10. References 907 10.1 Normative References 909 [1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 910 3730, March 2004. 912 [2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain 913 Name Mapping", RFC 3731, March 2004. 915 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 916 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 917 October 2000, . 919 [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 920 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 921 . 923 [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C 924 REC-xmlschema-2, May 2001, . 926 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 927 Levels", BCP 14, RFC 2119, March 1997. 929 [7] Klyne, G. and C. Newman, "Date and Time on the Internet: 930 Timestamps", RFC 3339, July 2002. 932 [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 933 2004. 935 [9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 936 REC-xml-names, January 1999, . 939 10.2 Informative References 941 [10] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 942 954, October 1985. 944 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 945 2279, January 1998. 947 [12] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 948 RFC 2781, February 2000. 950 Author's Address 952 Scott Hollenbeck 953 VeriSign, Inc. 954 21345 Ridgetop Circle 955 Dulles, VA 20166-6503 956 US 958 EMail: shollenbeck@verisign.com 960 Intellectual Property Statement 962 The IETF takes no position regarding the validity or scope of any 963 Intellectual Property Rights or other rights that might be claimed to 964 pertain to the implementation or use of the technology described in 965 this document or the extent to which any license under such rights 966 might or might not be available; nor does it represent that it has 967 made any independent effort to identify any such rights. Information 968 on the IETF's procedures with respect to rights in IETF Documents can 969 be found in BCP 78 and BCP 79. 971 Copies of IPR disclosures made to the IETF Secretariat and any 972 assurances of licenses to be made available, or the result of an 973 attempt made to obtain a general license or permission for the use of 974 such proprietary rights by implementers or users of this 975 specification can be obtained from the IETF on-line IPR repository at 976 http://www.ietf.org/ipr. 978 The IETF invites any interested party to bring to its attention any 979 copyrights, patents or patent applications, or other proprietary 980 rights that may cover technology that may be required to implement 981 this standard. Please address the information to the IETF at 982 ietf-ipr@ietf.org. 984 Disclaimer of Validity 986 This document and the information contained herein are provided on an 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 988 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 989 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 990 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 991 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Copyright Statement 996 Copyright (C) The Internet Society (2004). This document is subject 997 to the rights, licenses and restrictions contained in BCP 78, and 998 except as set forth therein, the authors retain all their rights. 1000 Acknowledgment 1002 Funding for the RFC Editor function is currently provided by the 1003 Internet Society.