idnits 2.17.00 (12 Aug 2021) /tmp/idnits3029/draft-hollenbeck-rfc4931bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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. -- The draft header indicates that this document obsoletes RFC4931, but the abstract doesn't seem to directly say this. It does mention RFC4931 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2009) is 4792 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: draft-hollenbeck-rfc4930bis has been published as RFC 5730 -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4930bis' == Outdated reference: draft-hollenbeck-rfc4932bis has been published as RFC 5732 -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4932bis' == Outdated reference: draft-hollenbeck-rfc4933bis has been published as RFC 5733 -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4933bis' ** 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 4931 (Obsoleted by RFC 5731) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: 4931 (if approved) April 6, 2009 5 Intended status: Standards Track 6 Expires: October 8, 2009 8 Extensible Provisioning Protocol (EPP) Domain Name Mapping 9 draft-hollenbeck-rfc4931bis-00 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 8, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes an Extensible Provisioning Protocol (EPP) 48 mapping for the provisioning and management of Internet domain names 49 stored in a shared central repository. Specified in XML, the mapping 50 defines EPP command syntax and semantics as applied to domain names. 51 This document is intended to obsolete RFC 4931. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Relationship of Domain Objects and Host Objects . . . . . 3 57 1.2. Conventions Used in This Document . . . . . . . . . . . . 5 58 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Domain and Host Names . . . . . . . . . . . . . . . . . . 5 60 2.2. Contact and Client Identifiers . . . . . . . . . . . . . . 6 61 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 8 63 2.5. Validity Periods . . . . . . . . . . . . . . . . . . . . . 8 64 2.6. Authorization Information . . . . . . . . . . . . . . . . 8 65 2.7. Other DNS Resource Record Attributes . . . . . . . . . . . 8 66 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9 68 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 9 69 3.1.2. EPP Command . . . . . . . . . . . . . . . . . . 11 70 3.1.3. EPP Query Command . . . . . . . . . . . . . 16 71 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 18 72 3.2.1. EPP Command . . . . . . . . . . . . . . . . . 19 73 3.2.2. EPP Command . . . . . . . . . . . . . . . . . 21 74 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 22 75 3.2.4. EPP Command . . . . . . . . . . . . . . . . 24 76 3.2.5. EPP Command . . . . . . . . . . . . . . . . . 26 77 3.3. Offline Review of Requested Actions . . . . . . . . . . . 29 78 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31 79 5. Internationalization Considerations . . . . . . . . . . . . . 40 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 44 86 Appendix A. Changes from RFC 4931 . . . . . . . . . . . . . . . . 44 88 1. Introduction 90 This document describes an Internet domain name mapping for version 91 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is 92 specified using the Extensible Markup Language (XML) 1.0 as described 93 in [W3C.REC-xml-20040204] and XML Schema notation as described in 94 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 95 This document is intended to obsolete RFC 4931 [RFC4931]. 97 [I-D.hollenbeck-rfc4930bis] provides a complete description of EPP 98 command and response structures. A thorough understanding of the 99 base protocol specification is necessary to understand the mapping 100 described in this document. 102 XML is case sensitive. Unless stated otherwise, XML specifications 103 and examples provided in this document MUST be interpreted in the 104 character case presented to develop a conforming implementation. 106 1.1. Relationship of Domain Objects and Host Objects 108 The EPP mapping for host objects is described in 109 [I-D.hollenbeck-rfc4932bis]. This document assumes that domain name 110 objects have a superordinate relationship to subordinate host name 111 objects. For example, domain name "example.com" has a superordinate 112 relationship to host name "ns1.example.com". EPP actions (such as 113 object transfers) that do not preserve this relationship MUST be 114 explicitly disallowed. 116 A host name object can be created in a repository for which no 117 superordinate domain name object exists. For example, host name 118 "ns1.example.com" can be created in the ".example" repository so that 119 DNS domains in ".example" can be delegated to the host. Such hosts 120 are described as "external" hosts in this specification since the 121 name of the host does not belong to the name space of the repository 122 in which the host is being used for delegation purposes. 124 Whether a host is external or internal relates to the repository in 125 which the host is being used for delegation purposes. Whether or not 126 an internal host is subordinate relates to a domain within the 127 repository. For example, host ns1.example1.com is a subordinate host 128 of domain example1.com, but it is not a subordinate host of domain 129 example2.com. ns1.example1.com can be used as a name server for 130 example2.com. In this case, ns1.example1.com MUST be treated as an 131 internal host, subject to the rules governing operations on 132 subordinate hosts within the same repository. 134 Name server hosts for domain delegation can be specified as either 135 references to existing host objects or as domain attributes that 136 describe a host machine. A server operator MUST use one name server 137 specification form consistently. A server operator that announces 138 support for host objects in an EPP greeting MUST NOT allow domain 139 attributes to describe a name server host machine. A server operator 140 that does not announce support for host objects MUST allow domain 141 attributes to describe a name server host machine. When domain 142 attributes are used to describe a name server host machine, IP 143 addresses SHOULD be required only as needed to generate DNS glue 144 records. 146 Name servers are specified within a element. This 147 element MUST contain one or more elements or one or 148 more elements. A element contains 149 the fully qualified name of a known name server host object. A 150 element contains the following child elements: 152 - A element that contains the fully qualified name 153 of a host. 155 - Zero or more OPTIONAL element that contain the 156 IP addresses to be associated with the host. Each element MAY 157 contain an "ip" attribute to identify the IP address format. 158 Attribute value "v4" is used to note IPv4 address format. 159 Attribute value "v6" is used to note IPv6 address format. If the 160 "ip" attribute is not specified, "v4" is the default attribute 161 value. IP address syntax requirements are described in Section 162 2.5 of the EPP host mapping [I-D.hollenbeck-rfc4932bis]. 164 Example host object name server elements for domain example.com: 166 167 ns1.example.com 168 ns1.example.net 169 170 Example host attribute name server elements for domain example.com: 172 173 174 ns1.example.com 175 192.0.2.2 177 1080:0:0:0:8:800:200C:417A 179 180 181 ns1.example.net 182 183 185 1.2. Conventions Used in This Document 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 In examples, "C:" represents lines sent by a protocol client and "S:" 192 represents lines returned by a protocol server. Indentation and 193 white space in examples are provided only to illustrate element 194 relationships and are not a REQUIRED feature of this protocol. 196 2. Object Attributes 198 An EPP domain object has attributes and associated values that can be 199 viewed and modified by the sponsoring client or the server. This 200 section describes each attribute type in detail. The formal syntax 201 for the attribute values described here can be found in the "Formal 202 Syntax" section of this document and in the appropriate normative 203 references. 205 2.1. Domain and Host Names 207 The syntax for domain and host names described in this document MUST 208 conform to [RFC0952] as updated by [RFC1123]. At the time of this 209 writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII 210 name labels to represent non-ASCII name labels. These conformance 211 requirements might change as a result of progressing work in 212 developing standards for internationalized domain names. A server 213 MAY restrict allowable domain names to a particular top-level domain, 214 second-level domain, or other domain for which the server is 215 authoritative. The trailing dot required when these names are stored 216 in a DNS zone is implicit and MUST NOT be provided when exchanging 217 host and domain names. 219 2.2. Contact and Client Identifiers 221 All EPP contacts are identified by a server-unique identifier. 222 Contact identifiers are character strings with a specified minimum 223 length, a specified maximum length, and a specified format. Contact 224 identifiers use the "clIDType" client identifier syntax described in 225 [I-D.hollenbeck-rfc4930bis]. 227 2.3. Status Values 229 A domain object MUST always have at least one associated status 230 value. Status values can be set only by the client that sponsors a 231 domain object and by the server on which the object resides. A 232 client can change the status of a domain object using the EPP 233 command. Each status value MAY be accompanied by a string 234 of human-readable text that describes the rationale for the status 235 applied to the object. 237 A client MUST NOT alter status values set by the server. A server 238 MAY alter or override status values set by a client subject to local 239 server policies. The status of an object MAY change as a result of 240 either a client-initiated transform command or an action performed by 241 a server operator. 243 Status values that can be added or removed by a client are prefixed 244 with "client". Corresponding status values that can be added or 245 removed by a server are prefixed with "server". Status values that 246 do not begin with either "client" or "server" are server-managed. 248 Status Value Descriptions: 250 - clientDeleteProhibited, serverDeleteProhibited 252 Requests to delete the object MUST be rejected. 254 - clientHold, serverHold 256 DNS delegation information MUST NOT be published for the object. 258 - clientRenewProhibited, serverRenewProhibited 260 Requests to renew the object MUST be rejected. 262 - clientTransferProhibited, serverTransferProhibited 264 Requests to transfer the object MUST be rejected. 266 - clientUpdateProhibited, serverUpdateProhibited 268 Requests to update the object (other than to remove this status) 269 MUST be rejected. 271 - inactive 273 Delegation information has not been associated with the object. 275 - ok 277 This is the normal status value for an object that has no pending 278 operations or prohibitions. This value is set and removed by the 279 server as other status values are added or removed. 281 - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, 282 pendingUpdate 284 A transform command has been processed for the object, but the 285 action has not been completed by the server. Server operators can 286 delay action completion for a variety of reasons, such as to allow 287 for human review or third-party action. A transform command that 288 is processed, but whose requested action is pending, is noted with 289 response code 1001. 291 When the requested action has been completed, the pendingCreate, 292 pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status 293 value MUST be removed. All clients involved in the transaction MUST 294 be notified using a service message that the action has been 295 completed and that the status of the object has changed. 297 "ok" status MUST NOT be combined with any other status. 299 "pendingDelete" status MUST NOT be combined with either 300 "clientDeleteProhibited" or "serverDeleteProhibited" status. 302 "pendingRenew" status MUST NOT be combined with either 303 "clientRenewProhibited" or "serverRenewProhibited" status. 305 "pendingTransfer" status MUST NOT be combined with either 306 "clientTransferProhibited" or "serverTransferProhibited" status. 308 "pendingUpdate" status MUST NOT be combined with either 309 "clientUpdateProhibited" or "serverUpdateProhibited" status. 311 The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and 312 pendingUpdate status values MUST NOT be combined with each other. 314 Other status combinations not expressly prohibited MAY be used. 316 2.4. Dates and Times 318 Date and time attribute values MUST be represented in Universal 319 Coordinated Time (UTC) using the Gregorian calendar. The extended 320 date-time form using upper case "T" and "Z" characters defined in 321 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 322 values as XML Schema does not support truncated date-time forms or 323 lower case "T" and "Z" characters. 325 2.5. Validity Periods 327 A domain name object MAY have a specified validity period. If server 328 policy supports domain object validity periods, the validity period 329 is defined when a domain object is created, and it MAY be extended by 330 the EPP or commands. As a matter of server 331 policy, this specification does not define actions to be taken upon 332 expiration of a domain object's validity period. 334 Validity periods are measured in years or months with the appropriate 335 units specified using the "unit" attribute. Valid values for the 336 "unit" attribute are "y" for years and "m" for months. The minimum 337 allowable period value is one (1). The maximum allowable value is 338 ninety-nine decimal (99). A server MAY support a lower maximum 339 value. 341 2.6. Authorization Information 343 Authorization information is associated with domain objects to 344 facilitate transfer operations. Authorization information is 345 assigned when a domain object is created, and it might be updated in 346 the future. This specification describes password-based 347 authorization information, though other mechanisms are possible. 349 2.7. Other DNS Resource Record Attributes 351 While the DNS allows many resource record types to be associated with 352 a domain, this mapping only explicitly specifies elements that 353 describe resource records used for domain delegation and resolution. 354 Facilities to provision other domain-related resource record types 355 can be developed by extending this mapping. 357 The provisioning method described in this mapping separates discrete 358 data elements by data type. This method of data definition allows 359 XML Schema processors to perform basic syntax validation tasks, 360 reducing ambiguity and the amount of parsing and syntax-checking work 361 required of protocol processors. Provisioning and extension methods 362 that aggregate data into opaque strings are possible, but such 363 methods SHOULD NOT be used because they impose additional parsing, 364 interpretation, and validation requirements on protocol processors. 366 3. EPP Command Mapping 368 A detailed description of the EPP syntax and semantics can be found 369 in [I-D.hollenbeck-rfc4930bis]. The command mappings described here 370 are specifically for use in provisioning and managing Internet domain 371 names via EPP. 373 3.1. EPP Query Commands 375 EPP provides three commands to retrieve domain information: 376 to determine if a domain object can be provisioned within a 377 repository, to retrieve detailed information associated with a 378 domain object, and to retrieve domain object transfer 379 status information. 381 3.1.1. EPP Command 383 The EPP command is used to determine if an object can be 384 provisioned within a repository. It provides a hint that allows a 385 client to anticipate the success or failure of provisioning an object 386 using the command as object provisioning requirements are 387 ultimately a matter of server policy. 389 In addition to the standard EPP command elements, the command 390 MUST contain a element that identifies the domain 391 namespace. The element contains the following child 392 elements: 394 - One or more elements that contain the fully 395 qualified names of the domain objects to be queried. 397 Example command: 399 C: 400 C: 401 C: 402 C: 403 C: 405 C: example.com 406 C: example.net 407 C: example.org 408 C: 409 C: 410 C: ABC-12345 411 C: 412 C: 414 When a command has been processed successfully, the EPP 415 element MUST contain a child element that 416 identifies the domain namespace. The element 417 contains one or more elements that contain the following 418 child elements: 420 - A element that contains the fully qualified name of 421 the queried domain object. This element MUST contain an "avail" 422 attribute whose value indicates object availability (can it be 423 provisioned or not) at the moment the command was 424 completed. A value of "1" or "true" means that the object can be 425 provisioned. A value of "0" or "false" means that the object can 426 not be provisioned. 428 - An OPTIONAL element that MAY be provided when an 429 object cannot be provisioned. If present, this element contains 430 server-specific text to help explain why the object cannot be 431 provisioned. This text MUST be represented in the response 432 language previously negotiated with the client; an OPTIONAL "lang" 433 attribute MAY be present to identify the language if the 434 negotiated value is something other than the default value of "en" 435 (English). 437 Example response: 439 S: 440 S: 441 S: 442 S: 443 S: Command completed successfully 444 S: 445 S: 446 S: 448 S: 449 S: example.com 450 S: 451 S: 452 S: example.net 453 S: In use 454 S: 455 S: 456 S: example.org 457 S: 458 S: 459 S: 460 S: 461 S: ABC-12345 462 S: 54322-XYZ 463 S: 464 S: 465 S: 467 An EPP error response MUST be returned if a command cannot be 468 processed for any reason. 470 3.1.2. EPP Command 472 The EPP command is used to retrieve information associated 473 with a domain object. The response to this command MAY vary 474 depending on the identity of the querying client, use of 475 authorization information, and server policy towards unauthorized 476 clients. If the querying client is the sponsoring client, all 477 available information MUST be returned. If the querying client is 478 not the sponsoring client, but the client provides valid 479 authorization information, all available information MUST be 480 returned. If the querying client is not the sponsoring client, and 481 the client does not provide valid authorization information, server 482 policy determines which OPTIONAL elements are returned. 484 In addition to the standard EPP command elements, the command 485 MUST contain a element that identifies the domain 486 namespace. The element contains the following child 487 elements: 489 - A element that contains the fully qualified name of 490 the domain object to be queried. An OPTIONAL "hosts" attribute is 491 available to control return of information describing hosts 492 related to the domain object. A value of "all" (the default, 493 which MAY be absent) returns information describing both 494 subordinate and delegated hosts. A value of "del" returns 495 information describing only delegated hosts. A value of "sub" 496 returns information describing only subordinate hosts. A value of 497 "none" returns no information describing delegated or subordinate 498 hosts. 500 - An OPTIONAL element that contains authorization 501 information associated with the domain object or authorization 502 information associated with the domain object's registrant or 503 associated contacts. An OPTIONAL "roid" attribute MUST be used to 504 identify the registrant or contact object if and only if the given 505 authInfo is associated with a registrant or contact object, and 506 not the domain object itself. If this element is not provided or 507 if the authorization information is invalid, server policy 508 determines if the command is rejected or if response information 509 will be returned to the client. 511 Example command without authorization information: 513 C: 514 C: 515 C: 516 C: 517 C: 519 C: example.com 520 C: 521 C: 522 C: ABC-12345 523 C: 524 C: 525 Example command with authorization information: 527 C: 528 C: 529 C: 530 C: 531 C: 533 C: example.com 534 C: 535 C: 2fooBAR 536 C: 537 C: 538 C: 539 C: ABC-12345 540 C: 541 C: 543 When an command has been processed successfully, the EPP 544 element MUST contain a child element that 545 identifies the domain namespace. Elements that are not OPTIONAL MUST 546 be returned; OPTIONAL elements are returned based on client 547 authorization and server policy. The element 548 contains the following child elements: 550 - A element that contains the fully qualified name of 551 the domain object. 553 - A element that contains the Repository Object 554 IDentifier assigned to the domain object when the object was 555 created. 557 - Zero or more OPTIONAL elements that contain the 558 current status descriptors associated with the domain. 560 - If supported by the server, one OPTIONAL 561 element and one or more OPTIONAL elements that 562 contain identifiers for the human or organizational social 563 information objects associated with the domain object. 565 - An OPTIONAL element that contains the fully qualified 566 names of the delegated host objects or host attributes (name 567 servers) associated with the domain object. See Section 1.1 for a 568 description of the elements used to specify host objects or host 569 attributes. 571 - Zero or more OPTIONAL elements that contain the 572 fully qualified names of the subordinate host objects that exist 573 under this superordinate domain object. 575 - A element that contains the identifier of the 576 sponsoring client. 578 - An OPTIONAL element that contains the identifier of 579 the client that created the domain object. 581 - An OPTIONAL element that contains the date and 582 time of domain object creation. 584 - An OPTIONAL element that contains the date and 585 time identifying the end of the domain object's registration 586 period. 588 - An OPTIONAL element that contains the identifier of 589 the client that last updated the domain object. This element MUST 590 NOT be present if the domain has never been modified. 592 - An OPTIONAL element that contains the date and 593 time of the most recent domain object modification. This element 594 MUST NOT be present if the domain object has never been modified. 596 - An OPTIONAL elements that contains the date and 597 time of the most recent successful domain object transfer. This 598 element MUST NOT be provided if the domain object has never been 599 transferred. 601 - An OPTIONAL element that contains authorization 602 information associated with the domain object. This element MUST 603 only be returned if the querying client is the current sponsoring 604 client, or if the client supplied valid authorization information 605 with the command. 607 Example response for an authorized client: 609 S: 610 S: 611 S: 612 S: 613 S: Command completed successfully 614 S: 615 S: 616 S: 618 S: example.com 619 S: EXAMPLE1-REP 620 S: 621 S: jd1234 622 S: sh8013 623 S: sh8013 624 S: 625 S: ns1.example.com 626 S: ns1.example.net 627 S: 628 S: ns1.example.com 629 S: ns2.example.com 630 S: ClientX 631 S: ClientY 632 S: 1999-04-03T22:00:00.0Z 633 S: ClientX 634 S: 1999-12-03T09:00:00.0Z 635 S: 2005-04-03T22:00:00.0Z 636 S: 2000-04-08T09:00:00.0Z 637 S: 638 S: 2fooBAR 639 S: 640 S: 641 S: 642 S: 643 S: ABC-12345 644 S: 54322-XYZ 645 S: 646 S: 647 S: 649 A server with a different information return policy MAY provide less 650 information in a response. 652 Example response for an unauthorized client: 654 S: 655 S: 656 S: 657 S: 658 S: Command completed successfully 659 S: 660 S: 661 S: 663 S: example.com 664 S: EXAMPLE1-REP 665 S: ClientX 666 S: 667 S: 668 S: 669 S: ABC-12345 670 S: 54322-XYZ 671 S: 672 S: 673 S: 675 An EPP error response MUST be returned if an command cannot be 676 processed for any reason. 678 3.1.3. EPP Query Command 680 The EPP command provides a query operation that allows a 681 client to determine real-time status of pending and completed 682 transfer requests. In addition to the standard EPP command elements, 683 the command MUST contain an "op" attribute with value 684 "query", and a element that identifies the domain 685 namespace. The element contains the following 686 child elements: 688 - A element that contains the fully qualified name of 689 the domain object to be queried. 691 - An OPTIONAL element that contains authorization 692 information associated with the domain object or authorization 693 information associated with the domain object's registrant or 694 associated contacts. An OPTIONAL "roid" attribute MUST be used to 695 identify the registrant or contact object if and only if the given 696 authInfo is associated with a registrant or contact object, and 697 not the domain object itself. If this element is not provided or 698 if the authorization information is invalid, server policy 699 determines if the command is rejected or if response information 700 will be returned to the client. 702 Example query command: 704 C: 705 C: 706 C: 707 C: 708 C: 710 C: example.com 711 C: 712 C: 2fooBAR 713 C: 714 C: 715 C: 716 C: ABC-12345 717 C: 718 C: 720 When a query command has been processed successfully, the 721 EPP element MUST contain a child element 722 that identifies the domain namespace. The element 723 contains the following child elements: 725 - A element that contains the fully qualified name of 726 the domain object. 728 - A element that contains the state of the most 729 recent transfer request. 731 - A element that contains the identifier of the client 732 that requested the object transfer. 734 - A element that contains the date and time that the 735 transfer was requested. 737 - A element that contains the identifier of the client 738 that SHOULD act upon a PENDING transfer request. For all other 739 status types, the value identifies the client that took the 740 indicated action. 742 - A element that contains the date and time of a 743 required or completed response. For a PENDING request, the value 744 identifies the date and time by which a response is required 745 before an automated response action will be taken by the server. 746 For all other status types, the value identifies the date and time 747 when the request was completed. 749 - An OPTIONAL element that contains the end of the 750 domain object's validity period if the command caused 751 or causes a change in the validity period. 753 Example query response: 755 S: 756 S: 757 S: 758 S: 759 S: Command completed successfully 760 S: 761 S: 762 S: 764 S: example.com 765 S: pending 766 S: ClientX 767 S: 2000-06-06T22:00:00.0Z 768 S: ClientY 769 S: 2000-06-11T22:00:00.0Z 770 S: 2002-09-08T22:00:00.0Z 771 S: 772 S: 773 S: 774 S: ABC-12345 775 S: 54322-XYZ 776 S: 777 S: 778 S: 780 An EPP error response MUST be returned if a query command 781 cannot be processed for any reason. 783 3.2. EPP Transform Commands 785 EPP provides five commands to transform domain objects: to 786 create an instance of a domain object, to delete an instance 787 of a domain object, to extend the validity period of a domain 788 object, to manage domain object sponsorship changes, and 789 to change information associated with a domain object. 791 Transform commands are typically processed and completed in real 792 time. Server operators MAY receive and process transform commands, 793 but defer completing the requested action if human or third-party 794 review is required before the requested action can be completed. In 795 such situations the server MUST return a 1001 response code to the 796 client to note that the command has been received and processed, but 797 the requested action is pending. The server MUST also manage the 798 status of the object that is the subject of the command to reflect 799 the initiation and completion of the requested action. Once the 800 action has been completed, all clients involved in the transaction 801 MUST be notified using a service message that the action has been 802 completed and that the status of the object has changed. 804 3.2.1. EPP Command 806 The EPP command provides a transform operation that allows a 807 client to create a domain object. In addition to the standard EPP 808 command elements, the command MUST contain a 809 element that identifies the domain namespace. The 810 element contains the following child elements: 812 - A element that contains the fully qualified name of 813 the domain object to be created. 815 - An OPTIONAL element that contains the initial 816 registration period of the domain object. A server MAY define a 817 default initial registration period if not specified by the 818 client. 820 - An OPTIONAL element that contains the fully qualified 821 names of the delegated host objects or host attributes (name 822 servers) associated with the domain object to provide resolution 823 services for the domain; see Section 1.1 for a description of the 824 elements used to specify host objects or host attributes. A host 825 object MUST be known to the server before the host object can be 826 associated with a domain object. 828 - An OPTIONAL element that contains the 829 identifier for the human or organizational social information 830 (contact) object to be associated with the domain object as the 831 object registrant. This object identifier MUST be known to the 832 server before the contact object can be associated with the domain 833 object. The EPP mapping for contact objects is described in 834 [I-D.hollenbeck-rfc4933bis]. 836 - Zero or more OPTIONAL elements that contain the 837 identifiers for other contact objects to be associated with the 838 domain object. Contact object identifiers MUST be known to the 839 server before the contact object can be associated with the domain 840 object. 842 - A element that contains authorization 843 information to be associated with the domain object. This mapping 844 includes a password-based authentication mechanism, but the schema 845 allows new mechanisms to be defined in new schemas. 847 Example command: 849 C: 850 C: 851 C: 852 C: 853 C: 855 C: example.com 856 C: 2 857 C: 858 C: ns1.example.com 859 C: ns1.example.net 860 C: 861 C: jd1234 862 C: sh8013 863 C: sh8013 864 C: 865 C: 2fooBAR 866 C: 867 C: 868 C: 869 C: ABC-12345 870 C: 871 C: 873 When a command has been processed successfully, the EPP 874 element MUST contain a child element that 875 identifies the domain namespace. The element 876 contains the following child elements: 878 - A element that contains the fully qualified name of 879 the domain object. 881 - A element that contains the date and time of 882 domain object creation. 884 - An OPTIONAL element that contains the date and 885 time identifying the end of the domain object's registration 886 period. 888 Example response: 890 S: 891 S: 892 S: 893 S: 894 S: Command completed successfully 895 S: 896 S: 897 S: 899 S: example.com 900 S: 1999-04-03T22:00:00.0Z 901 S: 2001-04-03T22:00:00.0Z 902 S: 903 S: 904 S: 905 S: ABC-12345 906 S: 54321-XYZ 907 S: 908 S: 909 S: 911 An EPP error response MUST be returned if a command cannot 912 be processed for any reason. 914 3.2.2. EPP Command 916 The EPP command provides a transform operation that allows a 917 client to delete a domain object. In addition to the standard EPP 918 command elements, the command MUST contain a 919 element that identifies the domain namespace. The 920 element contains the following child elements: 922 - A element that contains the fully qualified name of 923 the domain object to be deleted. 925 A domain object SHOULD NOT be deleted if subordinate host objects are 926 associated with the domain object. For example, if domain 927 "example.com" exists, and host object "ns1.example.com" also exists, 928 then domain "example.com" SHOULD NOT be deleted until host 929 "ns1.example.com" has been either deleted or renamed to exist in a 930 different superordinate domain. A server SHOULD notify clients that 931 object relationships exist by sending a 2305 error response code when 932 a command is attempted and fails due to existing object 933 relationships. Delegated and subordinate host objects associated 934 with a domain object can be determined using the query command 935 for the domain object. 937 Example command: 939 C: 940 C: 941 C: 942 C: 943 C: 945 C: example.com 946 C: 947 C: 948 C: ABC-12345 949 C: 950 C: 952 When a command has been processed successfully, a server 953 MUST respond with an EPP response with no element. 955 Example response: 957 S: 958 S: 959 S: 960 S: 961 S: Command completed successfully 962 S: 963 S: 964 S: ABC-12345 965 S: 54321-XYZ 966 S: 967 S: 968 S: 970 An EPP error response MUST be returned if a command cannot 971 be processed for any reason. 973 3.2.3. EPP Command 975 The EPP command provides a transform operation that allows a 976 client to extend the validity period of a domain object. In addition 977 to the standard EPP command elements, the command MUST 978 contain a element that identifies the domain 979 namespace. The element contains the following child 980 elements: 982 - A element that contains the fully qualified name of 983 the domain object whose validity period is to be extended. 985 - A element that contains the date on which the 986 current validity period ends. This value ensures that repeated 987 commands do not result in multiple unanticipated 988 successful renewals. 990 - An OPTIONAL element that contains the number of 991 units to be added to the registration period of the domain object. 992 The number of units available MAY be subject to limits imposed by 993 the server. 995 Example command: 997 C: 998 C: 999 C: 1000 C: 1001 C: 1003 C: example.com 1004 C: 2000-04-03 1005 C: 5 1006 C: 1007 C: 1008 C: ABC-12345 1009 C: 1010 C: 1012 When a command has been processed successfully, the EPP 1013 element MUST contain a child element that 1014 identifies the domain namespace. The element 1015 contains the following child elements: 1017 - A element that contains the fully qualified name of 1018 the domain object. 1020 - An OPTIONAL element that contains the date and 1021 time identifying the end of the domain object's registration 1022 period. 1024 Example response: 1026 S: 1027 S: 1028 S: 1029 S: 1030 S: Command completed successfully 1031 S: 1032 S: 1033 S: 1035 S: example.com 1036 S: 2005-04-03T22:00:00.0Z 1037 S: 1038 S: 1039 S: 1040 S: ABC-12345 1041 S: 54322-XYZ 1042 S: 1043 S: 1044 S: 1046 An EPP error response MUST be returned if a command cannot be 1047 processed for any reason. 1049 3.2.4. EPP Command 1051 The EPP command provides a transform operation that allows 1052 a client to manage requests to transfer the sponsorship of a domain 1053 object. In addition to the standard EPP command elements, the 1054 command MUST contain a element that 1055 identifies the domain namespace. The element 1056 contains the following child elements: 1058 - A element that contains the fully qualified name of 1059 the domain object for which a transfer request is to be created, 1060 approved, rejected, or cancelled. 1062 - An OPTIONAL element that contains the number of 1063 units to be added to the registration period of the domain object 1064 at completion of the transfer process. This element can only be 1065 used when a transfer is requested, and it MUST be ignored if used 1066 otherwise. The number of units available MAY be subject to limits 1067 imposed by the server. 1069 - A element that contains authorization 1070 information associated with the domain object or authorization 1071 information associated with the domain object's registrant or 1072 associated contacts. An OPTIONAL "roid" attribute MUST be used to 1073 identify the registrant or contact object if and only if the given 1074 authInfo is associated with a registrant or contact object, and 1075 not the domain object itself. 1077 Every EPP command MUST contain an "op" attribute that 1078 identifies the transfer operation to be performed. Valid values, 1079 definitions, and authorizations for all attribute values are defined 1080 in [I-D.hollenbeck-rfc4930bis]. 1082 Transfer of a domain object MUST implicitly transfer all host objects 1083 that are subordinate to the domain object. For example, if domain 1084 object "example.com" is transferred and host object "ns1.example.com" 1085 exists, the host object MUST be transferred as part of the 1086 "example.com" transfer process. Host objects that are subject to 1087 transfer when transferring a domain object are listed in the response 1088 to an EPP command performed on the domain object. 1090 Example request command: 1092 C: 1093 C: 1094 C: 1095 C: 1096 C: 1098 C: example.com 1099 C: 1 1100 C: 1101 C: 2fooBAR 1102 C: 1103 C: 1104 C: 1105 C: ABC-12345 1106 C: 1107 C: 1109 When a command has been processed successfully, the EPP 1110 element MUST contain a child element that 1111 identifies the domain namespace. The element 1112 contains the same child elements defined for a transfer query 1113 response. 1115 Example response: 1117 S: 1118 S: 1119 S: 1120 S: 1121 S: Command completed successfully; action pending 1122 S: 1123 S: 1124 S: 1126 S: example.com 1127 S: pending 1128 S: ClientX 1129 S: 2000-06-08T22:00:00.0Z 1130 S: ClientY 1131 S: 2000-06-13T22:00:00.0Z 1132 S: 2002-09-08T22:00:00.0Z 1133 S: 1134 S: 1135 S: 1136 S: ABC-12345 1137 S: 54322-XYZ 1138 S: 1139 S: 1140 S: 1142 An EPP error response MUST be returned if a command can 1143 not be processed for any reason. 1145 3.2.5. EPP Command 1147 The EPP command provides a transform operation that allows a 1148 client to modify the attributes of a domain object. In addition to 1149 the standard EPP command elements, the command MUST contain 1150 a element that identifies the domain namespace. The 1151 element contains the following child elements: 1153 - A element that contains the fully qualified name of 1154 the domain object to be updated. 1156 - An OPTIONAL element that contains attribute values to 1157 be added to the object. 1159 - An OPTIONAL element that contains attribute values to 1160 be removed from the object. 1162 - An OPTIONAL element that contains object attribute 1163 values to be changed. 1165 At least one , , or element MUST 1166 be provided if the command is not being extended. All of these 1167 elements MAY be omitted if an extension is present. The 1168 and elements contain the following child 1169 elements: 1171 - An OPTIONAL element that contains the fully qualified 1172 names of the delegated host objects or host attributes (name 1173 servers) associated with the domain object to provide resolution 1174 services for the domain; see Section 1.1 for a description of the 1175 elements used to specify host objects or host attributes. A host 1176 object MUST be known to the server before the host object can be 1177 associated with a domain object. If host attributes are used to 1178 specify name servers, note that IP address elements are not needed 1179 to identify a name server that is being removed. IP address 1180 elements can safely be absent or ignored in this situation. 1182 - Zero or more elements that contain the 1183 identifiers for contact objects to be associated with or removed 1184 from the domain object. Contact object identifiers MUST be known 1185 to the server before the contact object can be associated with the 1186 domain object. 1188 - Zero or more elements that contain status values 1189 to be applied to or removed from the object. When specifying a 1190 value to be removed, only the attribute value is significant; 1191 element text is not required to match a value for removal. 1193 A element contains the following child elements: 1195 - A element that contains the identifier for the 1196 human or organizational social information (contact) object to be 1197 associated with the domain object as the object registrant. This 1198 object identifier MUST be known to the server before the contact 1199 object can be associated with the domain object. An empty element 1200 can be used to remove registrant information. 1202 - A element that contains authorization 1203 information associated with the domain object. This mapping 1204 includes a password-based authentication mechanism, but the schema 1205 allows new mechanisms to be defined in new schemas. A element can be used within the element to 1207 remove authorization information. 1209 Example command: 1211 C: 1212 C: 1213 C: 1214 C: 1215 C: 1217 C: example.com 1218 C: 1219 C: 1220 C: ns2.example.com 1221 C: 1222 C: mak21 1223 C: Payment overdue. 1225 C: 1226 C: 1227 C: 1228 C: ns1.example.com 1229 C: 1230 C: sh8013 1231 C: 1232 C: 1233 C: 1234 C: sh8013 1235 C: 1236 C: 2BARfoo 1237 C: 1238 C: 1239 C: 1240 C: 1241 C: ABC-12345 1242 C: 1243 C: 1245 When an command has been processed successfully, a server 1246 MUST respond with an EPP response with no element. 1248 Example response: 1250 S: 1251 S: 1252 S: 1253 S: 1254 S: Command completed successfully 1255 S: 1256 S: 1257 S: ABC-12345 1258 S: 54321-XYZ 1259 S: 1260 S: 1261 S: 1263 An EPP error response MUST be returned if an command cannot 1264 be processed for any reason. 1266 3.3. Offline Review of Requested Actions 1268 Commands are processed by a server in the order they are received 1269 from a client. Though an immediate response confirming receipt and 1270 processing of the command is produced by the server, a server 1271 operator MAY perform an offline review of requested transform 1272 commands before completing the requested action. In such situations, 1273 the response from the server MUST clearly note that the transform 1274 command has been received and processed, but the requested action is 1275 pending. The status of the corresponding object MUST clearly reflect 1276 processing of the pending action. The server MUST notify the client 1277 when offline processing of the action has been completed. 1279 Examples describing a command that requires offline review 1280 are included here. Note the result code and message returned in 1281 response to the command. 1283 S: 1284 S: 1285 S: 1286 S: 1287 S: Command completed successfully; action pending 1288 S: 1289 S: 1290 S: 1292 S: example.com 1293 S: 1999-04-03T22:00:00.0Z 1294 S: 2001-04-03T22:00:00.0Z 1295 S: 1296 S: 1297 S: 1298 S: ABC-12345 1299 S: 54321-XYZ 1300 S: 1301 S: 1302 S: 1304 The status of the domain object after returning this response MUST 1305 include "pendingCreate". The server operator reviews the request 1306 offline, and informs the client of the outcome of the review either 1307 by queuing a service message for retrieval via the command or 1308 by using an out-of-band mechanism to inform the client of the 1309 request. 1311 The service message MUST contain text in the , , 1312 element that describes the notification. In addition, the EPP 1313 element MUST contain a child element that 1314 identifies the domain namespace. The element 1315 contains the following child elements: 1317 - A element that contains the fully qualified name of 1318 the domain object. The element contains a REQUIRED 1319 "paResult" attribute. A positive boolean value indicates that the 1320 request has been approved and completed. A negative boolean value 1321 indicates that the request has been denied and the requested 1322 action has not been taken. 1324 - A element that contains the client transaction 1325 identifier and server transaction identifier returned with the 1326 original response to process the command. The client transaction 1327 identifier is OPTIONAL and will only be returned if the client 1328 provided an identifier with the original command. 1330 - A element that contains the date and time 1331 describing when review of the requested action was completed. 1333 Example "review completed" service message: 1335 S: 1336 S: 1337 S: 1338 S: 1339 S: Command completed successfully; ack to dequeue 1340 S: 1341 S: 1342 S: 1999-04-04T22:01:00.0Z 1343 S: Pending action completed successfully. 1344 S: 1345 S: 1346 S: 1348 S: example.com 1349 S: 1350 S: ABC-12345 1351 S: 54321-XYZ 1352 S: 1353 S: 1999-04-04T22:00:00.0Z 1354 S: 1355 S: 1356 S: 1357 S: BCD-23456 1358 S: 65432-WXY 1359 S: 1360 S: 1361 S: 1363 4. Formal Syntax 1365 An EPP object mapping is specified in XML Schema notation. The 1366 formal syntax presented here is a complete schema representation of 1367 the object mapping suitable for automated validation of EPP XML 1368 instances. The BEGIN and END tags are not part of the schema; they 1369 are used to note the beginning and ending of the schema for URI 1370 registration purposes. 1372 BEGIN 1373 1375 1383 1386 1387 1388 1390 1391 1392 Extensible Provisioning Protocol v1.0 1393 domain provisioning schema. 1394 1395 1397 1400 1401 1402 1403 1404 1405 1406 1407 1410 1411 1412 1413 1415 1417 1419 1421 1422 1423 1425 1426 1427 1428 1430 1431 1432 1434 1435 1436 1437 1438 1439 1441 1442 1443 1444 1445 1446 1448 1449 1450 1452 1454 1455 1456 1460 1461 1462 1463 1465 1466 1467 1472 1473 1474 1475 1476 1477 1478 1480 1481 1482 1483 1484 1485 1486 1488 1489 1490 1491 1492 1493 1495 1498 1499 1500 1501 1502 1503 1506 1507 1508 1510 1511 1513 1516 1517 1518 1519 1521 1523 1525 1526 1527 1528 1530 1531 1532 1534 1535 1536 1537 1538 1539 1540 1541 1543 1546 1547 1548 1549 1550 1552 1553 1555 1558 1559 1560 1561 1563 1565 1566 1568 1571 1572 1573 1574 1576 1578 1580 1581 1583 1586 1587 1588 1590 1592 1594 1595 1597 1600 1601 1602 1604 1606 1607 1609 1613 1614 1615 1616 1617 1618 1619 1623 1624 1625 1626 1627 1628 1629 1631 1634 1635 1636 1637 1638 1639 1641 1644 1645 1646 1648 1649 1651 1652 1653 1654 1656 1657 1659 1660 1661 1662 1664 1665 1666 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 1712 1714 1719 1720 1721 1722 1724 1726 1727 1728 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1752 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1767 1768 1769 1771 1774 1775 1776 1777 1779 1780 1782 1785 1786 1787 1788 1789 1790 1791 1792 1793 1795 1796 1798 1801 1802 END 1804 5. Internationalization Considerations 1806 EPP is represented in XML, which provides native support for encoding 1807 information using the Unicode character set and its more compact 1808 representations including UTF-8. Conformant XML processors recognize 1809 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1810 identify and use other character encodings through use of an 1811 "encoding" attribute in an declaration, use of UTF-8 is 1812 RECOMMENDED in environments where parser encoding support 1813 incompatibility exists. 1815 All date-time values presented via EPP MUST be expressed in Universal 1816 Coordinated Time using the Gregorian calendar. XML Schema allows use 1817 of time zone identifiers to indicate offsets from the zero meridian, 1818 but this option MUST NOT be used with EPP. The extended date-time 1819 form using upper case "T" and "Z" characters defined in 1820 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1821 values as XML Schema does not support truncated date-time forms or 1822 lower case "T" and "Z" characters. 1824 This document requires domain and host name syntax as specified in 1825 [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 1826 3490 [RFC3490] describes a standard to use certain ASCII name labels 1827 to represent non-ASCII name labels. These conformance requirements 1828 might change as a result of progressing work in developing standards 1829 for internationalized domain names. 1831 6. IANA Considerations 1833 This document uses URNs to describe XML namespaces and XML schemas 1834 conforming to a registry mechanism described in [RFC3688]. Two URI 1835 assignments have been registered by the IANA. 1837 Registration request for the domain namespace: 1839 URI: urn:ietf:params:xml:ns:domain-1.0 1841 Registrant Contact: See the "Author's Address" section of this 1842 document. 1844 XML: None. Namespace URIs do not represent an XML specification. 1846 Registration request for the domain XML schema: 1848 URI: urn:ietf:params:xml:schema:domain-1.0 1850 Registrant Contact: See the "Author's Address" section of this 1851 document. 1853 XML: See the "Formal Syntax" section of this document. 1855 7. Security Considerations 1857 Authorization information as described in section 2.6 is REQUIRED to 1858 create a domain object. This information is used in some query and 1859 transfer operations as an additional means of determining client 1860 authorization to perform the command. Failure to protect 1861 authorization information from inadvertent disclosure can result in 1862 unauthorized transfer operations and unauthorized information 1863 release. Both client and server MUST ensure that authorization 1864 information is stored and exchanged with high-grade encryption 1865 mechanisms to provide privacy services. 1867 The object mapping described in this document does not provide any 1868 other security services or introduce any additional considerations 1869 beyond those described by [I-D.hollenbeck-rfc4930bis] and protocol 1870 layers used by EPP. 1872 8. Acknowledgements 1874 This document was originally written as an individual submission 1875 Internet-Draft. The PROVREG working group later adopted it as a 1876 working group document and provided many invaluable comments and 1877 suggested improvements. The author wishes to acknowledge the efforts 1878 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1879 editorial contributions. 1881 Specific suggestions that have been incorporated into this document 1882 were provided by Joe Abley, Chris Bason, Eric Brunner-Williams, 1883 Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1884 El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick 1885 Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson. 1887 9. References 1889 9.1. Normative References 1891 [I-D.hollenbeck-rfc4930bis] 1892 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1893 draft-hollenbeck-rfc4930bis-00 (work in progress), 1894 April 2009. 1896 [I-D.hollenbeck-rfc4932bis] 1897 Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1898 Host Mapping", draft-hollenbeck-rfc4932bis-00 (work in 1899 progress), April 2009. 1901 [I-D.hollenbeck-rfc4933bis] 1902 Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1903 Contact Mapping", draft-hollenbeck-rfc4933bis-00 (work in 1904 progress), April 2009. 1906 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1907 host table specification", RFC 952, October 1985. 1909 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1910 and Support", STD 3, RFC 1123, October 1989. 1912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1913 Requirement Levels", BCP 14, RFC 2119, March 1997. 1915 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1916 January 2004. 1918 [W3C.REC-xml-20040204] 1919 Maler, E., Sperberg-McQueen, C., Paoli, J., Yergeau, F., 1920 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1921 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1922 20040204, February 2004, 1923 . 1925 [W3C.REC-xmlschema-1-20041028] 1926 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 1927 "XML Schema Part 1: Structures Second Edition", World Wide 1928 Web Consortium Recommendation REC-xmlschema-1-20041028, 1929 October 2004, 1930 . 1932 [W3C.REC-xmlschema-2-20041028] 1933 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1934 Second Edition", World Wide Web Consortium 1935 Recommendation REC-xmlschema-2-20041028, October 2004, 1936 . 1938 9.2. Informative References 1940 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1941 10646", RFC 2781, February 2000. 1943 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1944 "Internationalizing Domain Names in Applications (IDNA)", 1945 RFC 3490, March 2003. 1947 [RFC4931] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1948 Domain Name Mapping", RFC 4931, May 2007. 1950 Appendix A. Changes from RFC 4931 1952 1. Changed "This document obsoletes RFC 3731" to "This document is 1953 intended to obsolete RFC 4931". 1954 2. Replaced references to RFC 3731 with references to 4931. 1955 3. Replaced references to RFC 4930 with references to 4930bis. 1956 4. Replaced references to RFC 4932 with references to 4932bis. 1957 5. Replaced references to RFC 4933 with references to 4933bis. 1959 Author's Address 1961 Scott Hollenbeck 1962 VeriSign, Inc. 1963 21345 Ridgetop Circle 1964 Dulles, VA 20166-6503 1965 US 1967 EMail: shollenbeck@verisign.com