idnits 2.17.1 draft-hollenbeck-epp-rfc3732bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1349. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2006) is 6370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Unknown state RFC: RFC 952 -- Obsolete informational reference (is this intentional?): RFC 1886 (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 3152 (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3732 (Obsoleted by RFC 4932) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 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: 3732 (if approved) November 17, 2006 5 Intended status: Standards Track 6 Expires: May 21, 2007 8 Extensible Provisioning Protocol (EPP) Host Mapping 9 draft-hollenbeck-epp-rfc3732bis-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2006). 40 Abstract 42 This document describes an Extensible Provisioning Protocol (EPP) 43 mapping for the provisioning and management of Internet host names 44 stored in a shared central repository. Specified in XML, the mapping 45 defines EPP command syntax and semantics as applied to host names. 46 This document obsoletes RFC 3732 if approved. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Relationship of Host Objects and Domain Objects . . . . . 3 52 1.2. Conventions Used In This Document . . . . . . . . . . . . 3 53 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Host Names . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Client Identifiers . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 4 57 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6 58 2.5. IP Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 6 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . . 8 63 3.1.3. EPP Query Command . . . . . . . . . . . . . 11 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 11 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . . 12 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . . 14 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 15 68 3.2.4. EPP Command . . . . . . . . . . . . . . . . 15 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . . 16 70 3.3. Offline Review of Requested Actions . . . . . . . . . . . 18 71 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20 72 5. Internationalization Considerations . . . . . . . . . . . . . 25 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 79 Appendix A. Changes from RFC 3732 . . . . . . . . . . . . . . . . 29 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 81 Intellectual Property and Copyright Statements . . . . . . . . . . 31 83 1. Introduction 85 This document describes an Internet host name mapping for version 1.0 86 of the Extensible Provisioning Protocol (EPP). This mapping is 87 specified using the Extensible Markup Language (XML) 1.0 as described 88 in [W3C.REC-xml-20040204] and XML Schema notation as described in 89 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 90 This document obsoletes RFC 3732 [RFC3732] if approved. 92 [I-D.hollenbeck-epp-rfc3730bis] provides a complete description of 93 EPP command and response structures. A thorough understanding of the 94 base protocol specification is necessary to understand the mapping 95 described in this document. 97 XML is case sensitive. Unless stated otherwise, XML specifications 98 and examples provided in this document MUST be interpreted in the 99 character case presented to develop a conforming implementation. 101 1.1. Relationship of Host Objects and Domain Objects 103 This document assumes that host name objects have a subordinate 104 relationship to a superordinate domain name object. For example, 105 host name "ns1.example.com" has a subordinate relationship to domain 106 name "example.com". EPP actions (such as object transfers) that do 107 not preserve this relationship MUST be explicitly disallowed. 109 A host name object can be created in a repository for which no 110 superordinate domain name object exists. For example, host name 111 "ns1.example.com" can be created in the ".example" repository so that 112 DNS domains in ".example" can be delegated to the host. Such hosts 113 are described as "external" hosts in this specification since the 114 name of the host does not belong to the name space of the repository 115 in which the host is being used for delegation purposes. 117 Whether a host is external or internal relates to the repository in 118 which the host is being used for delegation purposes. Whether an 119 internal host is subordinate or not relates to a domain within the 120 repository. For example, host ns1.example1.com is a subordinate host 121 of domain example1.com, but it is a not a subordinate host of domain 122 example2.com. ns1.example1.com can be used as a name server for 123 example2.com. In this case, ns1.example1.com MUST be treated as an 124 internal host, subject to the rules governing operations on 125 subordinate hosts within the same repository. 127 1.2. Conventions Used In This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 In examples, "C:" represents lines sent by a protocol client and "S:" 134 represents lines returned by a protocol server. Indentation and 135 white space in examples is provided only to illustrate element 136 relationships and is not a REQUIRED feature of this protocol. 138 2. Object Attributes 140 An EPP host object has attributes and associated values that can be 141 viewed and modified by the sponsoring client or the server. This 142 section describes each attribute type in detail. The formal syntax 143 for the attribute values described here can be found in the "Formal 144 Syntax" section of this document and in the appropriate normative 145 references. 147 2.1. Host Names 149 The syntax for host names described in this document MUST conform to 150 [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 151 3490 [RFC3490] describes a standard to use certain ASCII name labels 152 to represent non-ASCII name labels. These conformance requirements 153 might change in the future as a result of progressing work in 154 developing standards for internationalized host names. 156 2.2. Client Identifiers 158 All EPP clients are identified by a server-unique identifier. Client 159 identifiers conform to the "clIDType" syntax described in 160 [I-D.hollenbeck-epp-rfc3730bis]. 162 2.3. Status Values 164 A host object MUST always have at least one associated status value. 165 Status values MAY be set only by the client that sponsors a host 166 object and by the server on which the object resides. A client can 167 change the status of a host object using the EPP command. 168 Each status value MAY be accompanied by a string of human-readable 169 text that describes the rationale for the status applied to the 170 object. 172 A client MUST NOT alter status values set by the server. A server 173 MAY alter or override status values set by a client subject to local 174 server policies. The status of an object MAY change as a result of 175 either a client-initiated transform command or an action performed by 176 a server operator. 178 Status values that can be added or removed by a client are prefixed 179 with "client". Corresponding status values that can be added or 180 removed by a server are prefixed with "server". Status values that 181 do not begin with either "client" or "server" are server-managed. 183 Status Value Descriptions: 185 - clientDeleteProhibited, serverDeleteProhibited 187 Requests to delete the object MUST be rejected. 189 - clientUpdateProhibited, serverUpdateProhibited 191 Requests to update the object (other than to remove this status) 192 MUST be rejected. 194 - linked 196 The host object has at least one active association with another 197 object, such as a domain object. Servers SHOULD provide services 198 to determine existing object associations. 200 - ok 202 This is the normal status value for an object that has no pending 203 operations or prohibitions. This value is set and removed by the 204 server as other status values are added or removed. 206 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 208 A transform command has been processed for the object (or in the 209 case of a command, for the host object's superordinate 210 domain object), but the action has not been completed by the 211 server. Server operators can delay action completion for a 212 variety of reasons, such as to allow for human review or third- 213 party action. A transform command that is processed, but whose 214 requested action is pending, is noted with response code 1001. 216 When the requested action has been completed, the pendingCreate, 217 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 218 removed. All clients involved in the transaction MUST be notified 219 using a service message that the action has been completed and that 220 the status of the object has changed. 222 "ok" status MAY only be combined with "linked" status. 224 "linked" status MAY be combined with any status. 226 "pendingDelete" status MUST NOT be combined with either 227 "clientDeleteProhibited" or "serverDeleteProhibited" status. 229 "pendingUpdate" status MUST NOT be combined with either 230 "clientUpdateProhibited" or "serverUpdateProhibited" status. 232 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 233 status values MUST NOT be combined with each other. 235 Other status combinations not expressly prohibited MAY be used. 237 2.4. Dates and Times 239 Date and time attribute values MUST be represented in Universal 240 Coordinated Time (UTC) using the Gregorian calendar. The extended 241 date-time form using upper case "T" and "Z" characters defined in 242 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 243 values as XML Schema does not support truncated date-time forms or 244 lower case "T" and "Z" characters. 246 2.5. IP Addresses 248 The syntax for IPv4 addresses described in this document MUST conform 249 to [RFC0791]. The syntax for IPv6 addresses described in this 250 document MUST conform to [RFC4291]. Practical considerations for 251 publishing IPv6 address information in zone files are documented in 252 [RFC1886], [RFC2874], and [RFC3152]. A server MAY reject IP 253 addresses that have not been allocated for public use by IANA. When 254 a host object is provisioned for use as a DNS name server, IP 255 addresses SHOULD be required only as needed to generate DNS glue 256 records. 258 3. EPP Command Mapping 260 A detailed description of the EPP syntax and semantics can be found 261 in [I-D.hollenbeck-epp-rfc3730bis]. The command mappings described 262 here are specifically for use in provisioning and managing Internet 263 host names via EPP. 265 3.1. EPP Query Commands 267 EPP provides two commands to retrieve host information: to 268 determine if a host object can be provisioned within a repository, 269 and to retrieve detailed information associated with a host 270 object. 272 3.1.1. EPP Command 274 The EPP command is used to determine if an object can be 275 provisioned within a repository. It provides a hint that allows a 276 client to anticipate the success or failure of provisioning an object 277 using the command as object provisioning requirements are 278 ultimately a matter of server policy. 280 In addition to the standard EPP command elements, the command 281 MUST contain a element that identifies the host 282 namespace. The element contains the following child 283 elements: 285 - One or more elements that contain the fully qualified 286 names of the host objects to be queried. 288 Example command: 290 C: 291 C: 292 C: 293 C: 294 C: 296 C: ns1.example.com 297 C: ns2.example.com 298 C: ns3.example.com 299 C: 300 C: 301 C: ABC-12345 302 C: 303 C: command has been processed successfully, the EPP 306 element MUST contain a child element that 307 identifies the host namespace. The element contains 308 one or more elements that contain the following child 309 elements: 311 - A element that contains the fully qualified name of 312 the queried host object. This element MUST contain an "avail" 313 attribute whose value indicates object availability (can it be 314 provisioned or not) at the moment the command was 315 completed. A value of "1" or "true" means that the object can be 316 provisioned. A value of "0" or "false" means that the object can 317 not be provisioned. 319 - An OPTIONAL element that MAY be provided when an 320 object can not be provisioned. If present, this element contains 321 server-specific text to help explain why the object can not be 322 provisioned. This text MUST be represented in the response 323 language previously negotiated with the client; an OPTIONAL "lang" 324 attribute MAY be present to identify the language if the 325 negotiated value is something other than the default value of "en" 326 (English). 328 Example response: 330 S: 331 S: 332 S: 333 S: 334 S: Command completed successfully 335 S: 336 S: 337 S: 339 S: 340 S: ns1.example.com 341 S: 342 S: 343 S: ns2.example2.com 344 S: In use 345 S: 346 S: 347 S: ns3.example3.com 348 S: 349 S: 350 S: 351 S: 352 S: ABC-12345 353 S: 54322-XYZ 354 S: 355 S: 356 S: command can not 359 be processed for any reason. 361 3.1.2. EPP Command 363 The EPP command is used to retrieve information associated 364 with a host object. In addition to the standard EPP command 365 elements, the command MUST contain a element that 366 identifies the host namespace. The element contains the 367 following child elements: 369 - A element that contains the fully qualified name of 370 the host object for which information is requested. 372 Example command: 374 C: 375 C: 376 C: 377 C: 378 C: 380 C: ns1.example.com 381 C: 382 C: 383 C: ABC-12345 384 C: 385 C: command has been processed successfully, the EPP 388 element MUST contain a child element that 389 identifies the host namespace. The element contains 390 the following child elements: 392 - A element that contains the fully qualified name of 393 the host object. 395 - A element that contains the Repository Object 396 IDentifier assigned to the host object when the object was 397 created. 399 - One or more elements that describe the status of the 400 host object. 402 - Zero or more elements that contain the IP addresses 403 associated with the host object. 405 - A element that contains the identifier of the 406 sponsoring client. 408 - A element that contains the identifier of the client 409 that created the host object. 411 - A element that contains the date and time of host 412 object creation. 414 - A element that contains the identifier of the client 415 that last updated the host object. This element MUST NOT be 416 present if the host object has never been modified. 418 - A element that contains the date and time of the 419 most recent host object modification. This element MUST NOT be 420 present if the host object has never been modified. 422 - A element that contains the date and time of the 423 most recent successful host object transfer. This element MUST 424 NOT be provided if the host object has never been transferred. 425 Note that host objects MUST NOT be transferred directly; host 426 objects MUST be transferred implicitly when the host object's 427 superordinate domain object is transferred. Host objects that are 428 subject to transfer when transferring a domain object are listed 429 in the response to an EPP command performed on the domain 430 object. 432 Example response: 434 S: 435 S: 436 S: 437 S: 438 S: Command completed successfully 439 S: 440 S: 441 S: 443 S: ns1.example.com 444 S: NS1_EXAMPLE1-REP 445 S: 446 S: 447 S: 192.0.2.2 448 S: 192.0.2.29 449 S: 1080:0:0:0:8:800:200C:417A 450 S: ClientY 451 S: ClientX 452 S: 1999-04-03T22:00:00.0Z 453 S: ClientX 454 S: 1999-12-03T09:00:00.0Z 455 S: 2000-04-08T09:00:00.0Z 456 S: 457 S: 458 S: 459 S: ABC-12345 460 S: 54322-XYZ 461 S: 462 S: 463 S: command can not 466 be processed for any reason. 468 3.1.3. EPP Query Command 470 Transfer semantics do not directly apply to host objects, so there is 471 no mapping defined for the EPP query command. 473 3.2. EPP Transform Commands 475 EPP provides three commands to transform host objects: to 476 create an instance of a host object, to delete an instance 477 of a host object, and to change information associated with 478 a host object. This document does not define host object mappings 479 for the EPP and commands. 481 Transform commands are typically processed and completed in real 482 time. Server operators MAY receive and process transform commands, 483 but defer completing the requested action if human or third-party 484 review is required before the requested action can be completed. In 485 such situations the server MUST return a 1001 response code to the 486 client to note that the command has been received and processed, but 487 the requested action is pending. The server MUST also manage the 488 status of the object that is the subject of the command to reflect 489 the initiation and completion of the requested action. Once the 490 action has been completed, all clients involved in the transaction 491 MUST be notified using a service message that the action has been 492 completed and that the status of the object has changed. 494 3.2.1. EPP Command 496 The EPP command provides a transform operation that allows a 497 client to create a host object. In addition to the standard EPP 498 command elements, the command MUST contain a 499 element that identifies the host namespace. The 500 element contains the following child elements: 502 - A element that contains the fully qualified name of 503 the host object to be created. 505 - Zero or more elements that contain the IP addresses to 506 be associated with the host. Each element MAY contain an "ip" 507 attribute to identify the IP address format. Attribute value "v4" 508 is used to note IPv4 address format. Attribute value "v6" is used 509 to note IPv6 address format. If the "ip" attribute is not 510 specified, "v4" is the default attribute value. 512 Hosts can be provisioned for use as name servers in the Domain Name 513 System (DNS), described in [RFC1034] and [RFC1035]. Hosts 514 provisioned as name servers might be subject to server operator 515 policies that require or prohibit specification of IP addresses 516 depending on the name of the host and the name space in which the 517 server will be used as a name server. When provisioned for use as a 518 name server, IP addresses are REQUIRED only as needed to produce DNS 519 glue records. For example, if the server is authoritative for the 520 "com" name space and the name of the server is "ns1.example.net", the 521 server is not required to produce DNS glue records for the name 522 server and IP addresses for the server are not required by the DNS. 524 If the host name exists in a name space for which the server is 525 authoritative, then the superordinate domain of the host MUST be 526 known to the server before the host object can be created. 528 Example command: 530 C: 531 C: 532 C: 533 C: 534 C: 536 C: ns1.example.com 537 C: 192.0.2.2 538 C: 192.0.2.29 539 C: 1080:0:0:0:8:800:200C:417A 540 C: 541 C: 542 C: ABC-12345 543 C: 544 C: command has been processed successfully, the EPP 547 element MUST contain a child element that 548 identifies the host namespace. The element contains 549 the following child elements: 551 - A element that contains the fully qualified name of 552 the host object. 554 - A element that contains the date and time of host 555 object creation. 557 Example response: 559 S: 560 S: 561 S: 562 S: 563 S: Command completed successfully 564 S: 565 S: 566 S: 568 S: ns1.example.com 569 S: 1999-04-03T22:00:00.0Z 570 S: 571 S: 572 S: 573 S: ABC-12345 574 S: 54322-XYZ 575 S: 576 S: 577 S: command can not 580 be processed for any reason. 582 3.2.2. EPP Command 584 The EPP command provides a transform operation that allows a 585 client to delete a host object. In addition to the standard EPP 586 command elements, the command MUST contain a 587 element that identifies the host namespace. The 588 element contains the following child elements: 590 - A element that contains the fully qualified name of 591 the host object to be deleted. 593 A host name object SHOULD NOT be deleted if the host object is 594 associated with any other object. For example, if the host object is 595 associated with a domain object, the host object SHOULD NOT be 596 deleted until the existing association has been broken. Deleting a 597 host object without first breaking existing associations can cause 598 DNS resolution failure for domain objects that refer to the deleted 599 host object. 601 Example command: 603 C: 604 C: 605 C: 606 C: 607 C: 609 C: ns1.example.com 610 C: 611 C: 612 C: ABC-12345 613 C: 614 C: command has been processed successfully, a server 617 MUST respond with an EPP response with no element. 619 Example response: 621 S: 622 S: 623 S: 624 S: 625 S: Command completed successfully 626 S: 627 S: 628 S: ABC-12345 629 S: 54321-XYZ 630 S: 631 S: 632 S: command can not 635 be processed for any reason. 637 3.2.3. EPP Command 639 Renewal semantics do not apply to host objects, so there is no 640 mapping defined for the EPP command. 642 3.2.4. EPP Command 644 Transfer semantics do not directly apply to host objects, so there is 645 no mapping defined for the EPP command. Host objects are 646 subordinate to an existing superordinate domain object, and as such 647 they are subject to transfer when a domain object is transferred. 649 3.2.5. EPP Command 651 The EPP command provides a transform operation that allows a 652 client to modify the attributes of a host object. In addition to the 653 standard EPP command elements, the command MUST contain a 654 element that identifies the host namespace. The element contains the following child elements: 657 - A element that contains the fully qualified name of 658 the host object to be updated. 660 - An OPTIONAL element that contains attribute values to 661 be added to the object. 663 - An OPTIONAL element that contains attribute values to 664 be removed from the object. 666 - An OPTIONAL element that contains object attribute 667 values to be changed. 669 At least one , , or element MUST be 670 provided if the command is not being extended. All of these elements 671 MAY be omitted if an extension is present. The 672 and elements contain the following child elements: 674 - One or more elements that contain IP addresses to be 675 associated with or removed from the host object. IP address 676 restrictions described in the command mapping apply here 677 as well. 679 - One or more elements that contain status values to 680 be associated with or removed from the object. When specifying a 681 value to be removed, only the attribute value is significant; 682 element text is not required to match a value for removal. 684 A element contains the following child elements: 686 - A element that contains a new fully qualified host 687 name by which the host object will be known. 689 Host name changes MAY require the addition or removal of IP addresses 690 to be accepted by the server. IP address association MAY be subject 691 to server policies for provisioning hosts as name servers. 693 Host name changes can have an impact on associated objects that refer 694 to the host object. A host name change SHOULD NOT require additional 695 updates of associated objects to preserve existing associations, with 696 one exception: changing an external host object that has associations 697 with objects that are sponsored by a different client. Attempts to 698 update such hosts directly MUST fail with EPP error code 2305. The 699 change can be provisioned by creating a new external host with a new 700 name and needed new attributes and subsequently updating the other 701 objects sponsored by the client. 703 Example command: 705 C: 706 C: 707 C: 708 C: 709 C: 711 C: ns1.example.com 712 C: 713 C: 192.0.2.22 714 C: 715 C: 716 C: 717 C: 1080:0:0:0:8:800:200C:417A 718 C: 719 C: 720 C: ns2.example.com 721 C: 722 C: 723 C: 724 C: ABC-12345 725 C: 726 C: command has been processed successfully, a server 729 MUST respond with an EPP response with no element. 731 Example response: 733 S: 734 S: 735 S: 736 S: 737 S: Command completed successfully 738 S: 739 S: 740 S: ABC-12345 741 S: 54321-XYZ 742 S: 743 S: 744 S: command could 746 not be processed for any reason. 748 3.3. Offline Review of Requested Actions 750 Commands are processed by a server in the order they are received 751 from a client. Though an immediate response confirming receipt and 752 processing of the command is produced by the server, a server 753 operator MAY perform an offline review of requested transform 754 commands before completing the requested action. In such situations 755 the response from the server MUST clearly note that the transform 756 command has been received and processed, but the requested action is 757 pending. The status of the corresponding object MUST clearly reflect 758 processing of the pending action. The server MUST notify the client 759 when offline processing of the action has been completed. 761 Examples describing a command that requires offline review 762 are included here. Note the result code and message returned in 763 response to the command. 765 S: 766 S: 767 S: 768 S: 769 S: Command completed successfully; action pending 770 S: 771 S: 772 S: 774 S: ns1.example.com 775 S: 1999-04-03T22:00:00.0Z 776 S: 777 S: 778 S: 779 S: ABC-12345 780 S: 54322-XYZ 781 S: 782 S: 783 S: command 789 or by using an out-of-band mechanism to inform the client of the 790 request. 792 The service message MUST contain text in the , , 793 element that describes the notification. In addition, the EPP 794 element MUST contain a child element that 795 identifies the host namespace. The element contains 796 the following child elements: 798 - A element that contains the fully qualified name of 799 the host object. The element contains a REQUIRED 800 "paResult" attribute. A positive boolean value indicates that the 801 request has been approved and completed. A negative boolean value 802 indicates that the request has been denied and the requested 803 action has not been taken. 805 - A element that contains the client transaction 806 identifier and server transaction identifier returned with the 807 original response to process the command. The client transaction 808 identifier is OPTIONAL and will only be returned if the client 809 provided an identifier with the original command. 811 - A element that contains the date and time describing 812 when review of the requested action was completed. 814 Example "review completed" service message: 816 S: 817 S: 818 S: 819 S: 820 S: Command completed successfully; ack to dequeue 821 S: 822 S: 823 S: 1999-04-04T22:01:00.0Z 824 S: Pending action completed successfully. 825 S: 826 S: 827 S: 829 S: ns1.example.com 830 S: 831 S: ABC-12345 832 S: 54322-XYZ 833 S: 834 S: 1999-04-04T22:00:00.0Z 835 S: 836 S: 837 S: 838 S: BCD-23456 839 S: 65432-WXY 840 S: 841 S: 842 S: 856 863 866 867 869 870 871 Extensible Provisioning Protocol v1.0 872 host provisioning schema. 873 874 876 879 880 881 882 883 885 888 889 890 891 893 894 896 897 898 899 901 902 903 905 906 907 908 910 911 913 914 915 916 917 918 920 923 924 925 926 927 929 932 933 934 936 937 938 941 942 943 944 946 948 950 951 953 956 957 958 960 962 963 965 968 969 970 971 972 974 977 978 979 980 982 985 986 987 989 990 992 993 994 995 997 998 1000 1001 1002 1003 1005 1007 1008 1010 1013 1014 1015 1016 1017 1018 1020 1023 1024 1025 1026 1027 1029 1031 1032 1033 1034 1036 1038 1040 1041 1043 1047 1048 1049 1050 1052 1054 1056 1057 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1074 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1089 1090 1091 1093 1096 1097 END 1099 5. Internationalization Considerations 1101 EPP is represented in XML, which provides native support for encoding 1102 information using the Unicode character set and its more compact 1103 representations including UTF-8. Conformant XML processors recognize 1104 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1105 identify and use other character encodings through use of an 1106 "encoding" attribute in an declaration, use of UTF-8 is 1107 RECOMMENDED in environments where parser encoding support 1108 incompatibility exists. 1110 All date-time values presented via EPP MUST be expressed in Universal 1111 Coordinated Time using the Gregorian calendar. XML Schema allows use 1112 of time zone identifiers to indicate offsets from the zero meridian, 1113 but this option MUST NOT be used with EPP. The extended date-time 1114 form using upper case "T" and "Z" characters defined in 1115 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1116 values as XML Schema does not support truncated date-time forms or 1117 lower case "T" and "Z" characters. 1119 This document requires host name syntax as specified in [RFC0952] as 1120 updated by [RFC1123]. At the time of this writing, RFC 3490 1121 [RFC3490] describes a standard to use certain ASCII name labels to 1122 represent non-ASCII name labels. These conformance requirements 1123 might change as a result of progressing work in developing standards 1124 for internationalized host names. 1126 6. IANA Considerations 1128 This document uses URNs to describe XML namespaces and XML schemas 1129 conforming to a registry mechanism described in [RFC3688]. Two URI 1130 assignments have been registered by the IANA. 1132 Registration request for the host namespace: 1134 URI: urn:ietf:params:xml:ns:host-1.0 1136 Registrant Contact: See the "Author's Address" section of this 1137 document. 1139 XML: None. Namespace URIs do not represent an XML specification. 1141 Registration request for the host XML schema: 1143 URI: urn:ietf:params:xml:schema:host-1.0 1145 Registrant Contact: See the "Author's Address" section of this 1146 document. 1148 XML: See the "Formal Syntax" section of this document. 1150 7. Security Considerations 1152 The object mapping described in this document does not provide any 1153 security services or introduce any additional considerations beyond 1154 those described by and 1155 protocol layers used by EPP. 1157 8. Acknowledgements 1159 This document was originally written as an individual submission 1160 Internet-Draft. The provreg working group later adopted it as a 1161 working group document and provided many invaluable comments and 1162 suggested improvements. The author wishes to acknowledge the efforts 1163 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1164 editorial contributions. 1166 Specific suggestions that have been incorporated into this document 1167 were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony 1168 Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, 1169 Patrick Mevzek, and Rick Wesson. 1171 9. References 1173 9.1. Normative References 1175 [I-D.hollenbeck-epp-rfc3730bis] 1176 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1177 draft-hollenbeck-epp-rfc3730bis-04 (work in progress), 1178 November 2006. 1180 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1181 September 1981. 1183 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1184 host table specification", RFC 952, October 1985. 1186 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1187 STD 13, RFC 1034, November 1987. 1189 [RFC1035] Mockapetris, P., "Domain names - implementation and 1190 specification", STD 13, RFC 1035, November 1987. 1192 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1193 and Support", STD 3, RFC 1123, October 1989. 1195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1196 Requirement Levels", BCP 14, RFC 2119, March 1997. 1198 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1199 January 2004. 1201 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1202 Architecture", RFC 4291, February 2006. 1204 [W3C.REC-xml-20040204] 1205 Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., and 1206 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1207 Edition)", World Wide Web Consortium Recommendation REC- 1208 xml-20040204, February 2004, 1209 . 1211 [W3C.REC-xmlschema-1-20041028] 1212 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn, 1213 "XML Schema Part 1: Structures Second Edition", World Wide 1214 Web Consortium Recommendation REC-xmlschema-1-20041028, 1215 October 2004, 1216 . 1218 [W3C.REC-xmlschema-2-20041028] 1219 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1220 Second Edition", World Wide Web Consortium 1221 Recommendation REC-xmlschema-2-20041028, October 2004, 1222 . 1224 9.2. Informative References 1226 [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP 1227 version 6", RFC 1886, December 1995. 1229 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1230 10646", RFC 2781, February 2000. 1232 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 1233 IPv6 Address Aggregation and Renumbering", RFC 2874, 1234 July 2000. 1236 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 1237 August 2001. 1239 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1240 "Internationalizing Domain Names in Applications (IDNA)", 1241 RFC 3490, March 2003. 1243 [RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1244 Host Mapping", RFC 3732, March 2004. 1246 Appendix A. Changes from RFC 3732 1248 1. Minor reformatting as a result of converting I-D source format 1249 from nroff to XML. 1251 2. Removed this text from Section 2.3: 1253 "Transform commands MUST be rejected when a pendingCreate, 1254 pendingDelete, pendingTransfer, or pendingUpdate status is set." 1256 3. Changed text in Section 3.2.2 from this: 1258 "A host name object MUST NOT be deleted if the host object is 1259 associated with any other object. For example, if the host 1260 object is associated with a domain object, the host object MUST 1261 NOT be deleted until the existing association has been broken." 1263 to this: 1265 "A host name object SHOULD NOT be deleted if the host object is 1266 associated with any other object. For example, if the host 1267 object is associated with a domain object, the host object SHOULD 1268 NOT be deleted until the existing association has been broken. 1269 Deleting a host object without first breaking existing 1270 associations can cause DNS resolution failure for domain objects 1271 that refer to the deleted host object." 1273 4. Changed text in Section 3.2.5 from "At least one , 1274 , or element MUST be provided." to "At least 1275 one , , or element MUST be 1276 provided if the command is not being extended. All of these 1277 elements MAY be omitted if an extension is present.". 1279 5. Changed text in Section 3.3 (old Section 3.2.6) from this: 1281 "The server operator reviews the request offline, and informs the 1282 client of the outcome of the review by queuing a service message 1283 for retrieval via the command." 1285 to this: 1287 "The server operator reviews the request offline, and informs the 1288 client of the outcome of the review by either queuing a service 1289 message for retrieval via the command or by using an out- 1290 of-band mechanism to inform the client of the request." 1292 6. Removed text describing use of the XML Schema schemaLocation 1293 attribute. This is an optional attribute that doesn't need to be 1294 mandated for use in EPP. 1296 7. Removed references to RFC 3339 and replaced them with references 1297 to the W3C XML Schema specification. 1299 8. Updated EPP and XML references. 1301 Author's Address 1303 Scott Hollenbeck 1304 VeriSign, Inc. 1305 21345 Ridgetop Circle 1306 Dulles, VA 20166-6503 1307 US 1309 Email: shollenbeck@verisign.com 1311 Full Copyright Statement 1313 Copyright (C) The IETF Trust (2006). 1315 This document is subject to the rights, licenses and restrictions 1316 contained in BCP 78, and except as set forth therein, the authors 1317 retain all their rights. 1319 This document and the information contained herein are provided on an 1320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1322 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1323 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1324 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1327 Intellectual Property 1329 The IETF takes no position regarding the validity or scope of any 1330 Intellectual Property Rights or other rights that might be claimed to 1331 pertain to the implementation or use of the technology described in 1332 this document or the extent to which any license under such rights 1333 might or might not be available; nor does it represent that it has 1334 made any independent effort to identify any such rights. Information 1335 on the procedures with respect to rights in RFC documents can be 1336 found in BCP 78 and BCP 79. 1338 Copies of IPR disclosures made to the IETF Secretariat and any 1339 assurances of licenses to be made available, or the result of an 1340 attempt made to obtain a general license or permission for the use of 1341 such proprietary rights by implementers or users of this 1342 specification can be obtained from the IETF on-line IPR repository at 1343 http://www.ietf.org/ipr. 1345 The IETF invites any interested party to bring to its attention any 1346 copyrights, patents or patent applications, or other proprietary 1347 rights that may cover technology that may be required to implement 1348 this standard. Please address the information to the IETF at 1349 ietf-ipr@ietf.org. 1351 Acknowledgment 1353 Funding for the RFC Editor function is provided by the IETF 1354 Administrative Support Activity (IASA).