idnits 2.17.1 draft-hollenbeck-epp-rgp-04.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 994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 984. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1000), 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 16, 2004) is 7308 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 937, 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 15, 2004 April 16, 2004 6 Domain Registry Grace Period Mapping 7 for the Extensible Provisioning Protocol 8 draft-hollenbeck-epp-rgp-04.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 15, 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 Registration 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 Registration Data and Supporting Information 277 This extension allows a client to provide copies of registration data 278 (whois [10] data, for example) and supporting information in a 279 restore report as required by the RGP process. No specific format is 280 required by this extension; both free text and XML markup MAY be 281 used. 283 Operators of servers that provide registration data might find it 284 useful to provide grace period status values in their responses to 285 client queries. This information can be useful to people who want to 286 understand the operations that can be performed on a domain name at 287 any give time. 289 3.3 Dates and Times 291 Date and time attribute values MUST be represented in Universal 292 Coordinated Time (UTC) using the Gregorian calendar. The extended 293 date-time form using upper case "T" and "Z" characters defined in RFC 294 3339 [7] MUST be used to represent date-time values as XML Schema 295 does not support truncated date-time forms or lower case "T" and "Z" 296 characters. 298 3.4 Client Statements 300 The RGP process requires a client to make two statements regarding 301 the data included in a restore report. No specific format is 302 required by this extension; both free text and XML markup MAY be 303 used. English is the default language used within the statements, 304 but other languages MAY be used. 306 4. EPP Command Mapping 308 A detailed description of the EPP syntax and semantics can be found 309 in the EPP core protocol specification [1]. The command mappings 310 described here are specifically for use in implementing redemption 311 grace period processes via EPP. 313 4.1 EPP Query Commands 315 EPP provides three commands to retrieve object information: 316 to determine if an object is known to the server, to retrieve 317 detailed information associated with an object, and to 318 retrieve object transfer status information. 320 4.1.1 EPP Command 322 This extension does not add any elements to the EPP command 323 or response described in the EPP domain mapping [2]. 325 4.1.2 EPP Command 327 This extension does not add any elements to the EPP command 328 described in the EPP domain mapping [2]. Additional elements are 329 defined for the response. 331 When an command has been processed successfully, the EPP 332 element MUST contain child elements as described in [2]. 333 In addition, the EPP element MUST contain a child 334 element that identifies the registry grace period 335 namespace and the location of the registry grace period schema. The 336 element contains a single element that 337 contains a single attribute "s" whose value describes the current 338 grace period status of the domain. Possible status values are 339 described in section Section 3.1. 341 Example response for "addPeriod" status: 343 S: 344 S: 348 S: 349 S: 350 S: Command completed successfully 351 S: 352 S: 353 S: 357 S: example.com 358 S: EXAMPLE1-REP 359 S: 360 S: jd1234 361 S: sh8013 362 S: sh8013 363 S: 364 S: ns1.example.com 365 S: ns1.example.net 366 S: 367 S: ns1.example.com 368 S: ns2.example.com 369 S: ClientX 370 S: ClientX 371 S: 2003-11-26T22:00:00.0Z 372 S: 2005-11-26T22:00:00.0Z 373 S: 374 S: 2fooBAR 375 S: 376 S: 377 S: 378 S: 379 S: 382 S: 383 S: 384 S: 385 S: 386 S: ABC-12345 387 S: 54322-XYZ 388 S: 389 S: 390 S: 392 Example response for "redemptionPeriod" status: 394 S: 395 S: 399 S: 400 S: 401 S: Command completed successfully 402 S: 403 S: 404 S: 408 S: example.com 409 S: EXAMPLE1-REP 410 S: 411 S: jd1234 412 S: sh8013 413 S: sh8013 414 S: 415 S: ns1.example.com 416 S: ns1.example.net 417 S: 418 S: ns1.example.com 419 S: ns2.example.com 420 S: ClientX 421 S: ClientY 422 S: 1999-04-03T22:00:00.0Z 423 S: ClientX 424 S: 1999-12-03T09:00:00.0Z 425 S: 2005-04-03T22:00:00.0Z 426 S: 2000-04-08T09:00:00.0Z 427 S: 428 S: 2fooBAR 429 S: 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 Example response extension for "pendingRestore" status (note 447 that only the extension element changes from the first example): 449 S: 450 S: 453 S: 454 S: 455 S: 457 Example response extension for "pendingDelete" status (note 458 that only the extension element changes from the first example): 460 S: 461 S: 464 S: 465 S: 466 S: 468 4.1.3 EPP Command 470 This extension does not add any elements to the EPP 471 command or response described in the EPP domain mapping 472 [2]. 474 4.2 EPP Transform Commands 476 EPP provides five commands to transform objects: to create 477 an instance of an object, to delete an instance of an 478 object, to extend the validity period of an object, 479 to manage object sponsorship changes, and to 480 change information associated with an object. 482 4.2.1 EPP Command 484 This extension does not add any elements to the EPP command 485 or response described in the EPP domain mapping [2]. 487 4.2.2 EPP Command 489 This extension does not add any elements to the EPP command 490 or response described in the EPP domain mapping [2]. 492 4.2.3 EPP Command 494 This extension does not add any elements to the EPP command 495 or response described in the EPP domain mapping [2]. 497 4.2.4 EPP Command 499 This extension does not add any elements to the EPP 500 command or response described in the EPP domain mapping 501 [2]. 503 4.2.5 EPP Command 505 This extension defines additional elements to extend the EPP 506 command and response described in the EPP domain mapping [2] for 507 redemption grace period processing. 509 The EPP command provides a transform operation that allows a 510 client to change the state of a domain object. The registry grace 511 period extension modifies base update processing to support 512 redemption of domain names for which a command has been 513 processed, but the name has not yet been purged. 515 Section 3.2.5 of the EPP domain mapping describes the elements that 516 have to be specified within an command. The requirement to 517 provide at least one , , or 518 element is updated by this extension such that at least one empty 519 , , or element MUST be present 520 if this extension is specified within an command. This 521 requirement is updated to disallow the possibility of modifying a 522 domain object as part of redemption grace period recovery processing. 524 In addition to the EPP command elements described in the EPP domain 525 mapping [2], the command MUST contain an 526 element. The element MUST contain a child 527 element that identifies the registry grace period namespace and the 528 location of the registry grace period schema. The 529 element contains a single element that contains an 530 OPTIONAL element that MAY be used to deliver a 531 redemption grace period restore report. 533 The element contains a REQUIRED "op" attribute that 534 describes the redemption grace period operation being requested. Two 535 values are defined: "request" is used to identify a restore request 536 that does not include a restore report, and "report" is used to 537 identify a restore request that contains a restore report. A report 538 MAY be submitted more than once if corrections are required. If the 539 value of the "op" attribute is "request" an element MUST 540 NOT be present. If the value of the "op" attribute is "report" an 541 element MUST be present. 543 The element contains the following child elements: 545 - An element that contains a copy of the registration 546 data that existed for the domain name prior to the domain name 547 being deleted. This element MAY contain both text and XML markup. 549 - An element that contains a copy of the registration 550 data that exists for the domain name at the time the restore 551 report is submitted. This element MAY contain both text and XML 552 markup. 554 - An element that contains the date and time when the 555 domain name delete request was sent to the server. 557 - An element that contains the date and time when the 558 original command was sent to the server. 560 - An element that contains a brief explanation of 561 the reason for restoring the domain name. 563 - An element that contains a text statement that the 564 client has not restored the domain name in order to assume the 565 rights to use or sell the domain name for itself or for any third 566 party. Supporting information related to this statement MAY be 567 supplied in the element described below. An OPTIONAL 568 "lang" attribute MAY be present to identify the language if 569 English (value "en") is not used to represent the statement. 571 - A second element that contains a text statement 572 that the information in the restore report is factual to the best 573 of the client's knowledge. An OPTIONAL "lang" attribute MAY be 574 present to identify the language if English (value "en") is not 575 used to represent the statement. 577 - An OPTIONAL element that contains any information 578 needed to support the statements provided by the client. This 579 element MAY contain both text and XML markup. 581 More detailed information describing the information required to be 582 provided in a restore report is available from ICANN. 584 Example command without a restore report: 586 C: 587 C: 591 C: 592 C: 593 C: 597 C: example.com 598 C: 599 C: 600 C: 601 C: 602 C: 605 C: 606 C: 607 C: 608 C: ABC-12345 609 C: 610 C: 611 Example command with a restore report: 613 C: 614 C: 618 C: 619 C: 620 C: 624 C: example.com 625 C: 626 C: 627 C: 628 C: 629 C: 632 C: 633 C: 634 C: Pre-delete registration data goes here. 635 C: Both XML and free text are allowed. 636 C: Post-restore registration data goes here. 637 C: Both XML and free text are allowed. 638 C: 2003-07-10T22:00:00.0Z 639 C: 2003-07-20T22:00:00.0Z 640 C: Registrant error. 641 C: This registrar has not restored the 642 C: Registered Name in order to assume the rights to use 643 C: or sell the Registered Name for itself or for any 644 C: third party. 645 C: The information in this report is 646 C: true to best of this registrar's knowledge, and this 647 C: registrar acknowledges that intentionally supplying 648 C: false information in this report shall constitute an 649 C: incurable material breach of the 650 C: Registry-Registrar Agreement. 651 C: Supporting information goes 652 C: here. 653 C: 654 C: 655 C: 656 C: 657 C: ABC-12345 658 C: 659 C: 661 When an extended command without a restore report has been 662 processed successfully, the EPP response is as described in the EPP 663 domain mapping [2] except that an extension element is added to 664 describe grace period status as a result of processing the 665 command. The extension element contains a single child element 666 () that itself contains a single child element () 667 that contains a single attribute "s" whose value MUST be 668 "pendingRestore" if the request has been accepted. 670 Example "restore request" response: 672 S: 673 S: 677 S: 678 S: 679 S: Command completed successfully 680 S: 681 S: 682 S: 685 S: 686 S: 687 S: 688 S: 689 S: ABC-12345 690 S: 54321-XYZ 691 S: 692 S: 693 S: 695 When an extended command with a restore report has been 696 processed successfully, the EPP response is as described in the EPP 697 domain mapping [2] with no registry grace period extension. Registry 698 grace period extension is not required because acceptance of the 699 restore report completes redemption grace period processing. 701 5. Formal Syntax 703 An EPP object mapping is specified in XML Schema notation. The 704 formal syntax presented here is a complete schema representation of 705 the object mapping suitable for automated validation of EPP XML 706 instances. The BEGIN and END tags are not part of the schema; they 707 are used to note the beginning and ending of the schema for URI 708 registration purposes. 710 BEGIN 711 713 718 719 720 Extensible Provisioning Protocol v1.0 721 domain name extension schema for registry grace period 722 processing. 723 724 726 729 731 735 736 737 738 739 741 742 743 745 746 747 749 753 754 755 756 757 758 760 761 762 763 764 765 766 767 769 771 772 774 775 776 777 778 780 781 782 783 785 786 787 788 789 791 792 793 794 795 797 800 801 803 806 807 808 809 810 812 817 818 819 820 822 823 824 825 827 828 829 830 831 832 833 834 835 836 837 839 842 843 END 845 6. Internationalization Considerations 847 EPP is represented in XML, which provides native support for encoding 848 information using the Unicode character set and its more compact 849 representations including UTF-8 [11]. Conformant XML processors 850 recognize both UTF-8 and UTF-16 [12]. Though XML includes provisions 851 to identify and use other character encodings through use of an 852 "encoding" attribute in an declaration, use of UTF-8 is 853 RECOMMENDED in environments where parser encoding support 854 incompatibility exists. 856 As an extension of the EPP domain mapping [2], the elements, element 857 content, attributes, and attribute values described in this document 858 MUST inherit the internationalization conventions used to represent 859 higher-layer domain and core protocol structures present in an XML 860 instance that includes this extension. 862 7. IANA Considerations 864 This document uses URNs to describe XML namespaces and XML schemas 865 conforming to a registry mechanism described in RFC 3688 [8]. Two URI 866 assignments are requested. 868 Registration request for the registry grace period namespace: 870 URI: urn:ietf:params:xml:ns:rgp-1.0 872 Registrant Contact: See the "Author's Address" section of this 873 document. 875 XML: None. Namespace URIs do not represent an XML specification. 877 Registration request for the registry grace period XML schema: 879 URI: urn:ietf:params:xml:schema:rgp-1.0 881 Registrant Contact: See the "Author's Address" section of this 882 document. 884 XML: See the "Formal Syntax" section of this document. 886 8. Security Considerations 888 The mapping extensions described in this document do not provide any 889 security services beyond those described by EPP [1], the EPP domain 890 name mapping [2], and protocol layers used by EPP. The security 891 considerations described in these other specifications apply to this 892 specification as well. 894 As with other domain object updates, redemption of a deleted domain 895 object MUST be restricted to the sponsoring client. Any attempt to 896 recover a deleted domain object by any client other than the 897 sponsoring client MUST be rejected with an appropriate EPP 898 authorization error. 900 9. Acknowledgements 902 The author would like to thank the following people who have provided 903 significant contributions to the development of this document: 905 James Gould, Antony Perkov, and Janusz Sienkiewicz. 907 10. References 909 10.1 Normative References 911 [1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 912 3730, March 2004. 914 [2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain 915 Name Mapping", RFC 3731, March 2004. 917 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 918 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 919 October 2000, . 921 [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 922 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 923 . 925 [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C 926 REC-xmlschema-2, May 2001, . 928 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 929 Levels", BCP 14, RFC 2119, March 1997. 931 [7] Klyne, G. and C. Newman, "Date and Time on the Internet: 932 Timestamps", RFC 3339, July 2002. 934 [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 935 2004. 937 [9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 938 REC-xml-names, January 1999, . 941 10.2 Informative References 943 [10] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 944 954, October 1985. 946 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 947 2279, January 1998. 949 [12] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 950 RFC 2781, February 2000. 952 Author's Address 954 Scott Hollenbeck 955 VeriSign, Inc. 956 21345 Ridgetop Circle 957 Dulles, VA 20166-6503 958 US 960 EMail: shollenbeck@verisign.com 962 Intellectual Property Statement 964 The IETF takes no position regarding the validity or scope of any 965 Intellectual Property Rights or other rights that might be claimed to 966 pertain to the implementation or use of the technology described in 967 this document or the extent to which any license under such rights 968 might or might not be available; nor does it represent that it has 969 made any independent effort to identify any such rights. Information 970 on the IETF's procedures with respect to rights in IETF Documents can 971 be found in BCP 78 and BCP 79. 973 Copies of IPR disclosures made to the IETF Secretariat and any 974 assurances of licenses to be made available, or the result of an 975 attempt made to obtain a general license or permission for the use of 976 such proprietary rights by implementers or users of this 977 specification can be obtained from the IETF on-line IPR repository at 978 http://www.ietf.org/ipr. 980 The IETF invites any interested party to bring to its attention any 981 copyrights, patents or patent applications, or other proprietary 982 rights that may cover technology that may be required to implement 983 this standard. Please address the information to the IETF at 984 ietf-ipr@ietf.org. 986 Disclaimer of Validity 988 This document and the information contained herein are provided on an 989 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 990 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 991 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 992 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 993 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 994 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 996 Copyright Statement 998 Copyright (C) The Internet Society (2004). This document is subject 999 to the rights, licenses and restrictions contained in BCP 78, and 1000 except as set forth therein, the authors retain all their rights. 1002 Acknowledgment 1004 Funding for the RFC Editor function is currently provided by the 1005 Internet Society.