idnits 2.17.1 draft-hollenbeck-epp-rfc3731bis-05.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2052. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 17, 2006) is 6370 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) == Outdated reference: A later version (-06) exists of draft-hollenbeck-epp-rfc3733bis-05 ** Downref: Normative reference to an Unknown state RFC: RFC 952 -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3731 (Obsoleted by RFC 4931) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 Obsoletes: 3731 (if approved) November 17, 2006 5 Intended status: Standards Track 6 Expires: May 21, 2007 8 Extensible Provisioning Protocol (EPP) Domain Name Mapping 9 draft-hollenbeck-epp-rfc3731bis-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2006). 40 Abstract 42 This document describes an Extensible Provisioning Protocol (EPP) 43 mapping for the provisioning and management of Internet domain names 44 stored in a shared central repository. Specified in XML, the mapping 45 defines EPP command syntax and semantics as applied to domain names. 46 This document obsoletes RFC 3731 if approved. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Relationship of Domain Objects and Host Objects . . . . . 3 52 1.2. Conventions Used In This Document . . . . . . . . . . . . 5 53 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. Domain and Host Names . . . . . . . . . . . . . . . . . . 5 55 2.2. Contact and Client Identifiers . . . . . . . . . . . . . . 6 56 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 6 57 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 8 58 2.5. Validity Periods . . . . . . . . . . . . . . . . . . . . . 8 59 2.6. Authorization Information . . . . . . . . . . . . . . . . 8 60 2.7. Other DNS Resource Record Attributes . . . . . . . . . . . 8 61 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9 63 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 9 64 3.1.2. EPP Command . . . . . . . . . . . . . . . . . . 11 65 3.1.3. EPP Query Command . . . . . . . . . . . . . 16 66 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 18 67 3.2.1. EPP Command . . . . . . . . . . . . . . . . . 19 68 3.2.2. EPP Command . . . . . . . . . . . . . . . . . 21 69 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 22 70 3.2.4. EPP Command . . . . . . . . . . . . . . . . 24 71 3.2.5. EPP Command . . . . . . . . . . . . . . . . . 26 72 3.3. Offline Review of Requested Actions . . . . . . . . . . . 29 73 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31 74 5. Internationalization Considerations . . . . . . . . . . . . . 41 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 42 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 43 81 Appendix A. Changes from RFC 3731 . . . . . . . . . . . . . . . . 44 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 83 Intellectual Property and Copyright Statements . . . . . . . . . . 46 85 1. Introduction 87 This document describes an Internet domain name mapping for version 88 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is 89 specified using the Extensible Markup Language (XML) 1.0 as described 90 in [W3C.REC-xml-20040204] and XML Schema notation as described in 91 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 92 This document obsoletes RFC 3731 [RFC3731] if approved. 94 [I-D.hollenbeck-epp-rfc3730bis] provides a complete description of 95 EPP command and response structures. A thorough understanding of the 96 base protocol specification is necessary to understand the mapping 97 described in this document. 99 XML is case sensitive. Unless stated otherwise, XML specifications 100 and examples provided in this document MUST be interpreted in the 101 character case presented to develop a conforming implementation. 103 1.1. Relationship of Domain Objects and Host Objects 105 The EPP mapping for host objects is described in 106 [I-D.hollenbeck-epp-rfc3732bis]. This document assumes that domain 107 name objects have a superordinate relationship to subordinate host 108 name objects. For example, domain name "example.com" has a 109 superordinate relationship to host name "ns1.example.com". EPP 110 actions (such as object transfers) that do not preserve this 111 relationship MUST be explicitly disallowed. 113 A host name object can be created in a repository for which no 114 superordinate domain name object exists. For example, host name 115 "ns1.example.com" can be created in the ".example" repository so that 116 DNS domains in ".example" can be delegated to the host. Such hosts 117 are described as "external" hosts in this specification since the 118 name of the host does not belong to the name space of the repository 119 in which the host is being used for delegation purposes. 121 Whether a host is external or internal relates to the repository in 122 which the host is being used for delegation purposes. Whether an 123 internal host is subordinate or not relates to a domain within the 124 repository. For example, host ns1.example1.com is a subordinate host 125 of domain example1.com, but it is a not a subordinate host of domain 126 example2.com. ns1.example1.com can be used as a name server for 127 example2.com. In this case, ns1.example1.com MUST be treated as an 128 internal host, subject to the rules governing operations on 129 subordinate hosts within the same repository. 131 Name server hosts for domain delegation can be specified as either 132 references to existing host objects or as domain attributes that 133 describe a host machine. A server operator MUST use one name server 134 specification form consistently. A server operator that announces 135 support for host objects in an EPP greeting MUST NOT allow domain 136 attributes to describe a name server host machine. A server operator 137 that does not announce support for host objects MUST allow domain 138 attributes to describe a name server host machine. When domain 139 attributes are used to describe a name server host machine, IP 140 addresses SHOULD be required only as needed to generate DNS glue 141 records. 143 Name servers are specified within a element. This 144 element MUST contain one or more elements or one or 145 more elements. A element contains 146 the fully qualified name of a known name server host object. A 147 element contains the following child elements: 149 - A element that contains the fully qualified name 150 of a host. 152 - Zero or more OPTIONAL elements that contain the 153 IP addresses to be associated with the host. Each element MAY 154 contain an "ip" attribute to identify the IP address format. 155 Attribute value "v4" is used to note IPv4 address format. 156 Attribute value "v6" is used to note IPv6 address format. If the 157 "ip" attribute is not specified, "v4" is the default attribute 158 value. IP address syntax requirements are described in Section 159 2.5 of the EPP host mapping [I-D.hollenbeck-epp-rfc3732bis]. 161 Example host object name server elements for domain example.com: 163 164 ns1.example.com 165 ns1.example.net 166 167 Example host attribute name server elements for domain example.com: 169 170 171 ns1.example.com 172 192.0.2.2 174 1080:0:0:0:8:800:200C:417A 176 177 178 ns1.example.net 179 180 182 1.2. Conventions Used In This Document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 In examples, "C:" represents lines sent by a protocol client and "S:" 189 represents lines returned by a protocol server. Indentation and 190 white space in examples is provided only to illustrate element 191 relationships and is not a REQUIRED feature of this protocol. 193 2. Object Attributes 195 An EPP domain object has attributes and associated values that can be 196 viewed and modified by the sponsoring client or the server. This 197 section describes each attribute type in detail. The formal syntax 198 for the attribute values described here can be found in the "Formal 199 Syntax" section of this document and in the appropriate normative 200 references. 202 2.1. Domain and Host Names 204 The syntax for domain and host names described in this document MUST 205 conform to [RFC0952] as updated by [RFC1123]. At the time of this 206 writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII 207 name labels to represent non-ASCII name labels. These conformance 208 requirements might change as a result of progressing work in 209 developing standards for internationalized domain names. A server 210 MAY restrict allowable domain names to a particular top level domain, 211 second level domain, or other domain for which the server is 212 authoritative. The trailing dot required when these names are stored 213 in a DNS zone is implicit and MUST NOT be provided when exchanging 214 host and domain names. 216 2.2. Contact and Client Identifiers 218 All EPP contacts are identified by a server-unique identifier. 219 Contact identifiers are character strings with a specified minimum 220 length, a specified maximum length, and a specified format. Contact 221 identifiers use the "clIDType" client identifier syntax described in 222 [I-D.hollenbeck-epp-rfc3730bis]. 224 2.3. Status Values 226 A domain object MUST always have at least one associated status 227 value. Status values can be set only by the client that sponsors a 228 domain object and by the server on which the object resides. A 229 client can change the status of a domain object using the EPP 230 command. Each status value MAY be accompanied by a string 231 of human-readable text that describes the rationale for the status 232 applied to the object. 234 A client MUST NOT alter status values set by the server. A server 235 MAY alter or override status values set by a client subject to local 236 server policies. The status of an object MAY change as a result of 237 either a client-initiated transform command or an action performed by 238 a server operator. 240 Status values that can be added or removed by a client are prefixed 241 with "client". Corresponding status values that can be added or 242 removed by a server are prefixed with "server". Status values that 243 do not begin with either "client" or "server" are server-managed. 245 Status Value Descriptions: 247 - clientDeleteProhibited, serverDeleteProhibited 249 Requests to delete the object MUST be rejected. 251 - clientHold, serverHold 253 DNS delegation information MUST NOT be published for the object. 255 - clientRenewProhibited, serverRenewProhibited 257 Requests to renew the object MUST be rejected. 259 - clientTransferProhibited, serverTransferProhibited 261 Requests to transfer the object MUST be rejected. 263 - clientUpdateProhibited, serverUpdateProhibited 265 Requests to update the object (other than to remove this status) 266 MUST be rejected. 268 - inactive 270 Delegation information has not been associated with the object. 272 - ok 274 This is the normal status value for an object that has no pending 275 operations or prohibitions. This value is set and removed by the 276 server as other status values are added or removed. 278 - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, 279 pendingUpdate 281 A transform command has been processed for the object, but the 282 action has not been completed by the server. Server operators can 283 delay action completion for a variety of reasons, such as to allow 284 for human review or third-party action. A transform command that 285 is processed, but whose requested action is pending, is noted with 286 response code 1001. 288 When the requested action has been completed, the pendingCreate, 289 pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status 290 value MUST be removed. All clients involved in the transaction MUST 291 be notified using a service message that the action has been 292 completed and that the status of the object has changed. 294 "ok" status MUST NOT be combined with any other status. 296 "pendingDelete" status MUST NOT be combined with either 297 "clientDeleteProhibited" or "serverDeleteProhibited" status. 299 "pendingRenew" status MUST NOT be combined with either 300 "clientRenewProhibited" or "serverRenewProhibited" status. 302 "pendingTransfer" status MUST NOT be combined with either 303 "clientTransferProhibited" or "serverTransferProhibited" status. 305 "pendingUpdate" status MUST NOT be combined with either 306 "clientUpdateProhibited" or "serverUpdateProhibited" status. 308 The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and 309 pendingUpdate status values MUST NOT be combined with each other. 311 Other status combinations not expressly prohibited MAY be used. 313 2.4. Dates and Times 315 Date and time attribute values MUST be represented in Universal 316 Coordinated Time (UTC) using the Gregorian calendar. The extended 317 date-time form using upper case "T" and "Z" characters defined in 318 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 319 values as XML Schema does not support truncated date-time forms or 320 lower case "T" and "Z" characters. 322 2.5. Validity Periods 324 A domain name object MAY have a specified validity period. If server 325 policy supports domain object validity periods, the validity period 326 is defined when a domain object is created, and it MAY be extended by 327 the EPP or commands. As a matter of server 328 policy, this specification does not define actions to be taken upon 329 expiration of a domain object's validity period. 331 Validity periods are measured in years or months with the appropriate 332 units specified using the "unit" attribute. Valid values for the 333 "unit" attribute are "y" for years and "m" for months. The minimum 334 allowable period value is one decimal (1). The maximum allowable 335 value is ninety-nine decimal (99). A server MAY support a lower 336 maximum value. 338 2.6. Authorization Information 340 Authorization information is associated with domain objects to 341 facilitate transfer operations. Authorization information is 342 assigned when a domain object is created, and it might be updated in 343 the future. This specification describes password-based 344 authorization information, though other mechanisms are possible. 346 2.7. Other DNS Resource Record Attributes 348 While the DNS allows many resource record types to be associated with 349 a domain, this mapping only explicitly specifies elements that 350 describe resource records used for domain delegation and resolution. 351 Facilities to provision other domain-related resource record types 352 can be developed by extending this mapping. 354 The provisioning method described in this mapping separates discrete 355 data elements by data type. This method of data definition allows 356 XML Schema processors to perform basic syntax validation tasks, 357 reducing ambiguity and the amount of parsing and syntax-checking work 358 required of protocol processors. Provisioning and extension methods 359 that aggregate data into opaque strings are possible, but such 360 methods SHOULD NOT be used because they impose additional parsing, 361 interpretation, and validation requirements on protocol processors. 363 3. EPP Command Mapping 365 A detailed description of the EPP syntax and semantics can be found 366 in [I-D.hollenbeck-epp-rfc3730bis]. The command mappings described 367 here are specifically for use in provisioning and managing Internet 368 domain names via EPP. 370 3.1. EPP Query Commands 372 EPP provides three commands to retrieve domain information: 373 to determine if a domain object can be provisioned within a 374 repository, to retrieve detailed information associated with a 375 domain object, and to retrieve domain object transfer 376 status information. 378 3.1.1. EPP Command 380 The EPP command is used to determine if an object can be 381 provisioned within a repository. It provides a hint that allows a 382 client to anticipate the success or failure of provisioning an object 383 using the command as object provisioning requirements are 384 ultimately a matter of server policy. 386 In addition to the standard EPP command elements, the command 387 MUST contain a element that identifies the domain 388 namespace. The element contains the following child 389 elements: 391 - One or more elements that contain the fully 392 qualified names of the domain objects to be queried. 394 Example command: 396 C: 397 C: 398 C: 399 C: 400 C: 402 C: example.com 403 C: example.net 404 C: example.org 405 C: 406 C: 407 C: ABC-12345 408 C: 409 C: 411 When a command has been processed successfully, the EPP 412 element MUST contain a child element that 413 identifies the domain namespace. The element 414 contains one or more elements that contain the following 415 child elements: 417 - A element that contains the fully qualified name of 418 the queried domain object. This element MUST contain an "avail" 419 attribute whose value indicates object availability (can it be 420 provisioned or not) at the moment the command was 421 completed. A value of "1" or "true" means that the object can be 422 provisioned. A value of "0" or "false" means that the object can 423 not be provisioned. 425 - An OPTIONAL element that MAY be provided when an 426 object can not be provisioned. If present, this element contains 427 server-specific text to help explain why the object can not be 428 provisioned. This text MUST be represented in the response 429 language previously negotiated with the client; an OPTIONAL "lang" 430 attribute MAY be present to identify the language if the 431 negotiated value is something other than the default value of "en" 432 (English). 434 Example response: 436 S: 437 S: 438 S: 439 S: 440 S: Command completed successfully 441 S: 442 S: 443 S: 445 S: 446 S: example.com 447 S: 448 S: 449 S: example.net 450 S: In use 451 S: 452 S: 453 S: example.org 454 S: 455 S: 456 S: 457 S: 458 S: ABC-12345 459 S: 54322-XYZ 460 S: 461 S: 462 S: 464 An EPP error response MUST be returned if a command can not 465 be processed for any reason. 467 3.1.2. EPP Command 469 The EPP command is used to retrieve information associated 470 with a domain object. The response to this command MAY vary 471 depending on the identity of the querying client, use of 472 authorization information, and server policy towards unauthorized 473 clients. If the querying client is the sponsoring client, all 474 available information MUST be returned. If the querying client is 475 not the sponsoring client, but the client provides valid 476 authorization information, all available information MUST be 477 returned. If the querying client is not the sponsoring client, and 478 the client does not provide valid authorization information, server 479 policy determines which OPTIONAL elements are returned. 481 In addition to the standard EPP command elements, the command 482 MUST contain a element that identifies the domain 483 namespace. The element contains the following child 484 elements: 486 - A element that contains the fully qualified name of 487 the domain object to be queried. An OPTIONAL "hosts" attribute is 488 available to control return of information describing hosts 489 related to the domain object. A value of "all" (the default, 490 which MAY be absent) returns information describing both 491 subordinate and delegated hosts. A value of "del" returns 492 information describing only delegated hosts. A value of "sub" 493 returns information describing only subordinate hosts. A value of 494 "none" returns no information describing delegated or subordinate 495 hosts. 497 - An OPTIONAL element that contains authorization 498 information associated with the domain object or authorization 499 information associated with the domain object's registrant or 500 associated contacts. An OPTIONAL "roid" attribute MUST be used to 501 identify the registrant or contact object if and only if the given 502 authInfo is associated with a registrant or contact object, and 503 not the domain object itself. If this element is not provided or 504 if the authorization information is invalid, server policy 505 determines if the command is rejected or if response information 506 will be returned to the client. 508 Example command without authorization information: 510 C: 511 C: 512 C: 513 C: 514 C: 516 C: example.com 517 C: 518 C: 519 C: ABC-12345 520 C: 521 C: 522 Example command with authorization information: 524 C: 525 C: 526 C: 527 C: 528 C: 530 C: example.com 531 C: 532 C: 2fooBAR 533 C: 534 C: 535 C: 536 C: ABC-12345 537 C: 538 C: 540 When an command has been processed successfully, the EPP 541 element MUST contain a child element that 542 identifies the domain namespace. Elements that are not OPTIONAL MUST 543 be returned; OPTIONAL elements are returned based on client 544 authorization and server policy. The element 545 contains the following child elements: 547 - A element that contains the fully qualified name of 548 the domain object. 550 - A element that contains the Repository Object 551 IDentifier assigned to the domain object when the object was 552 created. 554 - Zero or more OPTIONAL elements that contain the 555 current status descriptors associated with the domain. 557 - If supported by the server, one OPTIONAL 558 element and one or more OPTIONAL elements that 559 contain identifiers for the human or organizational social 560 information objects associated with the domain object. 562 - An OPTIONAL element that contains the fully qualified 563 names of the delegated host objects or host attributes (name 564 servers) associated with the domain object. See section 1.1 for a 565 description of the elements used to specify host objects or host 566 attributes. 568 - Zero or more OPTIONAL elements that contain the 569 fully qualified names of the subordinate host objects that exist 570 under this superordinate domain object. 572 - A element that contains the identifier of the 573 sponsoring client. 575 - An OPTIONAL element that contains the identifier of 576 the client that created the domain object. 578 - An OPTIONAL element that contains the date and 579 time of domain object creation. 581 - An OPTIONAL element that contains the date and 582 time identifying the end of the domain object's registration 583 period. 585 - An OPTIONAL element that contains the identifier of 586 the client that last updated the domain object. This element MUST 587 NOT be present if the domain has never been modified. 589 - An OPTIONAL element that contains the date and 590 time of the most recent domain object modification. This element 591 MUST NOT be present if the domain object has never been modified. 593 - An OPTIONAL elements that contains the date and 594 time of the most recent successful domain object transfer. This 595 element MUST NOT be provided if the domain object has never been 596 transferred. 598 - An OPTIONAL element that contains authorization 599 information associated with the domain object. This element MUST 600 only be returned if the querying client is the current sponsoring 601 client, or if the client supplied valid authorization information 602 with the command. 604 Example response for an authorized client: 606 S: 607 S: 608 S: 609 S: 610 S: Command completed successfully 611 S: 612 S: 613 S: 615 S: example.com 616 S: EXAMPLE1-REP 617 S: 618 S: jd1234 619 S: sh8013 620 S: sh8013 621 S: 622 S: ns1.example.com 623 S: ns1.example.net 624 S: 625 S: ns1.example.com 626 S: ns2.example.com 627 S: ClientX 628 S: ClientY 629 S: 1999-04-03T22:00:00.0Z 630 S: ClientX 631 S: 1999-12-03T09:00:00.0Z 632 S: 2005-04-03T22:00:00.0Z 633 S: 2000-04-08T09:00:00.0Z 634 S: 635 S: 2fooBAR 636 S: 637 S: 638 S: 639 S: 640 S: ABC-12345 641 S: 54322-XYZ 642 S: 643 S: 644 S: 646 A server with a different information return policy MAY provide less 647 information in a response. 649 Example response for an unauthorized client: 651 S: 652 S: 653 S: 654 S: 655 S: Command completed successfully 656 S: 657 S: 658 S: 660 S: example.com 661 S: EXAMPLE1-REP 662 S: ClientX 663 S: 664 S: 665 S: 666 S: ABC-12345 667 S: 54322-XYZ 668 S: 669 S: 670 S: 672 An EPP error response MUST be returned if an command can not 673 be processed for any reason. 675 3.1.3. EPP Query Command 677 The EPP command provides a query operation that allows a 678 client to determine real-time status of pending and completed 679 transfer requests. In addition to the standard EPP command elements, 680 the command MUST contain an "op" attribute with value 681 "query", and a element that identifies the domain 682 namespace. The element contains the following 683 child elements: 685 - A element that contains the fully qualified name of 686 the domain object to be queried. 688 - An OPTIONAL element that contains authorization 689 information associated with the domain object or authorization 690 information associated with the domain object's registrant or 691 associated contacts. An OPTIONAL "roid" attribute MUST be used to 692 identify the registrant or contact object if and only if the given 693 authInfo is associated with a registrant or contact object, and 694 not the domain object itself. If this element is not provided or 695 if the authorization information is invalid, server policy 696 determines if the command is rejected or if response information 697 will be returned to the client. 699 Example query command: 701 C: 702 C: 703 C: 704 C: 705 C: 707 C: example.com 708 C: 709 C: 2fooBAR 710 C: 711 C: 712 C: 713 C: ABC-12345 714 C: 715 C: 717 When a query command has been processed successfully, the 718 EPP element MUST contain a child element 719 that identifies the domain namespace. The element 720 contains the following child elements: 722 - A element that contains the fully qualified name of 723 the domain object. 725 - A element that contains the state of the most 726 recent transfer request. 728 - A element that contains the identifier of the client 729 that requested the object transfer. 731 - A element that contains the date and time that the 732 transfer was requested. 734 - A element that contains the identifier of the client 735 that SHOULD act upon a PENDING transfer request. For all other 736 status types, the value identifies the client that took the 737 indicated action. 739 - A element that contains the date and time of a 740 required or completed response. For a PENDING request, the value 741 identifies the date and time by which a response is required 742 before an automated response action will be taken by the server. 743 For all other status types, the value identifies the date and time 744 when the request was completed. 746 - An OPTIONAL element that contains the end of the 747 domain object's validity period if the command caused 748 or causes a change in the validity period. 750 Example query response: 752 S: 753 S: 754 S: 755 S: 756 S: Command completed successfully 757 S: 758 S: 759 S: 761 S: example.com 762 S: pending 763 S: ClientX 764 S: 2000-06-06T22:00:00.0Z 765 S: ClientY 766 S: 2000-06-11T22:00:00.0Z 767 S: 2002-09-08T22:00:00.0Z 768 S: 769 S: 770 S: 771 S: ABC-12345 772 S: 54322-XYZ 773 S: 774 S: 775 S: 777 An EPP error response MUST be returned if a query command 778 can not be processed for any reason. 780 3.2. EPP Transform Commands 782 EPP provides five commands to transform domain objects: to 783 create an instance of a domain object, to delete an instance 784 of a domain object, to extend the validity period of a domain 785 object, to manage domain object sponsorship changes, and 786 to change information associated with a domain object. 788 Transform commands are typically processed and completed in real 789 time. Server operators MAY receive and process transform commands, 790 but defer completing the requested action if human or third-party 791 review is required before the requested action can be completed. In 792 such situations the server MUST return a 1001 response code to the 793 client to note that the command has been received and processed, but 794 the requested action is pending. The server MUST also manage the 795 status of the object that is the subject of the command to reflect 796 the initiation and completion of the requested action. Once the 797 action has been completed, all clients involved in the transaction 798 MUST be notified using a service message that the action has been 799 completed and that the status of the object has changed. 801 3.2.1. EPP Command 803 The EPP command provides a transform operation that allows a 804 client to create a domain object. In addition to the standard EPP 805 command elements, the command MUST contain a 806 element that identifies the domain namespace. The 807 element contains the following child elements: 809 - A element that contains the fully qualified name of 810 the domain object to be created. 812 - An OPTIONAL element that contains the initial 813 registration period of the domain object. A server MAY define a 814 default initial registration period if not specified by the 815 client. 817 - An OPTIONAL element that contains the fully qualified 818 names of the delegated host objects or host attributes (name 819 servers) associated with the domain object to provide resolution 820 services for the domain; see section 1.1 for a description of the 821 elements used to specify host objects or host attributes. A host 822 object MUST be known to the server before the host object can be 823 associated with a domain object. 825 - An OPTIONAL element that contains the 826 identifier for the human or organizational social information 827 (contact) object to be associated with the domain object as the 828 object registrant. This object identifier MUST be known to the 829 server before the contact object can be associated with the domain 830 object. The EPP mapping for contact objects is described in 831 [I-D.hollenbeck-epp-rfc3733bis]. 833 - Zero or more OPTIONAL elements that contain the 834 identifiers for other contact objects to be associated with the 835 domain object. Contact object identifiers MUST be known to the 836 server before the contact object can be associated with the domain 837 object. 839 - A element that contains authorization 840 information to be associated with the domain object. This mapping 841 includes a password-based authentication mechanism, but the schema 842 allows new mechanisms to be defined in new schemas. 844 Example command: 846 C: 847 C: 848 C: 849 C: 850 C: 852 C: example.com 853 C: 2 854 C: 855 C: ns1.example.com 856 C: ns1.example.net 857 C: 858 C: jd1234 859 C: sh8013 860 C: sh8013 861 C: 862 C: 2fooBAR 863 C: 864 C: 865 C: 866 C: ABC-12345 867 C: 868 C: 870 When a command has been processed successfully, the EPP 871 element MUST contain a child element that 872 identifies the domain namespace. The element 873 contains the following child elements: 875 - A element that contains the fully qualified name of 876 the domain object. 878 - A element that contains the date and time of 879 domain object creation. 881 - An OPTIONAL element that contains the date and 882 time identifying the end of the domain object's registration 883 period. 885 Example response: 887 S: 888 S: 889 S: 890 S: 891 S: Command completed successfully 892 S: 893 S: 894 S: 896 S: example.com 897 S: 1999-04-03T22:00:00.0Z 898 S: 2001-04-03T22:00:00.0Z 899 S: 900 S: 901 S: 902 S: ABC-12345 903 S: 54321-XYZ 904 S: 905 S: 906 S: 908 An EPP error response MUST be returned if a command can not 909 be processed for any reason. 911 3.2.2. EPP Command 913 The EPP command provides a transform operation that allows a 914 client to delete a domain object. In addition to the standard EPP 915 command elements, the command MUST contain a 916 element that identifies the domain namespace. The 917 element contains the following child elements: 919 - A element that contains the fully qualified name of 920 the domain object to be deleted. 922 A domain object SHOULD NOT be deleted if subordinate host objects are 923 associated with the domain object. For example, if domain 924 "example.com" exists, and host object "ns1.example.com" also exists, 925 then domain "example.com" SHOULD NOT be deleted until host 926 "ns1.example.com" has been either deleted or renamed to exist in a 927 different superordinate domain. A server SHOULD notify clients that 928 object relationships exist by sending a 2305 error response code when 929 a command is attempted and fails due to existing object 930 relationships. Delegated and subordinate host objects associated 931 with a domain object can be determined using the query command 932 for the domain object. 934 Example command: 936 C: 937 C: 938 C: 939 C: 940 C: 942 C: example.com 943 C: 944 C: 945 C: ABC-12345 946 C: 947 C: 949 When a command has been processed successfully, a server 950 MUST respond with an EPP response with no element. 951 Example response: 953 S: 954 S: 955 S: 956 S: 957 S: Command completed successfully 958 S: 959 S: 960 S: ABC-12345 961 S: 54321-XYZ 962 S: 963 S: 964 S: 966 An EPP error response MUST be returned if a command can not 967 be processed for any reason. 969 3.2.3. EPP Command 971 The EPP command provides a transform operation that allows a 972 client to extend the validity period of a domain object. In addition 973 to the standard EPP command elements, the command MUST 974 contain a element that identifies the domain 975 namespace. The element contains the following child 976 elements: 978 - A element that contains the fully qualified name of 979 the domain object whose validity period is to be extended. 981 - A element that contains the date on which the 982 current validity period ends. This value ensures that repeated 983 commands do not result in multiple unanticipated 984 successful renewals. 986 - An OPTIONAL element that contains the number of 987 units to be added to the registration period of the domain object. 988 The number of units available MAY be subject to limits imposed by 989 the server. 991 Example command: 993 C: 994 C: 995 C: 996 C: 997 C: 999 C: example.com 1000 C: 2000-04-03 1001 C: 5 1002 C: 1003 C: 1004 C: ABC-12345 1005 C: 1006 C: 1008 When a command has been processed successfully, the EPP 1009 element MUST contain a child element that 1010 identifies the domain namespace. The element 1011 contains the following child elements: 1013 - A element that contains the fully qualified name of 1014 the domain object. 1016 - An OPTIONAL element that contains the date and 1017 time identifying the end of the domain object's registration 1018 period. 1020 Example response: 1022 S: 1023 S: 1024 S: 1025 S: 1026 S: Command completed successfully 1027 S: 1028 S: 1029 S: 1031 S: example.com 1032 S: 2005-04-03T22:00:00.0Z 1033 S: 1034 S: 1035 S: 1036 S: ABC-12345 1037 S: 54322-XYZ 1038 S: 1039 S: 1040 S: 1042 An EPP error response MUST be returned if a command can not 1043 be processed for any reason. 1045 3.2.4. EPP Command 1047 The EPP command provides a transform operation that allows 1048 a client to manage requests to transfer the sponsorship of a domain 1049 object. In addition to the standard EPP command elements, the 1050 command MUST contain a element that 1051 identifies the domain namespace. The element 1052 contains the following child elements: 1054 - A element that contains the fully qualified name of 1055 the domain object for which a transfer request is to be created, 1056 approved, rejected, or cancelled. 1058 - An OPTIONAL element that contains the number of 1059 units to be added to the registration period of the domain object 1060 at completion of the transfer process. This element can only be 1061 used when a transfer is requested, and it MUST be ignored if used 1062 otherwise. The number of units available MAY be subject to limits 1063 imposed by the server. 1065 - A element that contains authorization 1066 information associated with the domain object or authorization 1067 information associated with the domain object's registrant or 1068 associated contacts. An OPTIONAL "roid" attribute MUST be used to 1069 identify the registrant or contact object if and only if the given 1070 authInfo is associated with a registrant or contact object, and 1071 not the domain object itself. 1073 Every EPP command MUST contain an "op" attribute that 1074 identifies the transfer operation to be performed. Valid values, 1075 definitions, and authorizations for all attribute values are defined 1076 in [I-D.hollenbeck-epp-rfc3730bis]. 1078 Transfer of a domain object MUST implicitly transfer all host objects 1079 that are subordinate to the domain object. For example, if domain 1080 object "example.com" is transferred and host object "ns1.example.com" 1081 exists, the host object MUST be transferred as part of the 1082 "example.com" transfer process. Host objects that are subject to 1083 transfer when transferring a domain object are listed in the response 1084 to an EPP command performed on the domain object. 1086 Example request command: 1088 C: 1089 C: 1090 C: 1091 C: 1092 C: 1094 C: example.com 1095 C: 1 1096 C: 1097 C: 2fooBAR 1098 C: 1099 C: 1100 C: 1101 C: ABC-12345 1102 C: 1103 C: 1105 When a command has been processed successfully, the EPP 1106 element MUST contain a child element that 1107 identifies the domain namespace. The element 1108 contains the same child elements defined for a transfer query 1109 response. 1111 Example response: 1113 S: 1114 S: 1115 S: 1116 S: 1117 S: Command completed successfully; action pending 1118 S: 1119 S: 1120 S: 1122 S: example.com 1123 S: pending 1124 S: ClientX 1125 S: 2000-06-08T22:00:00.0Z 1126 S: ClientY 1127 S: 2000-06-13T22:00:00.0Z 1128 S: 2002-09-08T22:00:00.0Z 1129 S: 1130 S: 1131 S: 1132 S: ABC-12345 1133 S: 54322-XYZ 1134 S: 1135 S: 1136 S: 1138 An EPP error response MUST be returned if a command can 1139 not be processed for any reason. 1141 3.2.5. EPP Command 1143 The EPP command provides a transform operation that allows a 1144 client to modify the attributes of a domain object. In addition to 1145 the standard EPP command elements, the command MUST contain 1146 a element that identifies the domain namespace. The 1147 element contains the following child elements: 1149 - A element that contains the fully qualified name of 1150 the domain object to be updated. 1152 - An OPTIONAL element that contains attribute values to 1153 be added to the object. 1155 - An OPTIONAL element that contains attribute values to 1156 be removed from the object. 1158 - An OPTIONAL element that contains object attribute 1159 values to be changed. 1161 At least one , , or element MUST 1162 be provided if the command is not being extended. All of these 1163 elements MAY be omitted if an extension is present. The 1164 and elements contain the following child 1165 elements: 1167 - An OPTIONAL element that contains the fully qualified 1168 names of the delegated host objects or host attributes (name 1169 servers) associated with the domain object to provide resolution 1170 services for the domain; see section 1.1 for a description of the 1171 elements used to specify host objects or host attributes. A host 1172 object MUST be known to the server before the host object can be 1173 associated with a domain object. If host attributes are used to 1174 specify name servers, note that IP address elements are not needed 1175 to identify a name server that is being removed. IP address 1176 elements can safely be absent or ignored in this situation. 1178 - Zero or more elements that contain the 1179 identifiers for contact objects to be associated with or removed 1180 from the domain object. Contact object identifiers MUST be known 1181 to the server before the contact object can be associated with the 1182 domain object. 1184 - Zero or more elements that contain status values 1185 to be applied to or removed from the object. When specifying a 1186 value to be removed, only the attribute value is significant; 1187 element text is not required to match a value for removal. 1189 A element contains the following child elements: 1191 - A element that contains the identifier for the 1192 human or organizational social information (contact) object to be 1193 associated with the domain object as the object registrant. This 1194 object identifier MUST be known to the server before the contact 1195 object can be associated with the domain object. An empty element 1196 can be used to remove registrant information. 1198 - A element that contains authorization 1199 information associated with the domain object. This mapping 1200 includes a password-based authentication mechanism, but the schema 1201 allows new mechanisms to be defined in new schemas. A element can be used within the element to 1203 remove authorization information. 1205 Example command: 1207 C: 1208 C: 1209 C: 1210 C: 1211 C: 1213 C: example.com 1214 C: 1215 C: 1216 C: ns2.example.com 1217 C: 1218 C: mak21 1219 C: Payment overdue. 1221 C: 1222 C: 1223 C: 1224 C: ns1.example.com 1225 C: 1226 C: sh8013 1227 C: 1228 C: 1229 C: 1230 C: sh8013 1231 C: 1232 C: 2BARfoo 1233 C: 1234 C: 1235 C: 1236 C: 1237 C: ABC-12345 1238 C: 1239 C: 1241 When an command has been processed successfully, a server 1242 MUST respond with an EPP response with no element. 1244 Example response: 1246 S: 1247 S: 1248 S: 1249 S: 1250 S: Command completed successfully 1251 S: 1252 S: 1253 S: ABC-12345 1254 S: 54321-XYZ 1255 S: 1256 S: 1257 S: 1259 An EPP error response MUST be returned if an command can not 1260 be processed for any reason. 1262 3.3. Offline Review of Requested Actions 1264 Commands are processed by a server in the order they are received 1265 from a client. Though an immediate response confirming receipt and 1266 processing of the command is produced by the server, a server 1267 operator MAY perform an offline review of requested transform 1268 commands before completing the requested action. In such situations 1269 the response from the server MUST clearly note that the transform 1270 command has been received and processed, but the requested action is 1271 pending. The status of the corresponding object MUST clearly reflect 1272 processing of the pending action. The server MUST notify the client 1273 when offline processing of the action has been completed. 1275 Examples describing a command that requires offline review 1276 are included here. Note the result code and message returned in 1277 response to the command. 1279 S: 1280 S: 1281 S: 1282 S: 1283 S: Command completed successfully; action pending 1284 S: 1285 S: 1286 S: 1288 S: example.com 1289 S: 1999-04-03T22:00:00.0Z 1290 S: 2001-04-03T22:00:00.0Z 1291 S: 1292 S: 1293 S: 1294 S: ABC-12345 1295 S: 54321-XYZ 1296 S: 1297 S: 1298 S: 1300 The status of the domain object after returning this response MUST 1301 include "pendingCreate". The server operator reviews the request 1302 offline, and informs the client of the outcome of the review by 1303 either queuing a service message for retrieval via the command 1304 or by using an out-of-band mechanism to inform the client of the 1305 request. 1307 The service message MUST contain text in the , , 1308 element that describes the notification. In addition, the EPP 1309 element MUST contain a child element that 1310 identifies the domain namespace. The element 1311 contains the following child elements: 1313 - A element that contains the fully qualified name of 1314 the domain object. The element contains a REQUIRED 1315 "paResult" attribute. A positive boolean value indicates that the 1316 request has been approved and completed. A negative boolean value 1317 indicates that the request has been denied and the requested 1318 action has not been taken. 1320 - A element that contains the client transaction 1321 identifier and server transaction identifier returned with the 1322 original response to process the command. The client transaction 1323 identifier is OPTIONAL and will only be returned if the client 1324 provided an identifier with the original command. 1326 - A element that contains the date and time 1327 describing when review of the requested action was completed. 1329 Example "review completed" service message: 1331 S: 1332 S: 1333 S: 1334 S: 1335 S: Command completed successfully; ack to dequeue 1336 S: 1337 S: 1338 S: 1999-04-04T22:01:00.0Z 1339 S: Pending action completed successfully. 1340 S: 1341 S: 1342 S: 1344 S: example.com 1345 S: 1346 S: ABC-12345 1347 S: 54321-XYZ 1348 S: 1349 S: 1999-04-04T22:00:00.0Z 1350 S: 1351 S: 1352 S: 1353 S: BCD-23456 1354 S: 65432-WXY 1355 S: 1356 S: 1357 S: 1359 4. Formal Syntax 1361 An EPP object mapping is specified in XML Schema notation. The 1362 formal syntax presented here is a complete schema representation of 1363 the object mapping suitable for automated validation of EPP XML 1364 instances. The BEGIN and END tags are not part of the schema; they 1365 are used to note the beginning and ending of the schema for URI 1366 registration purposes. 1368 BEGIN 1369 1371 1379 1382 1383 1384 1386 1387 1388 Extensible Provisioning Protocol v1.0 1389 domain provisioning schema. 1390 1391 1393 1396 1397 1398 1399 1400 1401 1402 1403 1406 1407 1408 1409 1411 1413 1415 1417 1418 1419 1420 1421 1422 1423 1425 1426 1427 1429 1430 1431 1432 1433 1434 1436 1437 1438 1439 1440 1441 1443 1444 1445 1447 1449 1450 1451 1455 1456 1457 1458 1460 1461 1462 1467 1468 1469 1470 1471 1472 1473 1475 1476 1477 1478 1479 1480 1481 1483 1484 1485 1486 1487 1488 1490 1493 1494 1495 1496 1497 1498 1501 1502 1503 1505 1506 1508 1511 1512 1513 1514 1517 1518 1520 1521 1522 1523 1525 1526 1527 1529 1530 1531 1532 1533 1534 1535 1536 1538 1541 1542 1543 1544 1545 1547 1548 1550 1553 1554 1555 1556 1558 1560 1561 1563 1567 1568 1569 1570 1572 1574 1576 1577 1579 1582 1583 1584 1586 1588 1590 1591 1593 1596 1597 1598 1600 1602 1603 1605 1609 1610 1611 1612 1613 1615 1617 1621 1622 1623 1624 1625 1626 1627 1629 1632 1633 1634 1635 1636 1637 1639 1642 1643 1644 1646 1647 1649 1650 1651 1652 1654 1655 1657 1658 1659 1660 1662 1664 1665 1667 1670 1671 1672 1673 1674 1676 1677 1679 1682 1683 1684 1685 1686 1688 1690 1692 1694 1696 1697 1699 1701 1703 1705 1707 1709 1711 1713 1715 1720 1721 1722 1723 1725 1727 1728 1729 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1753 1756 1757 1758 1759 1760 1762 1763 1765 1766 1767 1768 1770 1771 1772 1774 1777 1778 1779 1780 1782 1783 1785 1788 1789 1790 1791 1792 1793 1794 1795 1796 1798 1799 1801 1804 1805 END 1807 5. Internationalization Considerations 1809 EPP is represented in XML, which provides native support for encoding 1810 information using the Unicode character set and its more compact 1811 representations including UTF-8. Conformant XML processors recognize 1812 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1813 identify and use other character encodings through use of an 1814 "encoding" attribute in an declaration, use of UTF-8 is 1815 RECOMMENDED in environments where parser encoding support 1816 incompatibility exists. 1818 All date-time values presented via EPP MUST be expressed in Universal 1819 Coordinated Time using the Gregorian calendar. XML Schema allows use 1820 of time zone identifiers to indicate offsets from the zero meridian, 1821 but this option MUST NOT be used with EPP. The extended date-time 1822 form using upper case "T" and "Z" characters defined in 1823 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1824 values as XML Schema does not support truncated date-time forms or 1825 lower case "T" and "Z" characters. 1827 This document requires domain and host name syntax as specified in 1828 [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 1829 3490 [RFC3490] describes a standard to use certain ASCII name labels 1830 to represent non-ASCII name labels. These conformance requirements 1831 might change as a result of progressing work in developing standards 1832 for internationalized domain names. 1834 6. IANA Considerations 1836 This document uses URNs to describe XML namespaces and XML schemas 1837 conforming to a registry mechanism described in [RFC3688]. Two URI 1838 assignments have been registered by the IANA. 1840 Registration request for the domain namespace: 1842 URI: urn:ietf:params:xml:ns:domain-1.0 1844 Registrant Contact: See the "Author's Address" section of this 1845 document. 1847 XML: None. Namespace URIs do not represent an XML specification. 1849 Registration request for the domain XML schema: 1851 URI: urn:ietf:params:xml:schema:domain-1.0 1853 Registrant Contact: See the "Author's Address" section of this 1854 document. 1856 XML: See the "Formal Syntax" section of this document. 1858 7. Security Considerations 1860 Authorization information as described in section 2.6 is REQUIRED to 1861 create a domain object. This information is used in some query and 1862 transfer operations as an additional means of determining client 1863 authorization to perform the command. Failure to protect 1864 authorization information from inadvertent disclosure can result in 1865 unauthorized transfer operations and unauthorized information 1866 release. Both client and server MUST ensure that authorization 1867 information is stored and exchanged with high-grade encryption 1868 mechanisms to provide privacy services. 1870 The object mapping described in this document does not provide any 1871 other security services or introduce any additional considerations 1872 beyond those described by [I-D.hollenbeck-epp-rfc3730bis] and 1873 protocol layers used by EPP. 1875 8. Acknowledgements 1877 This document was originally written as an individual submission 1878 Internet-Draft. The provreg working group later adopted it as a 1879 working group document and provided many invaluable comments and 1880 suggested improvements. The author wishes to acknowledge the efforts 1881 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1882 editorial contributions. 1884 Specific suggestions that have been incorporated into this document 1885 were provided by Joe Abley, Chris Bason, Eric Brunner-Williams, 1886 Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1887 El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick 1888 Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson. 1890 9. References 1892 9.1. Normative References 1894 [I-D.hollenbeck-epp-rfc3730bis] 1895 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1896 draft-hollenbeck-epp-rfc3730bis-04 (work in progress), 1897 November 2006. 1899 [I-D.hollenbeck-epp-rfc3732bis] 1900 Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1901 Host Mapping", draft-hollenbeck-epp-rfc3732bis-04 (work in 1902 progress), November 2006. 1904 [I-D.hollenbeck-epp-rfc3733bis] 1905 Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1906 Contact Mapping", draft-hollenbeck-epp-rfc3733bis-05 (work 1907 in progress), November 2006. 1909 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1910 host table specification", RFC 952, October 1985. 1912 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1913 and Support", STD 3, RFC 1123, October 1989. 1915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1916 Requirement Levels", BCP 14, RFC 2119, March 1997. 1918 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1919 January 2004. 1921 [W3C.REC-xml-20040204] 1922 Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., and 1923 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1924 Edition)", World Wide Web Consortium Recommendation REC- 1925 xml-20040204, February 2004, 1926 . 1928 [W3C.REC-xmlschema-1-20041028] 1929 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn, 1930 "XML Schema Part 1: Structures Second Edition", World Wide 1931 Web Consortium Recommendation REC-xmlschema-1-20041028, 1932 October 2004, 1933 . 1935 [W3C.REC-xmlschema-2-20041028] 1936 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1937 Second Edition", World Wide Web Consortium 1938 Recommendation REC-xmlschema-2-20041028, October 2004, 1939 . 1941 9.2. Informative References 1943 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1944 10646", RFC 2781, February 2000. 1946 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1947 "Internationalizing Domain Names in Applications (IDNA)", 1948 RFC 3490, March 2003. 1950 [RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1951 Domain Name Mapping", RFC 3731, March 2004. 1953 Appendix A. Changes from RFC 3731 1955 1. Minor reformatting as a result of converting I-D source format 1956 from nroff to XML. 1958 2. Removed this text from Section 2.3: 1960 "With one exception, transform commands MUST be rejected when a 1961 pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or 1962 pendingUpdate status is set. The only exception is that a 1963 command to approve, reject, or cancel a transfer MAY 1964 be processed while an object is in "pendingTransfer" status." 1966 3. Changed text in Section 3.1.3 from "A element that 1967 contains the identifier of the client that SHOULD act upon the 1968 transfer request" to "A element that contains the 1969 identifier of the client that SHOULD act upon a PENDING transfer 1970 request. For all other status types, the value identifies the 1971 client that took the indicated action". 1973 4. Changed text in Section 3.2.1.4 from "At least one , 1974 , or element MUST be provided." to "At 1975 least one , , or element 1976 MUST be provided if the command is not being extended. All of 1977 these elements MAY be omitted if an extension is 1978 present.". 1980 5. Renumbered old section 3.2.6 to new section 3.3. 1982 6. Changed text in Section 3.3 (old Section 3.2.6) from this: 1984 "The server operator reviews the request offline, and informs the 1985 client of the outcome of the review by queuing a service message 1986 for retrieval via the command." 1988 to this: 1990 "The server operator reviews the request offline, and informs the 1991 client of the outcome of the review by either queuing a service 1992 message for retrieval via the command or by using an out- 1993 of-band mechanism to inform the client of the request." 1995 7. Removed text describing use of the XML Schema schemaLocation 1996 attribute. This is an optional attribute that doesn't need to be 1997 mandated for use in EPP. 1999 8. Removed references to RFC 3339 and replaced them with references 2000 to the W3C XML Schema specification. 2002 9. Updated EPP and XML references. 2004 Author's Address 2006 Scott Hollenbeck 2007 VeriSign, Inc. 2008 21345 Ridgetop Circle 2009 Dulles, VA 20166-6503 2010 US 2012 Email: shollenbeck@verisign.com 2014 Full Copyright Statement 2016 Copyright (C) The IETF Trust (2006). 2018 This document is subject to the rights, licenses and restrictions 2019 contained in BCP 78, and except as set forth therein, the authors 2020 retain all their rights. 2022 This document and the information contained herein are provided on an 2023 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2024 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2025 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2026 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2027 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2028 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2030 Intellectual Property 2032 The IETF takes no position regarding the validity or scope of any 2033 Intellectual Property Rights or other rights that might be claimed to 2034 pertain to the implementation or use of the technology described in 2035 this document or the extent to which any license under such rights 2036 might or might not be available; nor does it represent that it has 2037 made any independent effort to identify any such rights. Information 2038 on the procedures with respect to rights in RFC documents can be 2039 found in BCP 78 and BCP 79. 2041 Copies of IPR disclosures made to the IETF Secretariat and any 2042 assurances of licenses to be made available, or the result of an 2043 attempt made to obtain a general license or permission for the use of 2044 such proprietary rights by implementers or users of this 2045 specification can be obtained from the IETF on-line IPR repository at 2046 http://www.ietf.org/ipr. 2048 The IETF invites any interested party to bring to its attention any 2049 copyrights, patents or patent applications, or other proprietary 2050 rights that may cover technology that may be required to implement 2051 this standard. Please address the information to the IETF at 2052 ietf-ipr@ietf.org. 2054 Acknowledgment 2056 Funding for the RFC Editor function is provided by the IETF 2057 Administrative Support Activity (IASA).