idnits 2.17.1 draft-ietf-provreg-epp-domain-04.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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. 'DATE-TIME' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP-C' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP-H' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-XML' ** Downref: Normative reference to an Unknown state RFC: RFC 952 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-2' Summary: 3 errors (**), 0 flaws (~~), 3 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 January 24, 2002 Expires: July 24, 2002 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 and white 44 space in examples is provided only to illustrate element relationships 45 and is not a REQUIRED feature of this protocol. 47 Table of Contents 49 1. Introduction ................................................. 3 50 1.1 Relationship of Domain Objects and Host Objects ............. 3 51 2. Object Attributes ............................................ 4 52 2.1 Domain and Host Names ....................................... 4 53 2.2 Contact and Client Identifiers .............................. 4 54 2.3 Status Values ............................................... 4 55 2.4 Dates and Times ............................................. 6 56 2.5 Validity Periods ............................................ 6 57 2.6 Authorization Information ................................... 6 58 3. EPP Command Mapping .......................................... 7 59 3.1 EPP Query Commands .......................................... 7 60 3.1.1 EPP Command ....................................... 7 61 3.1.2 EPP Command ........................................ 9 62 3.1.3 EPP Command .................................... 14 63 3.2 EPP Transform Commands ...................................... 16 64 3.2.1 EPP Command ...................................... 17 65 3.2.2 EPP Command ...................................... 19 66 3.2.3 EPP Command ....................................... 21 67 3.2.4 EPP Command .................................... 22 68 3.2.5 EPP Command ...................................... 25 69 4. Formal Syntax ................................................ 29 70 5. Internationalization Considerations .......................... 37 71 6. IANA Considerations .......................................... 37 72 7. Security Considerations ...................................... 38 73 8. Acknowledgements ............................................. 38 74 9. References ................................................... 39 75 10. Author's Address ............................................ 40 76 A. Revisions From Previous Version .............................. 41 77 B. Full Copyright Statement ..................................... 42 79 1. Introduction 81 This document describes an Internet domain name mapping for version 82 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is 83 specified using the Extensible Markup Language (XML) 1.0 as described 84 in [XML] and XML Schema notation as described in [XMLS-1] and [XMLS- 85 2]. 87 [EPP] provides a complete description of EPP command and response 88 structures. A thorough understanding of the base protocol 89 specification is necessary to understand the mapping described in this 90 document. 92 XML is case sensitive. Unless stated otherwise, XML specifications 93 and examples provided in this document MUST be interpreted in the 94 character case presented to develop a conforming implementation. 96 This document is being discussed on the "ietf-provreg" mailing list. 97 To join the list, send a message to with the 98 words "subscribe ietf-provreg" in the body of the message. There is a 99 web site for the list archives at http://www.cafax.se/ietf-provreg. 101 1.1 Relationship of Domain Objects and Host Objects 103 This document assumes that domain name objects have a superordinate 104 relationship to subordinate host name objects. For example, domain 105 name "example.tld" has a superordinate relationship to host name 106 "ns1.example.tld". EPP actions (such as object transfers) that do not 107 preserve this relationship MUST be explicitly disallowed. 109 A host name object can be created in a repository for which no 110 superordinate domain name object exists. For example, host name 111 "ns1.example.tld2" can be created in the "tld1" repository so that DNS 112 domains in "tld1" can be delegated to the host. Such hosts are 113 described as "external" hosts in this specification since the 114 management authority for these hosts is external to the repository in 115 which the host is being used for delegation purposes. 117 External host objects are managed on a per-client basis. No 118 superordinate domain object exists in the repository, thus no single 119 client has management authority for the superordinate domain object. 120 Per-client management ensures that no single client can create an 121 instance of an external host object to the detriment of other clients 122 who might need to use the host for DNS delegation purposes. 124 2. Object Attributes 126 An EPP domain object has attributes and associated values that can be 127 viewed and modified by the sponsoring client or the server. This 128 section describes each attribute type in detail. The formal syntax 129 for the attribute values described here can be found in the "Formal 130 Syntax" section of this document and in the appropriate normative 131 references. 133 2.1 Domain and Host Names 135 The syntax for domain and host names described in this document MUST 136 conform to [RFC952] as updated by [RFC1123]. These conformance 137 requirements might change as a result of progressing work in 138 developing standards for internationalized domain names. A server MAY 139 restrict allowable domain names to a particular top level domain, 140 second level domain, or other domain for which the server is 141 authoritative. The trailing dot required when these names are stored 142 in a DNS zone is implicit and MUST NOT be provided when exchanging 143 host and domain names. 145 2.2 Contact and Client Identifiers 147 All EPP contacts are identified by a server-unique identifier. 148 Contact identifiers are character strings with a specified minimum 149 length, a specified maximum length, and a specified format. Contact 150 identifiers use the "clIDType" client identifier syntax described in 151 [EPP]. 153 2.3 Status Values 155 A domain object MUST always have at least one associated status value. 156 Status values can be set only by the client that sponsors a domain 157 object and by the server on which the object resides. A client can 158 change the status of a domain object using the EPP command. 159 Each status value MAY be accompanied by a string of human-readable 160 text that describes the rationale for the status applied to the 161 object. 163 A client MUST NOT alter status values set by the server. A server MAY 164 alter or override status values set by a client subject to local 165 server policies. 167 Status values that can be added or removed by a client are prefixed 168 with "client". Corresponding status values that can be added or 169 removed by a server are prefixed with "server". Status values that do 170 not begin with either "client" or "server" are server-managed. 172 Status Value Descriptions: 174 clientDeleteProhibited, serverDeleteProhibited 176 Requests to delete the object MUST be rejected. 178 clientHold, serverHold 180 DNS delegation information MUST NOT be published for the object. 182 clientRenewProhibited, serverRenewProhibited 184 Requests to renew the object MUST be rejected. 186 clientTransferProhibited, serverTransferProhibited 188 Requests to transfer the object MUST be rejected. 190 clientUpdateProhibited, serverUpdateProhibited 192 Requests to update the object (other than to remove this status) MUST 193 be rejected. 195 inactive 197 Delegation information has not been associated with the object. 199 ok 201 This is the nominal status value for an object that has no pending 202 operations or prohibitions. 204 pendingDelete 206 A delete request has been received for the object, but the object has 207 not yet been purged from the server database. 209 pendingTransfer 211 A transfer request has been received for the object, and completion of 212 the request is pending. Transform commands other than MUST 213 be rejected while an object is in this state. 215 pendingVerification 217 A create request has been received for the object, and completion of 218 the request is pending. 220 "ok" status MUST NOT be combined with any other status. 221 "pendingDelete" status MUST NOT be combined with either 222 "clientDeleteProhibited" or "serverDeleteProhibited" status. 223 "pendingTransfer" status MUST NOT be combined with either 224 "clientTransferProhibited" or "serverTransferProhibited" status. All 225 other status value combinations are valid. 227 2.4 Dates and Times 229 Date and time attribute values MUST be represented in Universal 230 Coordinated Time (UTC) using the Gregorian calendar. The extended 231 date-time form defined in [DATE-TIME] MUST be used to represent date- 232 time values as XML Schema does not support truncated date-time forms. 234 2.5 Validity Periods 236 A domain name object MAY have a specified validity period. If server 237 policy supports domain object validity periods, the validity period is 238 defined when a domain object is created, and it MAY be extended by the 239 EPP or commands. As a matter of server policy, 240 this specification does not define actions to be taken upon expiration 241 of a domain object's validity period. 243 Validity periods are measured in years or months with the appropriate 244 units specified using the "unit" attribute. Valid values for the 245 "unit" attribute are "y" for years and "m" for months. The minimum 246 allowable period value is one decimal (1). The maximum allowable 247 value is ninety-nine decimal (99). A server MAY support a lower 248 maximum value. 250 2.6 Authorization Information 252 Authorization information is associated with domain objects to 253 facilitate transfer operations. Authorization information is assigned 254 when a domain object is created, and it might be updated in the 255 future. This specification describes password-based authorization 256 information, though other mechanisms are possible. 258 3. EPP Command Mapping 260 A detailed description of the EPP syntax and semantics can be found in 261 [EPP]. The command mappings described here are specifically for use 262 in provisioning and managing Internet domain names via EPP. 264 3.1 EPP Query Commands 266 EPP provides three commands to retrieve domain information: to 267 determine if a domain object can be provisioned within a repository, 268 to retrieve detailed information associated with a domain 269 object, and to retrieve domain object transfer status 270 information. 272 3.1.1 EPP Command 274 The EPP command is used to determine if an object can be 275 provisioned within a repository. It provides a hint that allows a 276 client to anticipate the success or failure of provisioning an object 277 using the command. Object availability and provisioning 278 conditions are a matter of server policy. 280 In addition to the standard EPP command elements, the command 281 MUST contain a element that identifies the domain 282 namespace and the location of the domain schema. The 283 element contains the following child elements: 285 - One or more elements that contain the fully qualified 286 names of the domain objects to be queried. 288 Example command: 290 C: 291 C: 295 C: 296 C: 297 C: 301 C: example1.tld 302 C: example2.tld 303 C: example3.tld 304 C: 305 C: 306 C: ABC-12345 307 C: 308 C: 310 When a command has been processed successfully, the EPP 311 element MUST contain a child element that 312 identifies the domain namespace and the location of the domain schema. 313 The element contains one or more elements 314 that contain the following child elements: 316 - A element that contains the fully qualified name of 317 the queried domain object. This element MUST contain an "avail" 318 attribute whose value indicates object availability at the moment the 319 command was completed. A value of "1" or "true" means that 320 the object is available. A value of "0" or "false" means that the 321 object is not available. 323 - An OPTIONAL element that MAY be provided when an 324 object is not available for provisioning. If present, this element 325 contains server-specific text to help explain why the object is 326 unavailable. This text MUST be represented in the response language 327 previously negotiated with the client; an OPTIONAL "lang" attribute 328 MAY be present to identify the language if the negotiated value is 329 something other than the default value of "en" (English). 331 Example response: 333 S: 334 S: 338 S: 339 S: 340 S: Command completed successfully 341 S: 342 S: 343 S: 347 S: 348 S: example1.tld 349 S: 350 S: 351 S: example2.tld 352 S: In use 353 S: 354 S: 355 S: example3.tld 356 S: 357 S: 358 S: 359 S: 360 S: ABC-12345 361 S: 54322-XYZ 362 S: 363 S: 364 S: 366 An EPP error response MUST be returned if a command can not be 367 processed for any reason. 369 3.1.2 EPP Command 371 The EPP command is used to retrieve information associated with 372 a domain object. The response to this command MAY vary depending on 373 the identity of the querying client, use of authorization information, 374 and server policy towards unauthorized clients. If the querying 375 client is the sponsoring client, all available information MUST be 376 returned. If the querying client is not the sponsoring client, but 377 the client provides valid authorization information, all available 378 information MUST be returned. If the querying client is not the 379 sponsoring client, and the client does not provide valid authorization 380 information, server policy determines which OPTIONAL elements are 381 returned. 383 In addition to the standard EPP command elements, the command 384 MUST contain a element that identifies the domain 385 namespace and the location of the domain schema. The 386 element contains the following child elements: 388 - A element that contains the fully qualified name of 389 the domain object to be queried. An OPTIONAL "hosts" attribute is 390 available to control return of information describing hosts related to 391 the domain object. A value of "all" (the default, which MAY be 392 absent) returns information describing both subordinate and delegated 393 hosts. A value of "del" returns information describing only delegated 394 hosts. A value of "sub" returns information describing only 395 subordinate hosts. A value of "none" returns no information 396 describing delegated or subordinate hosts. 398 - An OPTIONAL element that contains authorization 399 information associated with the domain object or authorization 400 information associated with the domain object's registrant or 401 associated contacts. 403 Example command without authorization information: 405 C: 406 C: 410 C: 411 C: 412 C: 416 C: example.tld 417 C: 418 C: 419 C: ABC-12345 420 C: 421 C: 423 Example command with authorization information: 425 C: 426 C: 430 C: 431 C: 432 C: 436 C: example.tld 437 C: 2fooBAR 438 C: 439 C: 440 C: ABC-12345 441 C: 442 C: 444 When an command has been processed successfully, the EPP 445 element MUST contain a child element that 446 identifies the domain namespace and the location of the domain schema. 447 Elements that are not OPTIONAL MUST be returned; OPTIONAL elements are 448 returned based on client authorization and server policy. The 449 element contains the following child elements: 451 - A element that contains the fully qualified name of 452 the domain object. 454 - A element that contains the Repository Object 455 IDentifier assigned to the domain object when the object was created. 457 - One or more OPTIONAL elements that contain the 458 current status descriptors associated with the domain. 460 - If supported by the server, one OPTIONAL element 461 and one or more OPTIONAL elements that contain 462 identifiers for the human or organizational social information objects 463 associated with the domain object. 465 - Zero or more OPTIONAL elements that contain the fully 466 qualified names of the delegated host objects (name servers) 467 associated with the domain object. 469 - Zero or more OPTIONAL elements that contain the fully 470 qualified names of the subordinate host objects that exist under this 471 superordinate domain object. 473 - A element that contains the identifier of the 474 sponsoring client. 476 - An OPTIONAL element that contains the identifier of 477 the client that created the domain object. 479 - An OPTIONAL element that contains the date and time 480 of domain object creation. 482 - An OPTIONAL element that contains the date and time 483 identifying the end of the domain object's registration period. 485 - An OPTIONAL element that contains the identifier of 486 the client that last updated the domain object. This element MUST NOT 487 be present if the domain has never been modified. 489 - An OPTIONAL element that contains the date and time 490 of the most recent domain object modification. This element MUST NOT 491 be present if the domain object has never been modified. 493 - An OPTIONAL elements that contains the date and time 494 of the most recent successful domain object transfer. This element 495 MUST NOT be provided if the domain object has never been transferred. 497 - An OPTIONAL element that contains authorization 498 information associated with the domain object. This element MUST only 499 be returned if the querying client is the current sponsoring client, 500 or if the client supplied valid authorization information with the 501 command. 503 Example response for an authorized client: 505 S: 506 S: 510 S: 511 S: 512 S: Command completed successfully 513 S: 514 S: 515 S: 519 S: example.tld 520 S: EXAMPLE1-REP 521 S: 522 S: jd1234 523 S: sh8013 524 S: sh8013 525 S: ns1.example.tld 526 S: ns1.example2.tld 527 S: ns1.example.tld 528 S: ns2.example.tld 529 S: ClientX 530 S: ClientY 531 S: 1999-04-03T22:00:00.0Z 532 S: ClientX 533 S: 1999-12-03T09:00:00.0Z 534 S: 2005-04-03T22:00:00.0Z 535 S: 2000-04-08T09:00:00.0Z 536 S: 2fooBAR 537 S: 538 S: 539 S: 540 S: ABC-12345 541 S: 54322-XYZ 542 S: 543 S: 544 S: 546 A server with a different information return policy MAY provide less 547 information in a response. 549 Example response for an unauthorized client: 551 S: 552 S: 556 S: 557 S: 558 S: Command completed successfully 559 S: 560 S: 561 S: 565 S: example.tld 566 S: EXAMPLE1-REP 567 S: ClientX 568 S: 569 S: 570 S: 571 S: ABC-12345 572 S: 54322-XYZ 573 S: 574 S: 575 S: 577 An EPP error response MUST be returned if an command can not be 578 processed for any reason. 580 3.1.3 EPP Command 582 The EPP command provides a query operation that allows a 583 client to determine real-time status of pending and completed transfer 584 requests. In addition to the standard EPP command elements, the 585 command MUST contain an "op" attribute with value "query", 586 and a element that identifies the domain namespace 587 and the location of the domain schema. The element 588 contains the following child elements: 590 - A element that contains the fully qualified name of 591 the domain object to be queried. 593 - A element that contains authorization information 594 associated with the domain object or authorization information 595 associated with the domain object's registrant or associated contacts. 597 Example query command: 599 C: 600 C: 604 C: 605 C: 606 C: 610 C: example.tld 611 C: 2fooBAR 612 C: 613 C: 614 C: 615 C: ABC-12345 616 C: 617 C: 619 When a query command has been processed successfully, the 620 EPP element MUST contain a child element 621 that identifies the domain namespace and the location of the domain 622 schema. The element contains the following child 623 elements: 625 - A element that contains the fully qualified name of 626 the domain object. 628 - A element that contains the state of the most 629 recent transfer request. 631 - A element that contains the identifier of the client 632 that requested the object transfer. 634 - A element that contains the date and time that the 635 transfer was requested. 637 - A element that contains the identifier of the client 638 that SHOULD act upon the transfer request. 640 - A element that contains the date and time of a 641 required or completed response. For a PENDING request, the value 642 identifies the date and time by which a response is required before an 643 automated response action will be taken by the server. For all other 644 status types, the value identifies the date and time when the request 645 was completed. 647 - An OPTIONAL element that contains the end of the 648 domain object's validity period if the command caused or 649 causes a change in the validity period. 651 Example query response: 653 S: 654 S: 658 S: 659 S: 660 S: Command completed successfully 661 S: 662 S: 663 S: 667 S: example.tld 668 S: pending 669 S: ClientX 670 S: 2000-06-06T22:00:00.0Z 671 S: ClientY 672 S: 2000-06-11T22:00:00.0Z 673 S: 2002-09-08T22:00:00.0Z 674 S: 675 S: 676 S: 677 S: ABC-12345 678 S: 54322-XYZ 679 S: 680 S: 681 S: 683 An EPP error response MUST be returned if a query command 684 can not be processed for any reason. 686 3.2 EPP Transform Commands 688 EPP provides five commands to transform domain objects: to 689 create an instance of a domain object, to delete an instance 690 of a domain object, to extend the validity period of a domain 691 object, to manage domain object sponsorship changes, and 692 to change information associated with a domain object. 694 3.2.1 EPP Command 696 The EPP command provides a transform operation that allows a 697 client to create a domain object. In addition to the standard EPP 698 command elements, the command MUST contain a 699 element that identifies the domain namespace and the location of the 700 domain schema. The element contains the following 701 child elements: 703 - A element that contains the fully qualified name of 704 the domain object to be created. 706 - An OPTIONAL element that contains the initial 707 registration period of the domain object. A server MAY define a 708 default initial registration period if not specified by the client. 710 - Zero or more elements that contain the fully qualified 711 name of a known host object to provide resolution services for the 712 domain. A host object MUST be known to the server before the host 713 object can be associated with a domain object. A server MUST provide 714 host object services to provide domain name services. The EPP mapping 715 for host objects is described in [EPP-H]. 717 - An OPTIONAL element that contains the identifier 718 for the human or organizational social information (contact) object to 719 be associated with the domain object as the object registrant. This 720 object identifier MUST be known to the server before the contact 721 object can be associated with the domain object. The EPP mapping for 722 contact objects is described in [EPP-C]. 724 - Zero or more OPTIONAL elements that contain the 725 identifiers for other contact objects to be associated with the domain 726 object. Contact object identifiers MUST be known to the server before 727 the contact object can be associated with the domain object. 729 - A element that contains authorization information 730 to be associated with the domain object. 732 Example command: 734 C: 735 C: 739 C: 740 C: 741 C: 745 C: example.tld 746 C: 2 747 C: ns1.example.tld 748 C: ns1.example2.tld 749 C: jd1234 750 C: sh8013 751 C: sh8013 752 C: 2fooBAR 753 C: 754 C: 755 C: ABC-12345 756 C: 757 C: 759 When a command has been processed successfully, the EPP 760 element MUST contain a child element that 761 identifies the domain namespace and the location of the domain schema. 762 The element contains the following child elements: 764 - A element that contains the fully qualified name of 765 the domain object. 767 - A element that contains the date and time of domain 768 object creation. 770 - An OPTIONAL element that contains the date and time 771 identifying the end of the domain object's registration period. 773 Example response: 775 S: 776 S: 780 S: 781 S: 782 S: Command completed successfully 783 S: 784 S: 785 S: 789 S: example.tld 790 S: 1999-04-03T22:00:00.0Z 791 S: 2001-04-03T22:00:00.0Z 792 S: 793 S: 794 S: 795 S: ABC-12345 796 S: 54321-XYZ 797 S: 798 S: 799 S: 801 An EPP error response MUST be returned if a command can not 802 be processed for any reason. 804 3.2.2 EPP Command 806 The EPP command provides a transform operation that allows a 807 client to delete a domain object. In addition to the standard EPP 808 command elements, the command MUST contain a 809 element that identifies the domain namespace and the location of the 810 domain schema. The element contains the following 811 child elements: 813 - A element that contains the fully qualified name of 814 the domain object to be deleted. 816 A domain object SHOULD NOT be deleted if subordinate host objects are 817 associated with the domain object. For example, if domain 818 "example.tld" exists, and host object "ns1.example.tld" also exists, 819 then domain "example.tld" SHOULD NOT be deleted until host 820 "ns1.example.tld" has been either deleted or renamed to exist in a 821 different superordinate domain. A server SHOULD notify clients of 822 object relationships when a command is attempted and fails 823 due to existing object relationships. 825 Example command: 827 C: 828 C: 832 C: 833 C: 834 C: 838 C: example.tld 839 C: 840 C: 841 C: ABC-12345 842 C: 843 C: 845 When a command has been processed successfully, a server MUST 846 respond with an EPP response with no element. 848 Example response: 850 S: 851 S: 855 S: 856 S: 857 S: Command completed successfully 858 S: 859 S: 860 S: ABC-12345 861 S: 54321-XYZ 862 S: 863 S: 864 S: 866 An EPP error response MUST be returned if a command can not 867 be processed for any reason. 869 3.2.3 EPP Command 871 The EPP command provides a transform operation that allows a 872 client to extend the validity period of a domain object. In addition 873 to the standard EPP command elements, the command MUST contain 874 a element that identifies the domain namespace and the 875 location of the domain schema. The element contains 876 the following child elements: 878 - A element that contains the fully qualified name of 879 the domain object whose validity period is to be extended. 881 - A element that contains the date on which the 882 current validity period ends. This value ensures that repeated 883 commands do not result in multiple unanticipated successful 884 renewals. 886 - An OPTIONAL element that contains the number of 887 units to be added to the registration period of the domain object. 888 The number of units available MAY be subject to limits imposed by the 889 server. 891 Example command: 893 C: 894 C: 898 C: 899 C: 900 C: 904 C: example.tld 905 C: 2000-04-03 906 C: 5 907 C: 908 C: 909 C: ABC-12345 910 C: 911 C: 913 When a command has been processed successfully, the EPP 914 element MUST contain a child element that 915 identifies the domain namespace and the location of the domain schema. 916 The element contains the following child elements: 918 - A element that contains the fully qualified name of 919 the domain object. 921 - An OPTIONAL element that contains the date and time 922 identifying the end of the domain object's registration period. 924 Example response: 926 S: 927 S: 931 S: 932 S: 933 S: Command completed successfully 934 S: 935 S: 936 S: 940 S: example.tld 941 S: 2005-04-03T22:00:00.0Z 942 S: 943 S: 944 S: 945 S: ABC-12345 946 S: 54322-XYZ 947 S: 948 S: 949 S: 951 An EPP error response MUST be returned if a command can not be 952 processed for any reason. 954 3.2.4 EPP Command 956 The EPP command provides a transform operation that allows 957 a client to manage requests to transfer the sponsorship of a domain 958 object. In addition to the standard EPP command elements, the 959 command MUST contain a element that 960 identifies the domain namespace and the location of the domain schema. 961 The element contains the following child elements: 963 - A element that contains the fully qualified name of 964 the domain object for which a transfer request is to be created, 965 approved, rejected, or cancelled. 967 - An OPTIONAL element that contains the number of 968 units to be added to the registration period of the domain object at 969 completion of the transfer process. This element can only be used 970 when a transfer is requested, and it MUST be ignored if used 971 otherwise. The number of units available MAY be subject to limits 972 imposed by the server. 974 - A element that contains authorization information 975 associated with the domain object or authorization information 976 associated with the domain object's registrant or associated contacts. 978 Every EPP command MUST contain an "op" attribute that 979 identifies the transfer operation to be performed. Valid values, 980 definitions, and authorizations for all attribute values are defined 981 in [EPP]. 983 Transfer of a domain object MUST implicitly transfer all host objects 984 that are subordinate to the domain object. For example, if domain 985 object "example.tld" is transferred and host object "ns1.example.tld" 986 exists, the host object MUST be transferred as part of the 987 "example.tld" transfer process. Host objects that are subject to 988 transfer when transferring a domain object are listed in the response 989 to an EPP command performed on the domain object. 991 DNS domains can be delegated to external hosts. If a domain has been 992 delegated to an external host, a client MUST have created a host 993 object for each delegation to an external host before requesting a 994 domain transfer. A transfer request or approval MUST fail with EPP 995 error code 2305 if host objects representing the external hosts are 996 not managed by the requesting client at the time a transfer request is 997 made and at the time the transfer request is approved. 999 Example request command: 1001 C: 1002 C: 1006 C: 1007 C: 1008 C: 1012 C: example.tld 1013 C: 1 1014 C: 2fooBAR 1015 C: 1016 C: 1017 C: 1018 C: ABC-12345 1019 C: 1020 C: 1022 When a command has been processed successfully, the EPP 1023 element MUST contain a child element that 1024 identifies the domain namespace and the location of the domain schema. 1025 The element contains the same child elements defined 1026 for a transfer query response. 1028 Example response: 1030 S: 1031 S: 1035 S: 1036 S: 1037 S: Command completed successfully 1038 S: 1039 S: 1040 S: 1044 S: example.tld 1045 S: pending 1046 S: ClientX 1047 S: 2000-06-08T22:00:00.0Z 1048 S: ClientY 1049 S: 2000-06-13T22:00:00.0Z 1050 S: 2002-09-08T22:00:00.0Z 1051 S: 1052 S: 1053 S: 1054 S: ABC-12345 1055 S: 54322-XYZ 1056 S: 1057 S: 1058 S: 1060 An EPP error response MUST be returned if a command can not 1061 be processed for any reason. 1063 3.2.5 EPP Command 1065 The EPP command provides a transform operation that allows a 1066 client to modify the attributes of a domain object. In addition to 1067 the standard EPP command elements, the command MUST contain a 1068 element that identifies the domain namespace and the 1069 location of the domain schema. The element contains 1070 the following child elements: 1072 - A element that contains the fully qualified name of 1073 the domain object to be updated. 1075 - An OPTIONAL element that contains attribute values to 1076 be added to the object. 1078 - An OPTIONAL element that contains attribute values to 1079 be removed from the object. 1081 - An OPTIONAL element that contains object attribute 1082 values to be changed. 1084 At least one , , or element MUST 1085 be provided. The and elements contain the 1086 following child elements: 1088 - Zero or more elements that contain the fully qualified 1089 name of a known name server host object. A host object MUST be known 1090 to the server before a name server attribute can be added or removed 1091 from a domain object. The EPP mapping for host objects is described 1092 in [EPP-H]. 1094 - Zero or more elements that contain the identifiers 1095 for contact objects to be associated with or removed from the domain 1096 object. Contact object identifiers MUST be known to the server before 1097 the contact object can be associated with the domain object. 1099 - Zero or more elements that contain status values to 1100 be applied to or removed from the object. When specifying a value to 1101 be removed, only the attribute value is significant; element text is 1102 not required to match a value for removal. 1104 A element contains the following child elements: 1106 - A element that contains the identifier for the 1107 human or organizational social information (contact) object to be 1108 associated with the domain object as the object registrant. This 1109 object identifier MUST be known to the server before the contact 1110 object can be associated with the domain object. 1112 - A element that contains authorization information 1113 associated with the domain object. 1115 Example command: 1117 C: 1118 C: 1122 C: 1123 C: 1124 C: 1128 C: example.tld 1129 C: 1130 C: ns2.example2.tld 1131 C: mak21 1132 C: Payment overdue. 1133 C: 1134 C: 1135 C: 1136 C: ns1.example2.tld 1137 C: sh8013 1138 C: 1139 C: 1140 C: 1141 C: sh8013 1142 C: 2BARfoo 1143 C: 1144 C: 1145 C: 1146 C: ABC-12345 1147 C: 1148 C: 1150 When an command has been processed successfully, a server 1151 MUST respond with an EPP response with no element. 1153 Example response: 1155 S: 1156 S: 1160 S: 1161 S: 1162 S: Command completed successfully 1163 S: 1164 S: 1165 S: ABC-12345 1166 S: 54321-XYZ 1167 S: 1168 S: 1169 S: 1171 An EPP error response MUST be returned if an command can not 1172 be processed for any reason. 1174 4. Formal Syntax 1176 An EPP object mapping is specified in XML Schema notation. The formal 1177 syntax presented here is a complete schema representation of the 1178 object mapping suitable for automated validation of EPP XML instances. 1179 The BEGIN and END tags are not part of the schema; they are used to 1180 note the beginning and ending of the schema for URI registration 1181 purposes. 1183 BEGIN 1184 1186 1193 1196 1198 1201 1202 1203 Extensible Provisioning Protocol v1.0 1204 domain provisioning schema. 1205 1206 1208 1211 1212 1213 1214 1215 1216 1217 1219 1222 1223 1224 1225 1227 1229 1231 1233 1234 1235 1237 1238 1239 1240 1242 1243 1244 1246 1247 1248 1249 1250 1251 1253 1254 1255 1256 1257 1258 1260 1261 1262 1263 1264 1265 1266 1268 1269 1270 1271 1272 1273 1274 1276 1279 1280 1281 1282 1283 1285 1288 1289 1290 1292 1293 1295 1298 1299 1300 1301 1303 1304 1306 1307 1308 1309 1311 1312 1313 1315 1316 1317 1318 1319 1320 1321 1322 1324 1327 1328 1329 1330 1331 1333 1334 1336 1339 1340 1341 1342 1344 1345 1346 1348 1351 1352 1353 1354 1356 1358 1360 1361 1363 1366 1367 1368 1370 1372 1374 1375 1377 1380 1381 1382 1384 1386 1387 1389 1392 1393 1394 1395 1396 1398 1401 1402 1403 1405 1406 1408 1409 1410 1411 1413 1415 1417 1418 1419 1420 1422 1423 1424 1426 1429 1430 1431 1432 1433 1435 1436 1438 1441 1442 1443 1444 1445 1447 1449 1451 1453 1455 1456 1458 1460 1462 1464 1466 1468 1470 1471 1473 1477 1478 1479 1480 1482 1484 1485 1486 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1508 1511 1512 1513 1514 1516 1517 1519 1522 1523 1524 1525 1526 1527 1528 1529 1530 1532 1533 1535 1538 1539 END 1541 5. Internationalization Considerations 1543 EPP is represented in XML, which provides native support for encoding 1544 information using the Unicode character set and its more compact 1545 representations including UTF-8. Compliant XML processors are 1546 REQUIRED to understand both UTF-8 and UTF-16. Though XML includes 1547 provisions to identify other character set encodings through use of an 1548 "encoding" attribute in an declaration, EPP use with character 1549 sets other than UTF-8 is NOT RECOMMENDED. 1551 All date-time values presented via EPP MUST be expressed in Universal 1552 Coordinated Time using the Gregorian calendar. XML Schema allows use 1553 of time zone identifiers to indicate offsets from the zero meridian, 1554 but this option MUST NOT be used with EPP. The extended date-time 1555 form defined in [DATE-TIME] MUST be used to represent date-time values 1556 as XML Schema does not support truncated date-time forms. 1558 This document requires domain and host name syntax as specified in 1559 [RFC952] as updated by [RFC1123]. These conformance requirements 1560 might change as a result of progressing work in developing standards 1561 for internationalized domain names. 1563 6. IANA Considerations 1565 This document uses URNs to describe XML namespaces and XML schemas 1566 conforming to a registry mechanism described in [IETF-XML]. Two URI 1567 assignments are requested. 1569 Registration request for the domain namespace: 1571 URI: urn:ietf:params:xml:ns:domain-1.0 1573 Registrant Contact: See the "Author's Address" section of this 1574 document. 1576 XML: None. Namespace URIs do not represent an XML specification. 1578 Registration request for the domain XML schema: 1580 URI: urn:ietf:params:xml:schema:domain-1.0 1582 Registrant Contact: See the "Author's Address" section of this 1583 document. 1585 XML: See the "Formal Syntax" section of this document. 1587 7. Security Considerations 1589 An authorization token is REQUIRED to create a domain object. This 1590 token is used in some query and transfer operations as an additional 1591 means of determining client authorization to perform the command. 1592 Failure to protect authorization tokens can result in unauthorized 1593 transfer operations and unauthorized information disclosure. Both 1594 client and server MUST ensure that tokens are stored and exchanged 1595 with high-grade encryption mechanisms to provide privacy services. 1597 The object mapping described in this document does not provide any 1598 other security services or introduce any additional considerations 1599 beyond those described by [EPP] and protocol layers used by EPP. 1601 8. Acknowledgements 1603 This document was originally written as an individual submission 1604 Internet-Draft. The provreg working group later adopted it as a 1605 working group document and provided many invaluable comments and 1606 suggested improvements. The author wishes to acknowledge the efforts 1607 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1608 editorial contributions. 1610 Specific suggestions that have been incorporated into this document 1611 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1612 Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer El-Showk, Klaus 1613 Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, Asbjorn Steira, 1614 Bruce Tonkin, and Rick Wesson. 1616 9. References 1618 Normative References: 1620 [DATE-TIME] G. Klyne, C. Newman: "Date and Time on the Internet: 1621 Timestamps", work in progress. 1623 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 1624 progress. 1626 [EPP-C] S. Hollenbeck: "Extensible Provisioning Protocol Contact 1627 Mapping", work in progress. 1629 [EPP-H] S. Hollenbeck: "Extensible Provisioning Protocol Host 1630 Mapping", work in progress. 1632 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 1634 [RFC952] K. Harrenstien et al.: "DOD Internet Host Table 1635 Specification", RFC 952, October 1985. 1637 [RFC1123] R. Braden: "Requirements for Internet Hosts -- Application 1638 and Support", RFC 1123, October 1989. 1640 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 1641 Requirement Levels", BCP 14, RFC 2119, March 1997. 1643 Informative References: 1645 [XML] Editors T. Bray et al.: "Extensible Markup Language (XML) 1.0 1646 (Second Edition)", W3C Recommendation 6 October 2000. 1648 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 1649 W3C Recommendation 2 May 2001. 1651 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 1652 Datatypes", W3C Recommendation 2 May 2001. 1654 10. Author's Address 1656 Scott Hollenbeck 1657 VeriSign Global Registry Services 1658 21345 Ridgetop Circle 1659 Dulles, VA 20166-6503 1660 USA 1661 shollenbeck@verisign.com 1663 A. Revisions From Previous Version 1665 (Note to RFC editor: please remove this section completely before 1666 publication as an RFC.) 1668 -03 to -04 (WG last call updates): 1670 Fixed typos. 1672 Added section 1.1 to the Introduction to explain the "external" host 1673 concept and the relationship to domain objects. 1675 Fixed and response descriptions to note that the 1676 element is (and has been) OPTIONAL per the schema. 1678 Added text to section 2.1 to note that the trailing dot required in 1679 zones is implicit. 1681 Minor text change in section 2.3 to avoid use of the term "zone" when 1682 describing clientHold and serverHold status. 1684 Fixed schema to prevent multiple choices in updates, replacing 1685 with . 1687 Made mandatory for transfer queries. Added optional 1688 to the command. 1690 Added a sentence to section 3.2.2 to encourage server implementers to 1691 notify clients when a delete command fails due to existing object 1692 relationships. 1694 Added text to section 3.2.4 to note the relationship between external 1695 hosts and commands. 1697 Changed some lower-case "must"s, "may"s, etc. to avoid confusion with 1698 RFC 2119 directives. 1700 Updated the security considerations section to note the need to 1701 protect authorization tokens. 1703 Separated references into normative and informative subsections. 1705 Replaced reference to ISO 8601 with an IMPP I-D that will hopefully be 1706 an RFC soon. 1708 B. Full Copyright Statement 1710 Copyright (C) The Internet Society 2002. All Rights Reserved. 1712 This document and translations of it may be copied and furnished to 1713 others, and derivative works that comment on or otherwise explain it 1714 or assist in its implementation may be prepared, copied, published and 1715 distributed, in whole or in part, without restriction of any kind, 1716 provided that the above copyright notice and this paragraph are 1717 included on all such copies and derivative works. However, this 1718 document itself may not be modified in any way, such as by removing 1719 the copyright notice or references to the Internet Society or other 1720 Internet organizations, except as needed for the purpose of developing 1721 Internet standards in which case the procedures for copyrights defined 1722 in the Internet Standards process must be followed, or as required to 1723 translate it into languages other than English. 1725 The limited permissions granted above are perpetual and will not be 1726 revoked by the Internet Society or its successors or assigns. 1728 This document and the information contained herein is provided on an 1729 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1730 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1731 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1732 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1733 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1735 Acknowledgement 1737 Funding for the RFC Editor function is currently provided by the 1738 Internet Society.