idnits 2.17.1 draft-hollenbeck-epp-domain-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CHARSET' -- Possible downref: Normative reference to a draft: ref. 'EPP' == Outdated reference: A later version (-01) exists of draft-hollenbeck-epp-contact-00 -- Possible downref: Normative reference to a draft: ref. 'EPP-C' == Outdated reference: A later version (-01) exists of draft-hollenbeck-epp-host-00 -- Possible downref: Normative reference to a draft: ref. 'EPP-H' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Downref: Normative reference to an Unknown state RFC: RFC 952 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-SD' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-SS' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 November 10, 2000 Expires: May 10, 2001 6 Extensible Provisioning Protocol Domain Name Mapping 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an Extensible Provisioning Protocol (EPP) 32 mapping for the provisioning and management of Internet domain names 33 stored in a shared central repository. Specified in XML, the mapping 34 defines EPP command syntax and semantics as applied to domain names. 36 Conventions Used In This Document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 In examples, "C:" represents lines sent by a protocol client and "S:" 43 represents lines returned by a protocol server. Indentation in 44 examples is provided only to illustrate element relationships and is 45 not a REQUIRED feature of this protocol. 47 XML protocol elements are case sensitive. 49 Table of Contents 51 1. Introduction ................................................. 3 52 2. Object Attributes ............................................ 4 53 2.1 Domain Name and Host Names .................................. 4 54 2.2 Client Identifiers .......................................... 4 55 2.3 Status Values ............................................... 4 56 2.4 Domain Contacts ............................................. 5 57 2.5 Dates and Times ............................................. 5 58 2.6 Authorization Identifiers ................................... 6 59 3. EPP Command Mapping .......................................... 7 60 3.1 EPP Query Commands .......................................... 7 61 3.1.1 EPP Command ........................................ 7 62 3.1.2 EPP Command ........................................ 10 63 3.1.3 EPP Command .................................... 11 64 3.2 EPP Transform Commands ...................................... 14 65 3.2.1 EPP Command ...................................... 14 66 3.2.2 EPP Command ...................................... 16 67 3.2.3 EPP Command ....................................... 17 68 3.2.4 EPP Command .................................... 19 69 3.2.5 EPP Command ...................................... 22 70 4. Formal Syntax ................................................ 25 71 5. Internationalization Considerations .......................... 31 72 6. IANA Considerations .......................................... 31 73 7. Security Considerations ...................................... 31 74 8. References ................................................... 32 75 9. Author's Address ............................................. 33 76 10. Full Copyright Statement .................................... 34 78 1. Introduction 80 This document describes an internet domain name mapping for version 81 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is 82 specified using the Extensible Markup Language (XML) 1.0 as described 83 in [XML] and XML Schema notation as described in [XML-SD] and [XML- 84 SS]. 86 The referenced XML Schema documents recently progressed from Working 87 Draft status to Candidate Recommendation status. The references to 88 these documents and the URIs used to refer to XML Schema namespaces 89 MUST be changed once XML parsers that support the updated 90 specifications are available. 92 [EPP] provides a complete description of EPP command and response 93 structures. A thorough understanding of the base protocol 94 specification is necessary to understand the mapping described in this 95 document. 97 It is important to note that XML is case sensitive. XML 98 specifications and examples provided in this document MUST be 99 interpreted in the exact character case presented to develop a 100 conforming implementation. 102 This document is being discussed on the "rrp" mailing list. To join 103 the list, send a message to with the words 104 "subscribe rrp" in the body of the message. There is a web site for 105 the list archives at . 107 2. Object Attributes 109 An EPP domain object has attributes and associated values that may be 110 viewed and modified by the sponsoring client or the server. This 111 section describes each attribute type in detail. 113 2.1 Domain Name and Host Names 115 The syntax for domain and host names described in this document MUST 116 conform to [RFC952] as updated by [RFC1123]. These conformance 117 requirements MAY change as a result of progressing work in developing 118 standards for internationalized domain names. A server MAY restrict 119 allowable domain names to a particular top level domain, second level 120 domain, or other domain for which the server is authoritative. 122 2.2 Client Identifiers 124 All EPP clients are identified by a server-unique identifier. Client 125 identifiers use the contact identifier syntax described in [EPP-C]. 127 2.3 Status Values 129 A domain name always has at least one associated status indicator. 130 Status indicators MAY be set only by the client that sponsors a known 131 domain object and by the server on which the object resides. A client 132 MAY change the status of a domain object using the EPP 133 command. 135 Client-Managed Status Values: 137 CLIENT-HOLD 139 The domain MUST NOT be published in a zone for DNS resolution. 141 CLIENT-LOCK 143 The domain MUST NOT be modified through any action of the EPP 144 , , or commands, though the 145 command MAY be used to change the status value. The command 146 MAY be applied to avoid exceeding the end of the domain validity 147 period. Child objects MUST NOT be added or removed. 149 Server-Managed Status Values: 151 NEW 153 The domain has been delegated, can be modified, and has not been 154 published in a zone. 156 ACTIVE 158 The domain has been delegated, can be modified, and appears in a zone. 160 INACTIVE 162 The domain has not been delegated, can be modified, and does not 163 appear in a zone. 165 HOLD 167 The domain MUST NOT be published in a zone for DNS resolution. 169 LOCK 171 The domain MUST NOT be modified through any action of the EPP 172 , , or commands, though the 173 command MAY be used to change the status value. The command 174 MAY be applied to avoid exceeding the end of the domain validity 175 period. Child objects MUST NOT be added or removed. 177 PENDING-TRANSFER 179 A transfer request has been received for the domain, and processing of 180 the request is pending. 182 PENDING-DELETE 184 A delete request has been received for this domain. The domain has 185 been removed from the zone, but has not yet been purged from the 186 server database. 188 2.4 Domain Contacts 190 The syntax for domain contact identifiers is described in [EPP-C]. A 191 server MAY support a contact object service to allow contact objects 192 to be associated with domain objects. 194 2.5 Dates and Times 196 Date and time attribute values MUST be represented in Universal 197 Coordinated Time (UTC). Both extended and truncated date and time 198 forms defined in [ISO8601] MAY be used. 200 Every domain name has an associated validity period. The validity 201 period is determined when a domain object is created, and it MAY be 202 extended by the action of the EPP and commands. If 203 the end of the validity period is reached without explicit client 204 action to extend the period, a server MAY extend the period 205 automatically for one additional year or it MAY place the domain on 206 HOLD status. A domain name MUST NOT be deleted automatically upon 207 expiration of the validity period. 209 2.6 Authorization Identifiers 211 Authorization identifiers are associated with domain name objects to 212 facilitate authorization of transfer requests. Authorization 213 identifiers use the transaction identifier syntax described in [EPP]. 215 3. EPP Command Mapping 217 A detailed description of the EPP syntax and semantics can be found in 218 [EPP]. The command mappings described here are specifically for use 219 in provisioning and managing internet domain names via EPP. 221 3.1 EPP Query Commands 223 EPP provides three commands to retrieve domain information: to 224 retrieve detailed information associated with a domain, to 225 determine if a domain is known to the server, and to 226 retrieve domain transfer status information. 228 3.1.1 EPP Command 230 The EPP command is used to retrieve information associated with 231 a domain. In addition to the standard EPP command elements, the 232 command MUST contain a element that identifies 233 the domain namespace and the location of the domain schema. The 234 element MUST contain the following child elements: 236 - A element that contains the fully qualified domain 237 name for which information is requested. 239 Example command: 241 C: 242 C: 245 C: 246 C: 247 C: 249 C: example.com 250 C: 251 C: 252 C: 253 C: 2000-06-08 254 C: ClientX 255 C: ABC-12345-XYZ 256 C: 257 C: 258 C: 260 If the domain is known to the server, the EPP element 261 MUST contain a child element that identifies the 262 domain namespace and the location of the domain schema. The 263 element SHALL contain the following child elements: 265 - A element that contains the fully qualified name of 266 the domain. 268 - A element that contains the identifier of the 269 sponsoring client. 271 - One or more elements that contain the current status 272 descriptors associated with the domain. See the command 273 description for a list of valid status values. 275 - If supported by the server, one or more elements 276 that contain identifiers for the registrant, administrative, 277 technical, and billing contacts. 279 - Zero or more elements that contain the fully 280 qualified names of the name servers to which the domain is delegated. 282 - Zero or more elements that contain the fully 283 qualified names of the child name servers known under this parent 284 domain. 286 - A element that contains the identifier of the 287 client that created the domain name. 289 - A element that contains the date and time of 290 domain creation. 292 - A element that contains the date and time 293 identifying the end of the domain's registration period. 295 - A element that contains the identifier of 296 the client that last updated the domain name. This element MUST NOT 297 be present if the domain has never been modified. 299 - A element that contains the date and time 300 of the most recent domain modification. This element MUST NOT be 301 present if the domain has never been modified. 303 - A elements that contains the date and 304 time of the most recent successful transfer. This element MUST NOT be 305 provided if the domain has never been transferred. 307 - A elements derived from either the original 308 creation transaction or the most recent successful transfer 309 transaction. This element MUST NOT be provided if the querying client 310 is not the current sponsoring client. 312 Example response: 314 S: 315 S: 318 S: 319 S: 320 S: Command completed successfully 321 S: 322 S: 323 S: 325 S: example.com 326 S: ClientX 327 S: ACTIVE 328 S: SH0000 329 S: SH0000 330 S: SH0000 331 S: SH0000 332 S: ns1.example.com 333 S: ns2.example.com 334 S: ns1.example.com 335 S: ns2.example.com 336 S: ClientY 337 S: 1999-04-03T22:00:00.0Z 338 S: 339 S: 2005-04-03T22:00:00.0Z 340 S: 341 S: ClientX 342 S: 1999-12-03T09:00:00.0Z 343 S: 344 S: 2000-04-08T09:00:00.0Z 345 S: 346 S: 347 S: 2000-04-08 348 S: ClientX 349 S: ABC-98765-XYZ 350 S: 351 S: 352 S: 353 S: 354 S: 2000-06-08 355 S: ClientX 356 S: ABC-12345-XYZ 357 S: 358 S: 359 S: 361 An EPP error response MUST be returned if an command could not 362 be processed for any reason. 364 3.1.2 EPP Command 366 The EPP command is used to determine if a domain name is known 367 to the server. In addition to the standard EPP command elements, the 368 command MUST contain a element that identifies 369 the domain namespace and the location of the domain schema. The 370 element MUST contain the following child elements: 372 - One or more (up to a maximum of sixteen) elements that 373 contain the fully qualified name of the queried domains. 375 Example command: 377 C: 378 C: 381 C: 382 C: 383 C: 385 C: example1.com 386 C: example2.com 387 C: example3.com 388 C: 389 C: 390 C: 391 C: 2000-06-08 392 C: ClientX 393 C: ABC-12345-XYZ 394 C: 395 C: 396 C: 398 When a command has been processed successfully, the EPP 399 element MUST contain a child 400 element that identifies the domain namespace and the location of the 401 domain schema. The element SHALL contain the 402 following child elements: 404 - One or more (up to a maximum of sixteen) elements that 405 contain the fully qualified name of the queried domains and a "result" 406 attribute whose value identifies the object as either "known" or 407 "unknown". 409 Example response: 411 S: 412 S: 415 S: 416 S: 417 S: Command completed successfully 418 S: 419 S: 420 S: 422 S: example1.com 423 S: example2.com 424 S: example3.com 425 S: 426 S: 427 S: 428 S: 2000-06-08 429 S: ClientX 430 S: ABC-12345-XYZ 431 S: 432 S: 433 S: 435 An EPP error response MUST be returned if a command could not 436 be processed for any reason. 438 3.1.3 EPP Command 440 The EPP command provides a query operation that allows a 441 client to determine real-time status of pending and completed transfer 442 requests. In addition to the standard EPP command elements, the 443 command MUST contain an "op" attribute with value "query", 444 and a element that identifies the domain 445 namespace and the location of the domain schema. The 446 element MUST contain the following child 447 elements: 449 - A element that contains the fully qualified name of 450 the domain. 452 Example query command: 454 C: 455 C: 458 C: 459 C: 460 C: 462 C: example.com 463 C: 464 C: 465 C: 1999-06-08 466 C: ClientX 467 C: ABC-98765-XYZ 468 C: 469 C: 470 C: 471 C: 2000-06-08 472 C: ClientX 473 C: ABC-12345-XYZ 474 C: 475 C: 476 C: 478 When a command has been processed successfully, a server 479 MUST respond with an EPP element that MUST contain a 480 child element that identifies the domain 481 namespace and the location of the domain schema. The 482 element SHALL contain the following child 483 elements: 485 - A element that contains the fully qualified domain 486 name used in the query. 488 - A element that contains the identifier of 489 the client that initiated the transfer request. 491 - A element that contains the identifier of the 492 client that SHOULD respond to the transfer request. 494 - A element that contains the state of the 495 most recent transfer request. Valid values are "PENDING", "APPROVED", 496 "REJECTED", "AUTO-APPROVED", "AUTO-REJECTED", and "CANCELLED". 498 - A element that contains the date and time that 499 the transfer was requested. 501 - A element that contains the date and time of a 502 required or completed response. For a PENDING request, the value 503 identifies the date and time by which a response is required before an 504 automated response action MUST be taken by the server. For all other 505 status types, the value identifies the date and time when the request 506 was completed. 508 - An OPTIONAL element that contains the end 509 of the domain's validity period if the command caused or 510 causes a change in the validity period. 512 Example query response: 514 S: 515 S: 518 S: 519 S: 520 S: Command completed successfully 521 S: 522 S: 523 S: 525 S: example.com 526 S: ClientX 527 S: ClientY 528 S: PENDING 529 S: 530 S: 2000-06-06T22:00:00.0Z 531 S: 532 S: 533 S: 2000-06-11T22:00:00.0Z 534 S: 535 S: 536 S: 2002-09-08T22:00:00.0Z 537 S: 538 S: 539 S: 540 S: 541 S: 2000-06-08 542 S: ClientX 543 S: ABC-12345-XYZ 544 S: 545 S: 546 S: 547 An EPP error response MUST be returned if a query command 548 could not be processed for any reason. 550 3.2 EPP Transform Commands 552 EPP provides five commands to transform domain object information: 553 to create an instance of a domain object, to delete 554 an instance of a domain object, to extend the validity period 555 of a domain object, to manage domain object sponsorship 556 changes, and to change information associated with a domain 557 object. 559 3.2.1 EPP Command 561 The EPP command provides a transform operation that allows a 562 client to create a domain object. In addition to the standard EPP 563 command elements, the command MUST contain a 564 element that identifies the domain namespace and the location of the 565 domain schema. The element MUST contain the following 566 child elements: 568 - A element that contains the fully qualified domain 569 name of the object to be created. 571 - An OPTIONAL element that contains the initial 572 registration period of the domain, measured in years. If not 573 specified, the initial registration period MUST be one year. The 574 minimum allowable value is one (1) year. The maximum allowable value 575 is ninety-nine (99) years. A server MAY support a lower maximum 576 value. 578 - Zero or more (up to a maximum of thirteen) elements 579 that contain the fully qualified host name of a known host object to 580 provide resolution services for the domain. A host object MUST be 581 known to the server before a domain can be delegated to the host. A 582 server MUST provide host object services to provide domain name 583 services. The EPP mapping for host objects is described in [EPP-H]. 585 - Zero or more (up to a maximum of four) elements 586 that contain the registrant, administrative, technical, and billing 587 contact identifiers to be associated with the domain. A contact 588 identifier MUST be known to the server before the contact can be 589 associated with the domain. Only one contact identifier of each type 590 MAY be specified. A server MAY provide contact object services when 591 providing domain name object services. The EPP mapping for contact 592 objects is described in [EPP-C]. 594 It is important to note that the transaction identifier associated 595 with successful creation of a domain object becomes the authorization 596 identifier required to transfer sponsorship of the domain object. A 597 client MUST retain all transaction identifiers associated with domain 598 object creation and protect them from disclosure. A client MUST also 599 provide a copy of the transaction identifier information to the domain 600 registrant, who will need this information to request a domain 601 transfer through a different client. 603 Example command: 605 C: 606 C: 609 C: 610 C: 611 C: 613 C: example.com 614 C: 2 615 C: ns1.example.com 616 C: ns2.example.com 617 C: SH0000 618 C: SH0000 619 C: SH0000 620 C: SH0000 621 C: 622 C: 623 C: 624 C: 2000-06-08 625 C: ClientX 626 C: ABC-12345-XYZ 627 C: 628 C: 629 C: 631 When a command has been processed successfully, a server MUST 632 respond with an EPP element that MUST contain a child 633 element that identifies the domain namespace and 634 the location of the domain schema. The element 635 SHALL contain the following child elements: 637 - A element that contains the fully qualified domain 638 name that has been created. 640 - A element that contains the end of the 641 domain's validity period. 643 Example response: 645 S: 646 S: 649 S: 650 S: 651 S: Command completed successfully 652 S: 653 S: 654 S: 656 S: example.com 657 S: 658 S: 2002-06-08T22:00:00.0Z 659 S: 660 S: 661 S: 662 S: 663 S: 2000-06-08 664 S: ClientX 665 S: ABC-12345-XYZ 666 S: 667 S: 668 S: 670 An EPP error response MUST be returned if a command could not 671 be processed for any reason. 673 3.2.2 EPP Command 675 The EPP command provides a transform operation that allows a 676 client to delete a domain object. In addition to the standard EPP 677 command elements, the command MUST contain a 678 element that identifies the domain namespace and the location of the 679 domain schema. The element SHALL contain the 680 following child elements: 682 - A element that contains the fully qualified domain 683 name of the object to be deleted. 685 A domain name MUST NOT be deleted if the domain is associated with 686 child name servers. For example, if domain "example.com" is known, 687 and name server "ns1.example.com" is also known, then domain 688 "example.com" MUST NOT be deleted until server "ns1.example.com" has 689 been either deleted or renamed to exist in a different parent domain. 691 Example command: 693 C: 694 C: 697 C: 698 C: 699 C: 701 C: example.com 702 C: 703 C: 704 C: 705 C: 2000-06-08 706 C: ClientX 707 C: ABC-12345-XYZ 708 C: 709 C: 710 C: 712 When a command has been processed successfully, a server MUST 713 respond with an EPP response with no element. 715 Example response: 717 S: 718 S: 721 S: 722 S: 723 S: Command completed successfully 724 S: 725 S: 726 S: 2000-06-08 727 S: ClientX 728 S: ABC-12345-XYZ 729 S: 730 S: 731 S: 733 An EPP error response MUST be returned if a command could not 734 be processed for any reason. 736 3.2.3 EPP Command 737 The EPP command provides a transform operation that allows a 738 client to extend the validity period of a domain object. In addition 739 to the standard EPP command elements, the command MUST contain 740 a element that identifies the domain namespace and the 741 location of the domain schema. The element SHALL 742 contain the following child elements: 744 - A element that contains the fully qualified domain 745 name of the object whose validity period is to be extended. 747 - A element that contains the year in 748 which the current validity period ends. This value ensures that 749 repeated commands do not result in multiple unanticipated 750 successful renewals. 752 - A element that contains the number of years to be 753 added to the validity period of the domain. The minimum allowable 754 value is one (1) year. The maximum allowable value is ninety-nine 755 (99) years. A server MAY support a lower maximum value. 757 Example command: 759 C: 760 C: 763 C: 764 C: 765 C: 767 C: example.com 768 C: 2000 769 C: 770 C: 5 771 C: 772 C: 773 C: 774 C: 2000-06-08 775 C: ClientX 776 C: ABC-12345-XYZ 777 C: 778 C: 779 C: 781 When a command has been processed successfully, a server MUST 782 respond with an EPP element that MUST contain a child 783 element that identifies the domain namespace and 784 the location of the domain schema. The element 785 SHALL contain the following child elements: 787 - A element that contains the fully qualified domain 788 name whose validity period has been extended. 790 - A element that contains the end of the 791 domain's validity period. 793 Example response: 795 S: 796 S: 799 S: 800 S: 801 S: Command completed successfully 802 S: 803 S: 804 S: 806 S: example.com 807 S: 808 S: 2005-04-03T22:00:00.0Z 809 S: 810 S: 811 S: 812 S: 813 S: 2000-06-08 814 S: ClientX 815 S: ABC-12345-XYZ 816 S: 817 S: 818 S: 820 An EPP error response MUST be returned if a command could not 821 be processed for any reason. 823 3.2.4 EPP Command 825 The EPP command provides a transform operation that allows 826 a client to manage requests to transfer the sponsorship of a domain 827 object. In addition to the standard EPP command elements, the 828 command MUST contain a element that 829 identifies the domain namespace and the location of the domain schema. 830 The element SHALL contain the following child 831 elements: 833 - A element that contains the fully qualified domain 834 name of the object for which a transfer request is to be created, 835 approved, rejected, or cancelled. 837 - An OPTIONAL element that contains a number of years 838 to be added to the registration period of the domain if the transfer 839 is successful. If not specified, the registration period MUST NOT be 840 changed as a result of the transfer. The minimum allowable value is 841 one (1) year. The maximum allowable value is ninety-nine (99) years. 842 A server MAY support a lower maximum value. This element MUST be 843 consistently present or absent for all associated request, approval, 844 rejection, or cancellation operations. 846 Every EPP command MUST contain an "op" attribute that 847 identifies the transfer operation to be performed. Valid values, 848 definitions, and authorizations for all attribute values are defined 849 in [EPP]. 851 Every EPP command MUST also contain an authorization 852 identifier as described in [EPP]. It is important to note that the 853 transaction identifier associated with successful transfer of a domain 854 object becomes the authorization identifier required to authorize 855 subsequent transfers of sponsorship of the domain object. A client 856 MUST retain all transaction identifiers associated with successful 857 domain object transfers and protect them from disclosure. A client 858 MUST provide a copy of the transaction identifier information to the 859 domain registrant, who will need this information to request a domain 860 transfer through a different client. 862 Example request command: 864 C: 865 C: 868 C: 869 C: 870 C: 872 C: example.com 873 C: 1 874 C: 875 C: 876 C: 1999-06-08 877 C: ClientX 878 C: ABC-98765-XYZ 879 C: 880 C: 881 C: 882 C: 2000-06-08 883 C: ClientY 884 C: ABC-12345-XYZ 885 C: 886 C: 887 C: 889 When a command has been processed successfully, a server 890 MUST respond with an EPP element that MUST contain a 891 child element that identifies the domain 892 namespace and the location of the domain schema. The 893 element SHALL contain the same child elements 894 defined for a transfer query response. 896 Example response: 898 S: 899 S: 902 S: 903 S: 904 S: Command completed successfully 905 S: 906 S: 907 S: 909 S: example.com 910 S: ClientX 911 S: ClientY 912 S: PENDING 913 S: 914 S: 2000-06-08T22:00:00.0Z 915 S: 916 S: 917 S: 2000-06-13T22:00:00.0Z 918 S: 919 S: 920 S: 2002-09-08T22:00:00.0Z 921 S: 922 S: 923 S: 924 S: 925 S: 2000-06-08 926 S: ClientX 927 S: ABC-12345-XYZ 928 S: 929 S: 930 S: 932 An EPP error response MUST be returned if a command could 933 not be processed for any reason. 935 3.2.5 EPP Command 937 The EPP command provides a transform operation that allows a 938 client to modify the attributes of a domain object. In addition to 939 the standard EPP command elements, the command MUST contain a 940 element that identifies the domain namespace and the 941 location of the domain schema. The element SHALL 942 contain the following child elements: 944 - A element that contains the fully qualified domain 945 name of the object to be updated. 947 - An OPTIONAL element that contains attribute values to 948 be added to the domain object. 950 - An OPTIONAL element that contains attribute values 951 to be removed from the domain object. 953 Either a element or a element MUST be 954 provided. The and elements SHALL contain 955 the following child elements: 957 - Zero or more elements that contain the fully 958 qualified host name of a known host object. A host object MUST be 959 known to the server before a server attribute can be added or removed 960 from a domain object. The EPP mapping for host objects is described 961 in [EPP-H]. 963 - Zero or more (up to a maximum of four) elements 964 that contain the registrant, administrative, technical, and billing 965 contact identifiers to be associated with the domain. A contact 966 identifier MUST be known to the server before the contact can be 967 associated with the domain. Only one contact identifier of each type 968 MAY be specified. A server MAY provide contact object services when 969 providing domain name object services. The EPP mapping for contact 970 objects is described in [EPP-C]. 972 - One or two elements that contain status values to be 973 applied to or removed from the domain object. 975 It is important to note that the maximum number of domain attribute 976 elements is subject to the number of values currently associated with 977 the domain object. For example, if a domain object currently has "n" 978 server attribute elements, the maximum number of server attribute 979 elements that can be added is 13 - "n". Likewise, the maximum number 980 of contact elements that can be added is 4 - "n", with the added 981 restriction that only one contact of each type (registrant, 982 administrative, technical, or billing) MAY be associated with a domain 983 object. 985 Example command: 987 C: 988 C: 991 C: 992 C: 993 C: 995 C: example.com 996 C: 997 C: ns1.example.com 998 C: SH0000 999 C: CLIENT-HOLD 1000 C: 1001 C: 1002 C: ns2.example.com 1003 C: SH0000 1004 C: CLIENT-LOCK 1005 C: 1006 C: 1007 C: 1008 C: 1009 C: 2000-06-08 1010 C: ClientX 1011 C: ABC-12345-XYZ 1012 C: 1013 C: 1014 C: 1016 When an command has been processed successfully, a server 1017 MUST respond with an EPP response with no element. 1019 Example response: 1021 S: 1022 S: 1025 S: 1026 S: 1027 S: Command completed successfully 1028 S: 1029 S: 1030 S: 2000-06-08 1031 S: ClientX 1032 S: ABC-12345-XYZ 1033 S: 1034 S: 1035 S: 1037 An EPP error response MUST be returned if an command could 1038 not be processed for any reason. 1040 4. Formal Syntax 1042 An EPP object mapping is specified in XML Schema notation. The formal 1043 syntax presented here is a complete schema representation of the 1044 object mapping suitable for automated validation of EPP XML instances. 1046 1048 1054 1055 1056 Extensible Provisioning Protocol v1.0 domain provisioning schema. 1057 1058 1060 1063 1064 1066 1069 1070 1071 1072 1073 1074 1075 1076 1078 1081 1082 1083 1084 1085 1087 1088 1089 1090 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1103 1106 1107 1108 1109 1111 1112 1113 1114 1115 1116 1117 1118 1119 1121 1122 1123 1125 1127 1129 1131 1134 1135 1136 1138 1140 1143 1144 1145 1147 1150 1151 1153 1155 1158 1159 1160 1161 1163 1165 1168 1169 1170 1172 1174 1176 1177 1179 1181 1183 1185 1188 1189 1190 1191 1193 1194 1195 1196 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1210 1212 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1227 1228 1229 1230 1231 1232 1233 1234 1236 1237 1238 1239 1241 1243 1245 1247 1248 1249 1250 1252 1254 1256 1258 1259 1260 1261 1262 1263 1264 1265 1266 1268 1270 1273 1275 5. Internationalization Considerations 1277 EPP is represented in XML, which provides native support for encoding 1278 information using the double-byte Unicode character set and its more 1279 compact representations including UTF-8. Compliant XML processors are 1280 required to understand both UTF-8 and raw Unicode character sets; XML 1281 also includes a provision for identifying other character sets through 1282 use of an "encoding" attribute in an processing instruction. 1283 The complete list of character set encoding identifiers is maintained 1284 by IANA and is described in [CHARSET] and [RFC1700]. 1286 All date-time values presented via EPP MUST be expressed in Universal 1287 Coordinated Time. The XML Schema "date" format allows use of time 1288 zone identifiers to indicate offsets from the zero meridian, but this 1289 option MUST NOT be used within EPP. Both extended and truncated date 1290 and time forms defined in [ISO8601] MAY be used. 1292 This document requires domain and host name syntax as specified in 1293 [RFC952] as updated by [RFC1123]. These conformance requirements MAY 1294 change as a result of progressing work in developing standards for 1295 internationalized domain names. 1297 6. IANA Considerations 1299 XML schemas require a URI for unique identification. Schemas MUST be 1300 registered to ensure URI uniqueness, but the IETF does not currently 1301 have a recommended repository for the registration of XML schemas. 1302 This document uses URNs to describe XML namespaces and XML schemas. 1303 IANA SHOULD maintain a registry of XML namespace and schema URI 1304 assignments. Per policies described in [IANA], URI assignment 1305 requests SHOULD be reviewed by a designated expert, and values SHOULD 1306 be assigned only as a result of standards action taken by the IESG. 1308 7. Security Considerations 1310 The object mapping described in this document does not provide any 1311 security services beyond those specified by [EPP]. 1313 8. References 1315 [CHARSET] ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 1317 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", draft- 1318 hollenbeck-epp-00.txt, work in progress. 1320 [EPP-C] S. Hollenbeck: "Extensible Provisioning Protocol Contact 1321 Mapping", draft-hollenbeck-epp-contact-00.txt, work in progress. 1323 [EPP-H] S. Hollenbeck: "Extensible Provisioning Protocol Host 1324 Mapping", draft-hollenbeck-epp-host-00.txt, work in progress. 1326 [IANA] T. Narten, H. Alvestrand: "Guidelines for Writing an IANA 1327 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1329 [ISO8601] ISO 8601:1988 (E): "Data elements and interchange formats - 1330 Information interchange - Representation of dates and times - The 1331 International Organization for Standardization". 1333 [RFC952] K. Harrenstien et al.: "DOD Internet Host Table 1334 Specification", RFC 952, October 1985. 1336 [RFC1123] R. Braden: "Requirements for Internet Hosts -- Application 1337 and Support", RFC 1123, October 1989. 1339 [RFC1700] J. Reynolds, J. Postel: "Assigned Numbers", STD 2, RFC 1700, 1340 October 1994. 1342 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 1343 Requirement Levels", BCP 14, RFC 2119, March 1997. 1345 [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0", 1346 http://www.w3.org/TR/REC-xml, W3C Recommendation February 1998 1348 [XML-SD] Editors P. Biron and A. Malhotra: "XML Schema Part 2: 1349 Datatypes", http://www.w3.org/TR/xmlschema-2/, W3C Working Draft April 1350 2000 1352 [XML-SS] Editor H. Thompson et al.: "XML Schema Part 1: Structures", 1353 http://www.w3.org/TR/xmlschema-1/, W3C Working Draft April 2000 1355 9. Author's Address 1357 Scott Hollenbeck 1358 VeriSign Global Registry Services 1359 21345 Ridgetop Circle 1360 Dulles, VA 20166-6503 1361 USA 1362 shollenbeck@verisign.com 1364 10. Full Copyright Statement 1366 Copyright (C) The Internet Society 2000. All Rights Reserved. 1368 This document and translations of it may be copied and furnished to 1369 others, and derivative works that comment on or otherwise explain it 1370 or assist in its implementation may be prepared, copied, published and 1371 distributed, in whole or in part, without restriction of any kind, 1372 provided that the above copyright notice and this paragraph are 1373 included on all such copies and derivative works. However, this 1374 document itself may not be modified in any way, such as by removing 1375 the copyright notice or references to the Internet Society or other 1376 Internet organizations, except as needed for the purpose of developing 1377 Internet standards in which case the procedures for copyrights defined 1378 in the Internet Standards process must be followed, or as required to 1379 translate it into languages other than English. 1381 The limited permissions granted above are perpetual and will not be 1382 revoked by the Internet Society or its successors or assigns. 1384 This document and the information contained herein is provided on an 1385 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1386 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1387 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1388 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1389 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1391 Acknowledgement 1393 Funding for the RFC Editor function is currently provided by the 1394 Internet Society.