idnits 2.17.1 draft-hollenbeck-rfc4931bis-01.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 (May 14, 2009) is 5454 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 (-02) exists of draft-hollenbeck-rfc4930bis-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4930bis' -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4932bis' == Outdated reference: A later version (-02) exists of draft-hollenbeck-rfc4933bis-01 -- 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 (~~), 4 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) May 14, 2009 5 Intended status: Standards Track 6 Expires: November 15, 2009 8 Extensible Provisioning Protocol (EPP) Domain Name Mapping 9 draft-hollenbeck-rfc4931bis-01 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 November 15, 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.net 168 ns2.example.net 169 170 Example host attribute name server elements for domain example.com: 172 173 174 ns1.example.net 175 192.0.2.2 177 1080:0:0:0:8:800:200C:417A 179 180 181 ns2.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. 274 This is the default status when a domain object is first created 275 and there are no associated host objects for the DNS delegation. 276 This status can also be set by the server when all host object 277 associations are removed. 279 - ok 281 This is the normal status value for an object that has no pending 282 operations or prohibitions. This value is set and removed by the 283 server as other status values are added or removed. 285 - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, 286 pendingUpdate 288 A transform command has been processed for the object, but the 289 action has not been completed by the server. Server operators can 290 delay action completion for a variety of reasons, such as to allow 291 for human review or third-party action. A transform command that 292 is processed, but whose requested action is pending, is noted with 293 response code 1001. 295 When the requested action has been completed, the pendingCreate, 296 pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status 297 value MUST be removed. All clients involved in the transaction MUST 298 be notified using a service message that the action has been 299 completed and that the status of the object has changed. 301 "ok" status MUST NOT be combined with any other status. 303 "pendingDelete" status MUST NOT be combined with either 304 "clientDeleteProhibited" or "serverDeleteProhibited" status. 306 "pendingRenew" status MUST NOT be combined with either 307 "clientRenewProhibited" or "serverRenewProhibited" status. 309 "pendingTransfer" status MUST NOT be combined with either 310 "clientTransferProhibited" or "serverTransferProhibited" status. 312 "pendingUpdate" status MUST NOT be combined with either 313 "clientUpdateProhibited" or "serverUpdateProhibited" status. 315 The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and 316 pendingUpdate status values MUST NOT be combined with each other. 318 Other status combinations not expressly prohibited MAY be used. 320 2.4. Dates and Times 322 Date and time attribute values MUST be represented in Universal 323 Coordinated Time (UTC) using the Gregorian calendar. The extended 324 date-time form using upper case "T" and "Z" characters defined in 325 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 326 values as XML Schema does not support truncated date-time forms or 327 lower case "T" and "Z" characters. 329 2.5. Validity Periods 331 A domain name object MAY have a specified validity period. If server 332 policy supports domain object validity periods, the validity period 333 is defined when a domain object is created, and it MAY be extended by 334 the EPP or commands. As a matter of server 335 policy, this specification does not define actions to be taken upon 336 expiration of a domain object's validity period. 338 Validity periods are measured in years or months with the appropriate 339 units specified using the "unit" attribute. Valid values for the 340 "unit" attribute are "y" for years and "m" for months. The minimum 341 allowable period value is one (1). The maximum allowable value is 342 ninety-nine decimal (99). A server MAY support a lower maximum 343 value. 345 2.6. Authorization Information 347 Authorization information is associated with domain objects to 348 facilitate transfer operations. Authorization information is 349 assigned when a domain object is created, and it might be updated in 350 the future. This specification describes password-based 351 authorization information, though other mechanisms are possible. 353 2.7. Other DNS Resource Record Attributes 355 While the DNS allows many resource record types to be associated with 356 a domain, this mapping only explicitly specifies elements that 357 describe resource records used for domain delegation and resolution. 358 Facilities to provision other domain-related resource record types 359 can be developed by extending this mapping. 361 The provisioning method described in this mapping separates discrete 362 data elements by data type. This method of data definition allows 363 XML Schema processors to perform basic syntax validation tasks, 364 reducing ambiguity and the amount of parsing and syntax-checking work 365 required of protocol processors. Provisioning and extension methods 366 that aggregate data into opaque strings are possible, but such 367 methods should not be used because they impose additional parsing, 368 interpretation, and validation requirements on protocol processors. 370 3. EPP Command Mapping 372 A detailed description of the EPP syntax and semantics can be found 373 in [I-D.hollenbeck-rfc4930bis]. The command mappings described here 374 are specifically for use in provisioning and managing Internet domain 375 names via EPP. 377 3.1. EPP Query Commands 379 EPP provides three commands to retrieve domain information: 380 to determine if a domain object can be provisioned within a 381 repository, to retrieve detailed information associated with a 382 domain object, and to retrieve domain object transfer 383 status information. 385 3.1.1. EPP Command 387 The EPP command is used to determine if an object can be 388 provisioned within a repository. It provides a hint that allows a 389 client to anticipate the success or failure of provisioning an object 390 using the command as object provisioning requirements are 391 ultimately a matter of server policy. 393 In addition to the standard EPP command elements, the command 394 MUST contain a element that identifies the domain 395 namespace. The element contains the following child 396 elements: 398 - One or more elements that contain the fully 399 qualified names of the domain objects to be queried. 401 Example command: 403 C: 404 C: 405 C: 406 C: 407 C: 409 C: example.com 410 C: example.net 411 C: example.org 412 C: 413 C: 414 C: ABC-12345 415 C: 416 C: 418 When a command has been processed successfully, the EPP 419 element MUST contain a child element that 420 identifies the domain namespace. The element 421 contains one or more elements that contain the following 422 child elements: 424 - A element that contains the fully qualified name of 425 the queried domain object. This element MUST contain an "avail" 426 attribute whose value indicates object availability (can it be 427 provisioned or not) at the moment the command was 428 completed. A value of "1" or "true" means that the object can be 429 provisioned. A value of "0" or "false" means that the object can 430 not be provisioned. 432 - An OPTIONAL element that MAY be provided when an 433 object cannot be provisioned. If present, this element contains 434 server-specific text to help explain why the object cannot be 435 provisioned. This text MUST be represented in the response 436 language previously negotiated with the client; an OPTIONAL "lang" 437 attribute MAY be present to identify the language if the 438 negotiated value is something other than the default value of "en" 439 (English). 441 Example response: 443 S: 444 S: 445 S: 446 S: 447 S: Command completed successfully 448 S: 449 S: 450 S: 452 S: 453 S: example.com 454 S: 455 S: 456 S: example.net 457 S: In use 458 S: 459 S: 460 S: example.org 461 S: 462 S: 463 S: 464 S: 465 S: ABC-12345 466 S: 54322-XYZ 467 S: 468 S: 469 S: 471 An EPP error response MUST be returned if a command cannot be 472 processed for any reason. 474 3.1.2. EPP Command 476 The EPP command is used to retrieve information associated 477 with a domain object. The response to this command MAY vary 478 depending on the identity of the querying client, use of 479 authorization information, and server policy towards unauthorized 480 clients. If the querying client is the sponsoring client, all 481 available information MUST be returned. If the querying client is 482 not the sponsoring client, but the client provides valid 483 authorization information, all available information MUST be 484 returned. If the querying client is not the sponsoring client, and 485 the client does not provide valid authorization information, server 486 policy determines which OPTIONAL elements are returned. 488 In addition to the standard EPP command elements, the command 489 MUST contain a element that identifies the domain 490 namespace. The element contains the following child 491 elements: 493 - A element that contains the fully qualified name of 494 the domain object to be queried. An OPTIONAL "hosts" attribute is 495 available to control return of information describing hosts 496 related to the domain object. A value of "all" (the default, 497 which MAY be absent) returns information describing both 498 subordinate and delegated hosts. A value of "del" returns 499 information describing only delegated hosts. A value of "sub" 500 returns information describing only subordinate hosts. A value of 501 "none" returns no information describing delegated or subordinate 502 hosts. 504 - An OPTIONAL element that contains authorization 505 information associated with the domain object or authorization 506 information associated with the domain object's registrant or 507 associated contacts. An OPTIONAL "roid" attribute MUST be used to 508 identify the registrant or contact object if and only if the given 509 authInfo is associated with a registrant or contact object, and 510 not the domain object itself. If this element is not provided or 511 if the authorization information is invalid, server policy 512 determines if the command is rejected or if response information 513 will be returned to the client. 515 Example command without authorization information: 517 C: 518 C: 519 C: 520 C: 521 C: 523 C: example.com 524 C: 525 C: 526 C: ABC-12345 527 C: 528 C: 529 Example command with authorization information: 531 C: 532 C: 533 C: 534 C: 535 C: 537 C: example.com 538 C: 539 C: 2fooBAR 540 C: 541 C: 542 C: 543 C: ABC-12345 544 C: 545 C: 547 When an command has been processed successfully, the EPP 548 element MUST contain a child element that 549 identifies the domain namespace. Elements that are not OPTIONAL MUST 550 be returned; OPTIONAL elements are returned based on client 551 authorization and server policy. The element 552 contains the following child elements: 554 - A element that contains the fully qualified name of 555 the domain object. 557 - A element that contains the Repository Object 558 IDentifier assigned to the domain object when the object was 559 created. 561 - Zero or more OPTIONAL elements that contain the 562 current status descriptors associated with the domain. 564 - If supported by the server, one OPTIONAL 565 element and one or more OPTIONAL elements that 566 contain identifiers for the human or organizational social 567 information objects associated with the domain object. 569 - An OPTIONAL element that contains the fully qualified 570 names of the delegated host objects or host attributes (name 571 servers) associated with the domain object. See Section 1.1 for a 572 description of the elements used to specify host objects or host 573 attributes. 575 - Zero or more OPTIONAL elements that contain the 576 fully qualified names of the subordinate host objects that exist 577 under this superordinate domain object. 579 - A element that contains the identifier of the 580 sponsoring client. 582 - An OPTIONAL element that contains the identifier of 583 the client that created the domain object. 585 - An OPTIONAL element that contains the date and 586 time of domain object creation. 588 - An OPTIONAL element that contains the date and 589 time identifying the end of the domain object's registration 590 period. 592 - An OPTIONAL element that contains the identifier of 593 the client that last updated the domain object. This element MUST 594 NOT be present if the domain has never been modified. 596 - An OPTIONAL element that contains the date and 597 time of the most recent domain object modification. This element 598 MUST NOT be present if the domain object has never been modified. 600 - An OPTIONAL elements that contains the date and 601 time of the most recent successful domain object transfer. This 602 element MUST NOT be provided if the domain object has never been 603 transferred. 605 - An OPTIONAL element that contains authorization 606 information associated with the domain object. This element MUST 607 only be returned if the querying client is the current sponsoring 608 client, or if the client supplied valid authorization information 609 with the command. 611 Example response for an authorized client: 613 S: 614 S: 615 S: 616 S: 617 S: Command completed successfully 618 S: 619 S: 620 S: 622 S: example.com 623 S: EXAMPLE1-REP 624 S: 625 S: jd1234 626 S: sh8013 627 S: sh8013 628 S: 629 S: ns1.example.com 630 S: ns1.example.net 631 S: 632 S: ns1.example.com 633 S: ns2.example.com 634 S: ClientX 635 S: ClientY 636 S: 1999-04-03T22:00:00.0Z 637 S: ClientX 638 S: 1999-12-03T09:00:00.0Z 639 S: 2005-04-03T22:00:00.0Z 640 S: 2000-04-08T09:00:00.0Z 641 S: 642 S: 2fooBAR 643 S: 644 S: 645 S: 646 S: 647 S: ABC-12345 648 S: 54322-XYZ 649 S: 650 S: 651 S: 653 A server with a different information return policy MAY provide less 654 information in a response. 656 Example response for an unauthorized client: 658 S: 659 S: 660 S: 661 S: 662 S: Command completed successfully 663 S: 664 S: 665 S: 667 S: example.com 668 S: EXAMPLE1-REP 669 S: ClientX 670 S: 671 S: 672 S: 673 S: ABC-12345 674 S: 54322-XYZ 675 S: 676 S: 677 S: 679 An EPP error response MUST be returned if an command cannot be 680 processed for any reason. 682 3.1.3. EPP Query Command 684 The EPP command provides a query operation that allows a 685 client to determine real-time status of pending and completed 686 transfer requests. In addition to the standard EPP command elements, 687 the command MUST contain an "op" attribute with value 688 "query", and a element that identifies the domain 689 namespace. The element contains the following 690 child elements: 692 - A element that contains the fully qualified name of 693 the domain object to be queried. 695 - An OPTIONAL element that contains authorization 696 information associated with the domain object or authorization 697 information associated with the domain object's registrant or 698 associated contacts. An OPTIONAL "roid" attribute MUST be used to 699 identify the registrant or contact object if and only if the given 700 authInfo is associated with a registrant or contact object, and 701 not the domain object itself. If this element is not provided or 702 if the authorization information is invalid, server policy 703 determines if the command is rejected or if response information 704 will be returned to the client. 706 Example query command: 708 C: 709 C: 710 C: 711 C: 712 C: 714 C: example.com 715 C: 716 C: 2fooBAR 717 C: 718 C: 719 C: 720 C: ABC-12345 721 C: 722 C: 724 When a query command has been processed successfully, the 725 EPP element MUST contain a child element 726 that identifies the domain namespace. The element 727 contains the following child elements: 729 - A element that contains the fully qualified name of 730 the domain object. 732 - A element that contains the state of the most 733 recent transfer request. 735 - A element that contains the identifier of the client 736 that requested the object transfer. 738 - A element that contains the date and time that the 739 transfer was requested. 741 - A element that contains the identifier of the client 742 that SHOULD act upon a PENDING transfer request. For all other 743 status types, the value identifies the client that took the 744 indicated action. 746 - A element that contains the date and time of a 747 required or completed response. For a PENDING request, the value 748 identifies the date and time by which a response is required 749 before an automated response action will be taken by the server. 750 For all other status types, the value identifies the date and time 751 when the request was completed. 753 - An OPTIONAL element that contains the end of the 754 domain object's validity period if the command caused 755 or causes a change in the validity period. 757 Example query response: 759 S: 760 S: 761 S: 762 S: 763 S: Command completed successfully 764 S: 765 S: 766 S: 768 S: example.com 769 S: pending 770 S: ClientX 771 S: 2000-06-06T22:00:00.0Z 772 S: ClientY 773 S: 2000-06-11T22:00:00.0Z 774 S: 2002-09-08T22:00:00.0Z 775 S: 776 S: 777 S: 778 S: ABC-12345 779 S: 54322-XYZ 780 S: 781 S: 782 S: 784 An EPP error response MUST be returned if a query command 785 cannot be processed for any reason. 787 3.2. EPP Transform Commands 789 EPP provides five commands to transform domain objects: to 790 create an instance of a domain object, to delete an instance 791 of a domain object, to extend the validity period of a domain 792 object, to manage domain object sponsorship changes, and 793 to change information associated with a domain object. 795 Transform commands are typically processed and completed in real 796 time. Server operators MAY receive and process transform commands, 797 but defer completing the requested action if human or third-party 798 review is required before the requested action can be completed. In 799 such situations the server MUST return a 1001 response code to the 800 client to note that the command has been received and processed, but 801 the requested action is pending. The server MUST also manage the 802 status of the object that is the subject of the command to reflect 803 the initiation and completion of the requested action. Once the 804 action has been completed, all clients involved in the transaction 805 MUST be notified using a service message that the action has been 806 completed and that the status of the object has changed. Other 807 notification methods MAY be used in addition to the required service 808 message. 810 Server operators SHOULD confirm that a client is authorized to 811 perform a transform command on a given object. Any attempt to 812 transform an object by an unauthorized client MUST be rejected, and 813 the server MUST return a 2201 response code to the client to note 814 that the client lacks privileges to execute the requested command. 816 3.2.1. EPP Command 818 The EPP command provides a transform operation that allows a 819 client to create a domain object. In addition to the standard EPP 820 command elements, the command MUST contain a 821 element that identifies the domain namespace. The 822 element contains the following child elements: 824 - A element that contains the fully qualified name of 825 the domain object to be created. 827 - An OPTIONAL element that contains the initial 828 registration period of the domain object. A server MAY define a 829 default initial registration period if not specified by the 830 client. 832 - An OPTIONAL element that contains the fully qualified 833 names of the delegated host objects or host attributes (name 834 servers) associated with the domain object to provide resolution 835 services for the domain; see Section 1.1 for a description of the 836 elements used to specify host objects or host attributes. A host 837 object MUST be known to the server before the host object can be 838 associated with a domain object. 840 - An OPTIONAL element that contains the 841 identifier for the human or organizational social information 842 (contact) object to be associated with the domain object as the 843 object registrant. This object identifier MUST be known to the 844 server before the contact object can be associated with the domain 845 object. The EPP mapping for contact objects is described in 846 [I-D.hollenbeck-rfc4933bis]. 848 - Zero or more OPTIONAL elements that contain the 849 identifiers for other contact objects to be associated with the 850 domain object. Contact object identifiers MUST be known to the 851 server before the contact object can be associated with the domain 852 object. 854 - A element that contains authorization 855 information to be associated with the domain object. This mapping 856 includes a password-based authentication mechanism, but the schema 857 allows new mechanisms to be defined in new schemas. 859 Example command: 861 C: 862 C: 863 C: 864 C: 865 C: 867 C: example.com 868 C: 2 869 C: 870 C: ns1.example.net 871 C: ns2.example.net 872 C: 873 C: jd1234 874 C: sh8013 875 C: sh8013 876 C: 877 C: 2fooBAR 878 C: 879 C: 880 C: 881 C: ABC-12345 882 C: 883 C: 885 When a command has been processed successfully, the EPP 886 element MUST contain a child element that 887 identifies the domain namespace. The element 888 contains the following child elements: 890 - A element that contains the fully qualified name of 891 the domain object. 893 - A element that contains the date and time of 894 domain object creation. 896 - An OPTIONAL element that contains the date and 897 time identifying the end of the domain object's registration 898 period. 900 Example response: 902 S: 903 S: 904 S: 905 S: 906 S: Command completed successfully 907 S: 908 S: 909 S: 911 S: example.com 912 S: 1999-04-03T22:00:00.0Z 913 S: 2001-04-03T22:00:00.0Z 914 S: 915 S: 916 S: 917 S: ABC-12345 918 S: 54321-XYZ 919 S: 920 S: 921 S: 923 An EPP error response MUST be returned if a command cannot 924 be processed for any reason. 926 3.2.2. EPP Command 928 The EPP command provides a transform operation that allows a 929 client to delete a domain object. In addition to the standard EPP 930 command elements, the command MUST contain a 931 element that identifies the domain namespace. The 932 element contains the following child elements: 934 - A element that contains the fully qualified name of 935 the domain object to be deleted. 937 A domain object SHOULD NOT be deleted if subordinate host objects are 938 associated with the domain object. For example, if domain 939 "example.com" exists, and host object "ns1.example.com" also exists, 940 then domain "example.com" SHOULD NOT be deleted until host 941 "ns1.example.com" has been either deleted or renamed to exist in a 942 different superordinate domain. A server SHOULD notify clients that 943 object relationships exist by sending a 2305 error response code when 944 a command is attempted and fails due to existing object 945 relationships. Delegated and subordinate host objects associated 946 with a domain object can be determined using the query command 947 for the domain object. 949 Example command: 951 C: 952 C: 953 C: 954 C: 955 C: 957 C: example.com 958 C: 959 C: 960 C: ABC-12345 961 C: 962 C: 964 When a command has been processed successfully, a server 965 MUST respond with an EPP response with no element. 967 Example response: 969 S: 970 S: 971 S: 972 S: 973 S: Command completed successfully 974 S: 975 S: 976 S: ABC-12345 977 S: 54321-XYZ 978 S: 979 S: 980 S: 982 An EPP error response MUST be returned if a command cannot 983 be processed for any reason. 985 3.2.3. EPP Command 987 The EPP command provides a transform operation that allows a 988 client to extend the validity period of a domain object. In addition 989 to the standard EPP command elements, the command MUST 990 contain a element that identifies the domain 991 namespace. The element contains the following child 992 elements: 994 - A element that contains the fully qualified name of 995 the domain object whose validity period is to be extended. 997 - A element that contains the date on which the 998 current validity period ends. This value ensures that repeated 999 commands do not result in multiple unanticipated 1000 successful renewals. 1002 - An OPTIONAL element that contains the number of 1003 units to be added to the registration period of the domain object. 1004 The number of units available MAY be subject to limits imposed by 1005 the server. 1007 Example command: 1009 C: 1010 C: 1011 C: 1012 C: 1013 C: 1015 C: example.com 1016 C: 2000-04-03 1017 C: 5 1018 C: 1019 C: 1020 C: ABC-12345 1021 C: 1022 C: 1024 When a command has been processed successfully, the EPP 1025 element MUST contain a child element that 1026 identifies the domain namespace. The element 1027 contains the following child elements: 1029 - A element that contains the fully qualified name of 1030 the domain object. 1032 - An OPTIONAL element that contains the date and 1033 time identifying the end of the domain object's registration 1034 period. 1036 Example response: 1038 S: 1039 S: 1040 S: 1041 S: 1042 S: Command completed successfully 1043 S: 1044 S: 1045 S: 1047 S: example.com 1048 S: 2005-04-03T22:00:00.0Z 1049 S: 1050 S: 1051 S: 1052 S: ABC-12345 1053 S: 54322-XYZ 1054 S: 1055 S: 1056 S: 1058 An EPP error response MUST be returned if a command cannot be 1059 processed for any reason. 1061 3.2.4. EPP Command 1063 The EPP command provides a transform operation that allows 1064 a client to manage requests to transfer the sponsorship of a domain 1065 object. In addition to the standard EPP command elements, the 1066 command MUST contain a element that 1067 identifies the domain namespace. The element 1068 contains the following child elements: 1070 - A element that contains the fully qualified name of 1071 the domain object for which a transfer request is to be created, 1072 approved, rejected, or cancelled. 1074 - An OPTIONAL element that contains the number of 1075 units to be added to the registration period of the domain object 1076 at completion of the transfer process. This element can only be 1077 used when a transfer is requested, and it MUST be ignored if used 1078 otherwise. The number of units available MAY be subject to limits 1079 imposed by the server. 1081 - A element that contains authorization 1082 information associated with the domain object or authorization 1083 information associated with the domain object's registrant or 1084 associated contacts. An OPTIONAL "roid" attribute MUST be used to 1085 identify the registrant or contact object if and only if the given 1086 authInfo is associated with a registrant or contact object, and 1087 not the domain object itself. 1089 Every EPP command MUST contain an "op" attribute that 1090 identifies the transfer operation to be performed. Valid values, 1091 definitions, and authorizations for all attribute values are defined 1092 in [I-D.hollenbeck-rfc4930bis]. 1094 Transfer of a domain object MUST implicitly transfer all host objects 1095 that are subordinate to the domain object. For example, if domain 1096 object "example.com" is transferred and host object "ns1.example.com" 1097 exists, the host object MUST be transferred as part of the 1098 "example.com" transfer process. Host objects that are subject to 1099 transfer when transferring a domain object are listed in the response 1100 to an EPP command performed on the domain object. 1102 Example request command: 1104 C: 1105 C: 1106 C: 1107 C: 1108 C: 1110 C: example.com 1111 C: 1 1112 C: 1113 C: 2fooBAR 1114 C: 1115 C: 1116 C: 1117 C: ABC-12345 1118 C: 1119 C: 1121 When a command has been processed successfully, the EPP 1122 element MUST contain a child element that 1123 identifies the domain namespace. The element 1124 contains the same child elements defined for a transfer query 1125 response. 1127 Example response: 1129 S: 1130 S: 1131 S: 1132 S: 1133 S: Command completed successfully; action pending 1134 S: 1135 S: 1136 S: 1138 S: example.com 1139 S: pending 1140 S: ClientX 1141 S: 2000-06-08T22:00:00.0Z 1142 S: ClientY 1143 S: 2000-06-13T22:00:00.0Z 1144 S: 2002-09-08T22:00:00.0Z 1145 S: 1146 S: 1147 S: 1148 S: ABC-12345 1149 S: 54322-XYZ 1150 S: 1151 S: 1152 S: 1154 An EPP error response MUST be returned if a command can 1155 not be processed for any reason. 1157 3.2.5. EPP Command 1159 The EPP command provides a transform operation that allows a 1160 client to modify the attributes of a domain object. In addition to 1161 the standard EPP command elements, the command MUST contain 1162 a element that identifies the domain namespace. The 1163 element contains the following child elements: 1165 - A element that contains the fully qualified name of 1166 the domain object to be updated. 1168 - An OPTIONAL element that contains attribute values to 1169 be added to the object. 1171 - An OPTIONAL element that contains attribute values to 1172 be removed from the object. 1174 - An OPTIONAL element that contains object attribute 1175 values to be changed. 1177 At least one , , or element MUST 1178 be provided if the command is not being extended. All of these 1179 elements MAY be omitted if an extension is present. The 1180 and elements contain the following child 1181 elements: 1183 - An OPTIONAL element that contains the fully qualified 1184 names of the delegated host objects or host attributes (name 1185 servers) associated with the domain object to provide resolution 1186 services for the domain; see Section 1.1 for a description of the 1187 elements used to specify host objects or host attributes. A host 1188 object MUST be known to the server before the host object can be 1189 associated with a domain object. If host attributes are used to 1190 specify name servers, note that IP address elements are not needed 1191 to identify a name server that is being removed. IP address 1192 elements can safely be absent or ignored in this situation. 1194 - Zero or more elements that contain the 1195 identifiers for contact objects to be associated with or removed 1196 from the domain object. Contact object identifiers MUST be known 1197 to the server before the contact object can be associated with the 1198 domain object. 1200 - Zero or more elements that contain status values 1201 to be applied to or removed from the object. When specifying a 1202 value to be removed, only the attribute value is significant; 1203 element text is not required to match a value for removal. 1205 A element contains the following child elements: 1207 - A element that contains the identifier for the 1208 human or organizational social information (contact) object to be 1209 associated with the domain object as the object registrant. This 1210 object identifier MUST be known to the server before the contact 1211 object can be associated with the domain object. An empty element 1212 can be used to remove registrant information. 1214 - A element that contains authorization 1215 information associated with the domain object. This mapping 1216 includes a password-based authentication mechanism, but the schema 1217 allows new mechanisms to be defined in new schemas. A element can be used within the element to 1219 remove authorization information. 1221 Example command: 1223 C: 1224 C: 1225 C: 1226 C: 1227 C: 1229 C: example.com 1230 C: 1231 C: 1232 C: ns2.example.com 1233 C: 1234 C: mak21 1235 C: Payment overdue. 1237 C: 1238 C: 1239 C: 1240 C: ns1.example.com 1241 C: 1242 C: sh8013 1243 C: 1244 C: 1245 C: 1246 C: sh8013 1247 C: 1248 C: 2BARfoo 1249 C: 1250 C: 1251 C: 1252 C: 1253 C: ABC-12345 1254 C: 1255 C: 1257 When an command has been processed successfully, a server 1258 MUST respond with an EPP response with no element. 1260 Example response: 1262 S: 1263 S: 1264 S: 1265 S: 1266 S: Command completed successfully 1267 S: 1268 S: 1269 S: ABC-12345 1270 S: 54321-XYZ 1271 S: 1272 S: 1273 S: 1275 An EPP error response MUST be returned if an command cannot 1276 be processed for any reason. 1278 3.3. Offline Review of Requested Actions 1280 Commands are processed by a server in the order they are received 1281 from a client. Though an immediate response confirming receipt and 1282 processing of the command is produced by the server, a server 1283 operator MAY perform an offline review of requested transform 1284 commands before completing the requested action. In such situations, 1285 the response from the server MUST clearly note that the transform 1286 command has been received and processed, but the requested action is 1287 pending. The status of the corresponding object MUST clearly reflect 1288 processing of the pending action. The server MUST notify the client 1289 when offline processing of the action has been completed. 1291 Examples describing a command that requires offline review 1292 are included here. Note the result code and message returned in 1293 response to the command. 1295 S: 1296 S: 1297 S: 1298 S: 1299 S: Command completed successfully; action pending 1300 S: 1301 S: 1302 S: 1304 S: example.com 1305 S: 1999-04-03T22:00:00.0Z 1306 S: 2001-04-03T22:00:00.0Z 1307 S: 1308 S: 1309 S: 1310 S: ABC-12345 1311 S: 54321-XYZ 1312 S: 1313 S: 1314 S: 1316 The status of the domain object after returning this response MUST 1317 include "pendingCreate". The server operator reviews the request 1318 offline, and informs the client of the outcome of the review either 1319 by queuing a service message for retrieval via the command or 1320 by using an out-of-band mechanism to inform the client of the 1321 request. 1323 The service message MUST contain text in the , , 1324 element that describes the notification. In addition, the EPP 1325 element MUST contain a child element that 1326 identifies the domain namespace. The element 1327 contains the following child elements: 1329 - A element that contains the fully qualified name of 1330 the domain object. The element contains a REQUIRED 1331 "paResult" attribute. A positive boolean value indicates that the 1332 request has been approved and completed. A negative boolean value 1333 indicates that the request has been denied and the requested 1334 action has not been taken. 1336 - A element that contains the client transaction 1337 identifier and server transaction identifier returned with the 1338 original response to process the command. The client transaction 1339 identifier is OPTIONAL and will only be returned if the client 1340 provided an identifier with the original command. 1342 - A element that contains the date and time 1343 describing when review of the requested action was completed. 1345 Example "review completed" service message: 1347 S: 1348 S: 1349 S: 1350 S: 1351 S: Command completed successfully; ack to dequeue 1352 S: 1353 S: 1354 S: 1999-04-04T22:01:00.0Z 1355 S: Pending action completed successfully. 1356 S: 1357 S: 1358 S: 1360 S: example.com 1361 S: 1362 S: ABC-12345 1363 S: 54321-XYZ 1364 S: 1365 S: 1999-04-04T22:00:00.0Z 1366 S: 1367 S: 1368 S: 1369 S: BCD-23456 1370 S: 65432-WXY 1371 S: 1372 S: 1373 S: 1375 4. Formal Syntax 1377 An EPP object mapping is specified in XML Schema notation. The 1378 formal syntax presented here is a complete schema representation of 1379 the object mapping suitable for automated validation of EPP XML 1380 instances. The BEGIN and END tags are not part of the schema; they 1381 are used to note the beginning and ending of the schema for URI 1382 registration purposes. 1384 BEGIN 1385 1387 1395 1398 1399 1400 1402 1403 1404 Extensible Provisioning Protocol v1.0 1405 domain provisioning schema. 1406 1407 1409 1412 1413 1414 1415 1416 1417 1418 1419 1422 1423 1424 1425 1427 1429 1431 1433 1434 1435 1437 1438 1439 1440 1442 1443 1444 1446 1447 1448 1449 1450 1451 1453 1454 1455 1456 1457 1458 1460 1461 1462 1464 1466 1467 1468 1472 1473 1474 1475 1477 1478 1479 1484 1485 1486 1487 1488 1489 1490 1492 1493 1494 1495 1496 1497 1498 1500 1501 1502 1503 1504 1505 1507 1510 1511 1512 1513 1514 1515 1518 1519 1520 1522 1523 1525 1528 1529 1530 1531 1533 1535 1537 1538 1539 1540 1542 1543 1544 1546 1547 1548 1549 1550 1551 1552 1553 1555 1558 1559 1560 1561 1562 1564 1565 1567 1570 1571 1572 1573 1575 1577 1578 1580 1583 1584 1585 1586 1588 1590 1592 1593 1595 1598 1599 1600 1602 1604 1606 1607 1609 1612 1613 1614 1616 1618 1619 1621 1625 1626 1627 1628 1629 1630 1631 1635 1636 1637 1638 1639 1640 1641 1643 1646 1647 1648 1649 1650 1651 1653 1656 1657 1658 1660 1661 1663 1664 1665 1666 1668 1669 1671 1672 1673 1674 1676 1677 1678 1679 1682 1683 1684 1685 1686 1688 1689 1691 1694 1695 1696 1697 1698 1700 1702 1704 1706 1708 1709 1711 1713 1715 1717 1719 1721 1723 1724 1726 1731 1732 1733 1734 1736 1738 1739 1740 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1764 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1779 1780 1781 1783 1786 1787 1788 1789 1791 1792 1794 1797 1798 1799 1800 1801 1802 1803 1804 1805 1807 1808 1810 1813 1814 END 1816 5. Internationalization Considerations 1818 EPP is represented in XML, which provides native support for encoding 1819 information using the Unicode character set and its more compact 1820 representations including UTF-8. Conformant XML processors recognize 1821 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1822 identify and use other character encodings through use of an 1823 "encoding" attribute in an declaration, use of UTF-8 is 1824 RECOMMENDED in environments where parser encoding support 1825 incompatibility exists. 1827 All date-time values presented via EPP MUST be expressed in Universal 1828 Coordinated Time using the Gregorian calendar. XML Schema allows use 1829 of time zone identifiers to indicate offsets from the zero meridian, 1830 but this option MUST NOT be used with EPP. The extended date-time 1831 form using upper case "T" and "Z" characters defined in 1832 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1833 values as XML Schema does not support truncated date-time forms or 1834 lower case "T" and "Z" characters. 1836 This document requires domain and host name syntax as specified in 1837 [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 1838 3490 [RFC3490] describes a standard to use certain ASCII name labels 1839 to represent non-ASCII name labels. These conformance requirements 1840 might change as a result of progressing work in developing standards 1841 for internationalized domain names. 1843 6. IANA Considerations 1845 This document uses URNs to describe XML namespaces and XML schemas 1846 conforming to a registry mechanism described in [RFC3688]. Two URI 1847 assignments have been registered by the IANA. 1849 Registration request for the domain namespace: 1851 URI: urn:ietf:params:xml:ns:domain-1.0 1853 Registrant Contact: See the "Author's Address" section of this 1854 document. 1856 XML: None. Namespace URIs do not represent an XML specification. 1858 Registration request for the domain XML schema: 1860 URI: urn:ietf:params:xml:schema:domain-1.0 1862 Registrant Contact: See the "Author's Address" section of this 1863 document. 1865 XML: See the "Formal Syntax" section of this document. 1867 7. Security Considerations 1869 Authorization information as described in section 2.6 is REQUIRED to 1870 create a domain object. This information is used in some query and 1871 transfer operations as an additional means of determining client 1872 authorization to perform the command. Failure to protect 1873 authorization information from inadvertent disclosure can result in 1874 unauthorized transfer operations and unauthorized information 1875 release. Both client and server MUST ensure that authorization 1876 information is stored and exchanged with high-grade encryption 1877 mechanisms to provide privacy services. 1879 The object mapping described in this document does not provide any 1880 other security services or introduce any additional considerations 1881 beyond those described by [I-D.hollenbeck-rfc4930bis] and protocol 1882 layers used by EPP. 1884 8. Acknowledgements 1886 This document was originally written as an individual submission 1887 Internet-Draft. The PROVREG working group later adopted it as a 1888 working group document and provided many invaluable comments and 1889 suggested improvements. The author wishes to acknowledge the efforts 1890 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1891 editorial contributions. 1893 Specific suggestions that have been incorporated into this document 1894 were provided by Joe Abley, Chris Bason, Eric Brunner-Williams, 1895 Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1896 El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick 1897 Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson. 1899 9. References 1901 9.1. Normative References 1903 [I-D.hollenbeck-rfc4930bis] 1904 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1905 draft-hollenbeck-rfc4930bis-01 (work in progress), 1906 May 2009. 1908 [I-D.hollenbeck-rfc4932bis] 1909 Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1910 Host Mapping", draft-hollenbeck-rfc4932bis-01 (work in 1911 progress), May 2009. 1913 [I-D.hollenbeck-rfc4933bis] 1914 Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1915 Contact Mapping", draft-hollenbeck-rfc4933bis-01 (work in 1916 progress), May 2009. 1918 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1919 host table specification", RFC 952, October 1985. 1921 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1922 and Support", STD 3, RFC 1123, October 1989. 1924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1925 Requirement Levels", BCP 14, RFC 2119, March 1997. 1927 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1928 January 2004. 1930 [W3C.REC-xml-20040204] 1931 Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., 1932 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1933 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1934 20040204, February 2004, 1935 . 1937 [W3C.REC-xmlschema-1-20041028] 1938 Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, 1939 "XML Schema Part 1: Structures Second Edition", World Wide 1940 Web Consortium Recommendation REC-xmlschema-1-20041028, 1941 October 2004, 1942 . 1944 [W3C.REC-xmlschema-2-20041028] 1945 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1946 Second Edition", World Wide Web Consortium 1947 Recommendation REC-xmlschema-2-20041028, October 2004, 1948 . 1950 9.2. Informative References 1952 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1953 10646", RFC 2781, February 2000. 1955 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1956 "Internationalizing Domain Names in Applications (IDNA)", 1957 RFC 3490, March 2003. 1959 [RFC4931] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1960 Domain Name Mapping", RFC 4931, May 2007. 1962 Appendix A. Changes from RFC 4931 1964 1. Changed "This document obsoletes RFC 3731" to "This document is 1965 intended to obsolete RFC 4931". 1966 2. Replaced references to RFC 3731 with references to 4931. 1967 3. Replaced references to RFC 4930 with references to 4930bis. 1968 4. Replaced references to RFC 4932 with references to 4932bis. 1969 5. Replaced references to RFC 4933 with references to 4933bis. 1970 6. Updated description of inactive status in Section 2.3. 1971 7. Fixed example host names in the Section 1.1 and Section 3.2.1 1972 examples. 1973 8. Changed "but such methods SHOULD NOT be used" to "but such 1974 methods should not be used" in Section 2.7. 1975 9. Added "Other notification methods MAY be used in addition to the 1976 required service message" in Section 3.2. 1977 10. Added 2201 response code text in Section 3.2. 1979 Author's Address 1981 Scott Hollenbeck 1982 VeriSign, Inc. 1983 21345 Ridgetop Circle 1984 Dulles, VA 20166-6503 1985 US 1987 EMail: shollenbeck@verisign.com