idnits 2.17.1 draft-ietf-provreg-epp-host-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-XML' ** Downref: Normative reference to an Unknown state RFC: RFC 952 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-2' ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Downref: Normative reference to an Informational RFC: RFC 2781 ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 April 24, 2003 Expires: October 24, 2003 6 Extensible Provisioning Protocol Host Mapping 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an Extensible Provisioning Protocol (EPP) 32 mapping for the provisioning and management of Internet host names 33 stored in a shared central repository. Specified in XML, the mapping 34 defines EPP command syntax and semantics as applied to host names. 36 Conventions Used In This Document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 In examples, "C:" represents lines sent by a protocol client and "S:" 43 represents lines returned by a protocol server. Indentation and white 44 space in examples is provided only to illustrate element relationships 45 and is not a REQUIRED feature of this protocol. 47 Table of Contents 49 1. Introduction ................................................. 3 50 1.1 Relationship of Host Objects and Domain Objects ............. 3 51 2. Object Attributes ............................................ 4 52 2.1 Host Names .................................................. 4 53 2.2 Client Identifiers .......................................... 4 54 2.3 Status Values ............................................... 4 55 2.4 Dates and Times ............................................. 6 56 2.5 IP Addresses ................................................ 6 57 3. EPP Command Mapping .......................................... 7 58 3.1 EPP Query Commands .......................................... 7 59 3.1.1 EPP Command ....................................... 7 60 3.1.2 EPP Command ........................................ 9 61 3.1.3 EPP Query Command .............................. 12 62 3.2 EPP Transform Commands ...................................... 12 63 3.2.1 EPP Command ...................................... 13 64 3.2.2 EPP Command ...................................... 15 65 3.2.3 EPP Command ....................................... 16 66 3.2.4 EPP Command .................................... 17 67 3.2.5 EPP Command ...................................... 17 68 3.2.6 Offline Review of Requested Actions ....................... 19 69 4. Formal Syntax ................................................ 22 70 5. Internationalization Considerations .......................... 28 71 6. IANA Considerations .......................................... 28 72 7. Security Considerations ...................................... 29 73 8. Acknowledgements ............................................. 29 74 9. References ................................................... 30 75 10. Author's Address ............................................ 31 76 A. Revisions From Previous Version .............................. 32 77 B. Full Copyright Statement ..................................... 33 79 1. Introduction 81 This document describes an Internet host name mapping for version 1.0 82 of the Extensible Provisioning Protocol (EPP). This mapping is 83 specified using the Extensible Markup Language (XML) 1.0 as described 84 in [XML] and XML Schema notation as described in [XMLS-1] and [XMLS- 85 2]. 87 [EPP] provides a complete description of EPP command and response 88 structures. A thorough understanding of the base protocol 89 specification is necessary to understand the mapping described in this 90 document. 92 XML is case sensitive. Unless stated otherwise, XML specifications 93 and examples provided in this document MUST be interpreted in the 94 character case presented to develop a conforming implementation. 96 1.1 Relationship of Host Objects and Domain Objects 98 This document assumes that host name objects have a subordinate 99 relationship to a superordinate domain name object. For example, host 100 name "ns1.example.com" has a subordinate relationship to domain name 101 "example.com". EPP actions (such as object transfers) that do not 102 preserve this relationship MUST be explicitly disallowed. 104 A host name object can be created in a repository for which no 105 superordinate domain name object exists. For example, host name 106 "ns1.example.com" can be created in the ".example" repository so that 107 DNS domains in ".example" can be delegated to the host. Such hosts 108 are described as "external" hosts in this specification since the name 109 of the host does not belong to the name space of the repository in 110 which the host is being used for delegation purposes. 112 Whether a host is external or internal relates to the repository in 113 which the host is being used for delegation purposes. Whether an 114 internal host is subordinate or not relates to a domain within the 115 repository. For example, host ns1.example1.com is a subordinate host 116 of domain example1.com, but it is a not a subordinate host of domain 117 example2.com. ns1.example1.com can be used as a name server for 118 example2.com. In this case ns1.example1.com MUST be treated as an 119 internal host, subject to the rules governing operations on 120 subordinate hosts within the same repository. 122 2. Object Attributes 124 An EPP host object has attributes and associated values that can be 125 viewed and modified by the sponsoring client or the server. This 126 section describes each attribute type in detail. The formal syntax 127 for the attribute values described here can be found in the "Formal 128 Syntax" section of this document and in the appropriate normative 129 references. 131 2.1 Host Names 133 The syntax for host names described in this document MUST conform to 134 [RFC952] as updated by [RFC1123]. These conformance requirements 135 might change in the future as a result of progressing work in 136 developing standards for internationalized host names. 138 2.2 Client Identifiers 140 All EPP clients are identified by a server-unique identifier. Client 141 identifiers conform to the "clIDType" syntax described in [EPP]. 143 2.3 Status Values 145 A host object MUST always have at least one associated status value. 146 Status values MAY be set only by the client that sponsors a host 147 object and by the server on which the object resides. A client can 148 change the status of a host object using the EPP command. 149 Each status value MAY be accompanied by a string of human-readable 150 text that describes the rationale for the status applied to the 151 object. 153 A client MUST NOT alter status values set by the server. A server MAY 154 alter or override status values set by a client subject to local 155 server policies. The status of an object MAY change as a result of 156 either a client-initiated transform command or an action performed by 157 a server operator. 159 Status values that can be added or removed by a client are prefixed 160 with "client". Corresponding status values that can be added or 161 removed by a server are prefixed with "server". Status values that do 162 not begin with either "client" or "server" are server-managed. 164 Status Value Descriptions: 166 - clientDeleteProhibited, serverDeleteProhibited 168 Requests to delete the object MUST be rejected. 170 - clientUpdateProhibited, serverUpdateProhibited 172 Requests to update the object (other than to remove this status) MUST 173 be rejected. 175 - linked 177 The host object has at least one active association with another 178 object, such as a domain object. Servers SHOULD provide services to 179 determine existing object associations. 181 - ok 183 This is the normal status value for an object that has no pending 184 operations or prohibitions. This value is set and removed by the 185 server as other status values are added or removed. 187 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 189 A transform command has been processed for the object (or in the case 190 of a command, for the host object's superordinate domain 191 object), but the action has not been completed by the server. Server 192 operators can delay action completion for a variety of reasons, such 193 as to allow for human review or third-party action. A transform 194 command that is processed, but whose requested action is pending, is 195 noted with response code 1001. 197 Transform commands MUST be rejected when a pendingCreate, 198 pendingDelete, pendingTransfer, or pendingUpdate status is set. 200 When the requested action has been completed, the pendingCreate, 201 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 202 removed. All clients involved in the transaction MUST be notified 203 using a service message that the action has been completed and that 204 the status of the object has changed. 206 "ok" status MAY only be combined with "linked" status. 208 "linked" status MAY be combined with any status. 210 "pendingDelete" status MUST NOT be combined with either 211 "clientDeleteProhibited" or "serverDeleteProhibited" status. 213 "pendingUpdate" status MUST NOT be combined with either 214 "clientUpdateProhibited" or "serverUpdateProhibited" status. 216 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 217 status values MUST NOT be combined with each other. 219 Other status combinations not expressly prohibited MAY be used. 221 2.4 Dates and Times 223 Date and time attribute values MUST be represented in Universal 224 Coordinated Time (UTC) using the Gregorian calendar. The extended 225 date-time form using upper case "T" and "Z" characters defined in 226 [RFC3339] MUST be used to represent date-time values as XML Schema 227 does not support truncated date-time forms or lower case "T" and "Z" 228 characters. 230 2.5 IP Addresses 232 The syntax for IPv4 addresses described in this document MUST conform 233 to [RFC791]. The syntax for IPv6 addresses described in this document 234 MUST conform to [RFC3513]. Practical considerations for publishing 235 IPv6 address information in zone files are documented in [RFC1886], 236 [RFC2874], and [RFC3152]. A server MAY reject IP addresses that have 237 not been allocated for public use by IANA. When a host object is 238 provisioned for use as a DNS name server, IP addresses SHOULD be 239 required only as needed to generate DNS glue records. 241 3. EPP Command Mapping 243 A detailed description of the EPP syntax and semantics can be found in 244 [EPP]. The command mappings described here are specifically for use 245 in provisioning and managing Internet host names via EPP. 247 3.1 EPP Query Commands 249 EPP provides two commands to retrieve host information: to 250 determine if a host object can be provisioned within a repository, and 251 to retrieve detailed information associated with a host object. 253 3.1.1 EPP Command 255 The EPP command is used to determine if an object can be 256 provisioned within a repository. It provides a hint that allows a 257 client to anticipate the success or failure of provisioning an object 258 using the command as object provisioning requirements are 259 ultimately a matter of server policy. 261 In addition to the standard EPP command elements, the command 262 MUST contain a element that identifies the host namespace 263 and the location of the host schema. The element 264 contains the following child elements: 266 - One or more elements that contain the fully qualified 267 names of the host objects to be queried. 269 Example command: 271 C: 272 C: 276 C: 277 C: 278 C: 282 C: ns1.example.com 283 C: ns2.example.com 284 C: ns3.example.com 285 C: 286 C: 287 C: ABC-12345 288 C: 289 C: 291 When a command has been processed successfully, the EPP 292 element MUST contain a child element that 293 identifies the host namespace and the location of the host schema. 294 The element contains one or more elements 295 that contain the following child elements: 297 - A element that contains the fully qualified name of the 298 queried host object. This element MUST contain an "avail" attribute 299 whose value indicates object availability (can it be provisioned or 300 not) at the moment the command was completed. A value of "1" 301 or "true" means that the object can be provisioned. A value of "0" or 302 "false" means that the object can not be provisioned. 304 - An OPTIONAL element that MAY be provided when an 305 object can not be provisioned. If present, this element contains 306 server-specific text to help explain why the object can not be 307 provisioned. This text MUST be represented in the response language 308 previously negotiated with the client; an OPTIONAL "lang" attribute 309 MAY be present to identify the language if the negotiated value is 310 something other than the default value of "en" (English). 312 Example response: 314 S: 315 S: 319 S: 320 S: 321 S: Command completed successfully 322 S: 323 S: 324 S: 328 S: 329 S: ns1.example.com 330 S: 331 S: 332 S: ns2.example2.com 333 S: In use 334 S: 335 S: 336 S: ns3.example3.com 337 S: 338 S: 339 S: 340 S: 341 S: ABC-12345 342 S: 54322-XYZ 343 S: 344 S: 345 S: 347 An EPP error response MUST be returned if a command can not be 348 processed for any reason. 350 3.1.2 EPP Command 352 The EPP command is used to retrieve information associated with 353 a host object. In addition to the standard EPP command elements, the 354 command MUST contain a element that identifies the 355 host namespace and the location of the host schema. The 356 element contains the following child elements: 358 - A element that contains the fully qualified name of the 359 host object for which information is requested. 361 Example command: 363 C: 364 C: 368 C: 369 C: 370 C: 374 C: ns1.example.com 375 C: 376 C: 377 C: ABC-12345 378 C: 379 C: 381 When an command has been processed successfully, the EPP 382 element MUST contain a child element that 383 identifies the host namespace and the location of the host schema. 384 The element contains the following child elements: 386 - A element that contains the fully qualified name of the 387 host object. 389 - A element that contains the Repository Object IDentifier 390 assigned to the host object when the object was created. 392 - One or more elements that describe the status of the 393 host object. 395 - Zero or more elements that contain the IP addresses 396 associated with the host object. 398 - A element that contains the identifier of the sponsoring 399 client. 401 - A element that contains the identifier of the client 402 that created the host object. 404 - A element that contains the date and time of host 405 object creation. 407 - A element that contains the identifier of the client 408 that last updated the host object. This element MUST NOT be present 409 if the host object has never been modified. 411 - A element that contains the date and time of the most 412 recent host object modification. This element MUST NOT be present if 413 the host object has never been modified. 415 - A element that contains the date and time of the most 416 recent successful host object transfer. This element MUST NOT be 417 provided if the host object has never been transferred. Note that 418 host objects MUST NOT be transferred directly; host objects MUST be 419 transferred implicitly when the host object's superordinate domain 420 object is transferred. Host objects that are subject to transfer when 421 transferring a domain object are listed in the response to an EPP 422 command performed on the domain object. 424 Example response: 426 S: 427 S: 431 S: 432 S: 433 S: Command completed successfully 434 S: 435 S: 436 S: 440 S: ns1.example.com 441 S: NS1_EXAMPLE1-REP 442 S: 443 S: 444 S: 192.0.2.2 445 S: 192.0.2.29 446 S: 1080:0:0:0:8:800:200C:417A 447 S: ClientY 448 S: ClientX 449 S: 1999-04-03T22:00:00.0Z 450 S: ClientX 451 S: 1999-12-03T09:00:00.0Z 452 S: 2000-04-08T09:00:00.0Z 453 S: 454 S: 455 S: 456 S: ABC-12345 457 S: 54322-XYZ 458 S: 459 S: 460 S: 462 An EPP error response MUST be returned if an command can not be 463 processed for any reason. 465 3.1.3 EPP Query Command 467 Transfer semantics do not directly apply to host objects, so there is 468 no mapping defined for the EPP query command. 470 3.2 EPP Transform Commands 471 EPP provides three commands to transform host objects: to 472 create an instance of a host object, to delete an instance of 473 a host object, and to change information associated with a 474 host object. This document does not define host object mappings for 475 the EPP and commands. 477 Transform commands are typically processed and completed in real time. 478 Server operators MAY receive and process transform commands, but defer 479 completing the requested action if human or third-party review is 480 required before the requested action can be completed. In such 481 situations the server MUST return a 1001 response code to the client 482 to note that the command has been received and processed, but the 483 requested action is pending. The server MUST also manage the status 484 of the object that is the subject of the command to reflect the 485 initiation and completion of the requested action. Once the action 486 has been completed, all clients involved in the transaction MUST be 487 notified using a service message that the action has been completed 488 and that the status of the object has changed. 490 3.2.1 EPP Command 492 The EPP command provides a transform operation that allows a 493 client to create a host object. In addition to the standard EPP 494 command elements, the command MUST contain a 495 element that identifies the host namespace and the location of the 496 host schema. The element contains the following child 497 elements: 499 - A element that contains the fully qualified name of the 500 host object to be created. 502 - Zero or more elements that contain the IP addresses to 503 be associated with the host. Each element MAY contain an "ip" 504 attribute to identify the IP address format. Attribute value "v4" is 505 used to note IPv4 address format. Attribute value "v6" is used to 506 note IPv6 address format. If the "ip" attribute is not specified, 507 "v4" is the default attribute value. 509 Hosts can be provisioned for use as name servers in the Domain Name 510 System (DNS), described in [RFC1034] and [RFC1035]. Hosts provisioned 511 as name servers might be subject to server operator policies that 512 require or prohibit specification of IP addresses depending on the 513 name of the host and the name space in which the server will be used 514 as a name server. When provisioned for use as a name server, IP 515 addresses are REQUIRED only as needed to produce DNS glue records. 516 For example, if the server is authoritative for the "com" name space 517 and the name of the server is "ns1.example.net", the server is not 518 required to produce DNS glue records for the name server and IP 519 addresses for the server are not required by the DNS. 521 If the host name exists in a name space for which the server is 522 authoritative, then the superordinate domain of the host MUST be known 523 to the server before the host object can be created. 525 Example command: 527 C: 528 C: 532 C: 533 C: 534 C: 538 C: ns1.example.com 539 C: 192.0.2.2 540 C: 192.0.2.29 541 C: 1080:0:0:0:8:800:200C:417A 542 C: 543 C: 544 C: ABC-12345 545 C: 546 C: 548 When a command has been processed successfully, the EPP 549 element MUST contain a child element that 550 identifies the host namespace and the location of the host schema. 551 The element contains the following child elements: 553 - A element that contains the fully qualified name of the 554 host object. 556 - A element that contains the date and time of host 557 object creation. 559 Example response: 561 S: 562 S: 566 S: 567 S: 568 S: Command completed successfully 569 S: 570 S: 571 S: 575 S: ns1.example.com 576 S: 1999-04-03T22:00:00.0Z 577 S: 578 S: 579 S: 580 S: ABC-12345 581 S: 54322-XYZ 582 S: 583 S: 584 S: 586 An EPP error response MUST be returned if a command can not 587 be processed for any reason. 589 3.2.2 EPP Command 591 The EPP command provides a transform operation that allows a 592 client to delete a host object. In addition to the standard EPP 593 command elements, the command MUST contain a 594 element that identifies the host namespace and the location of the 595 host schema. The element contains the following child 596 elements: 598 - A element that contains the fully qualified name of the 599 host object to be deleted. 601 A host name object MUST NOT be deleted if the host object is 602 associated with any other object. For example, if the host object is 603 associated with a domain object, the host object MUST NOT be deleted 604 until the existing association has been broken. 606 Example command: 608 C: 609 C: 613 C: 614 C: 615 C: 619 C: ns1.example.com 620 C: 621 C: 622 C: ABC-12345 623 C: 624 C: 626 When a command has been processed successfully, a server MUST 627 respond with an EPP response with no element. 629 Example response: 631 S: 632 S: 636 S: 637 S: 638 S: Command completed successfully 639 S: 640 S: 641 S: ABC-12345 642 S: 54321-XYZ 643 S: 644 S: 645 S: 647 An EPP error response MUST be returned if a command can not 648 be processed for any reason. 650 3.2.3 EPP Command 652 Renewal semantics do not apply to host objects, so there is no mapping 653 defined for the EPP command. 655 3.2.4 EPP Command 657 Transfer semantics do not directly apply to host objects, so there is 658 no mapping defined for the EPP command. Host objects are 659 subordinate to an existing superordinate domain object, and as such 660 they are subject to transfer when a domain object is transferred. 662 3.2.5 EPP Command 664 The EPP command provides a transform operation that allows a 665 client to modify the attributes of a host object. In addition to the 666 standard EPP command elements, the command MUST contain a 667 element that identifies the host namespace and the 668 location of the host schema. The element contains the 669 following child elements: 671 - A element that contains the fully qualified name of the 672 host object to be updated. 674 - An OPTIONAL element that contains attribute values to be 675 added to the object. 677 - An OPTIONAL element that contains attribute values to be 678 removed from the object. 680 - An OPTIONAL element that contains object attribute values 681 to be changed. 683 At least one , , or element MUST be 684 provided. The and elements contain the 685 following child elements: 687 - One or more elements that contain IP addresses to be 688 associated with or removed from the host object. IP address 689 restrictions described in the command mapping apply here as 690 well. 692 - One or more elements that contain status values to be 693 associated with or removed from the object. When specifying a value 694 to be removed, only the attribute value is significant; element text 695 is not required to match a value for removal. 697 A element contains the following child elements: 699 - A element that contains a new fully qualified host name 700 by which the host object will be known. 702 Host name changes MAY require the addition or removal of IP addresses 703 to be accepted by the server. IP address association MAY be subject 704 to server policies for provisioning hosts as name servers. 706 Host name changes can have an impact on associated objects that refer 707 to the host object. A host name change SHOULD NOT require additional 708 updates of associated objects to preserve existing associations, with 709 one exception: changing an external host object that has associations 710 with objects that are sponsored by a different client. Attempts to 711 update such hosts directly MUST fail with EPP error code 2305. The 712 change can be provisioned by creating a new external host with a new 713 name and needed new attributes and subsequently updating the other 714 objects sponsored by the client. 716 Example command: 718 C: 719 C: 723 C: 724 C: 725 C: 729 C: ns1.example.com 730 C: 731 C: 192.0.2.22 732 C: 733 C: 734 C: 735 C: 1080:0:0:0:8:800:200C:417A 736 C: 737 C: 738 C: ns2.example.com 739 C: 740 C: 741 C: 742 C: ABC-12345 743 C: 744 C: 746 When an command has been processed successfully, a server 747 MUST respond with an EPP response with no element. 749 Example response: 751 S: 752 S: 756 S: 757 S: 758 S: Command completed successfully 759 S: 760 S: 761 S: ABC-12345 762 S: 54321-XYZ 763 S: 764 S: 765 S: 767 An EPP error response MUST be returned if an command could 768 not be processed for any reason. 770 3.2.6 Offline Review of Requested Actions 772 Commands are processed by a server in the order they are received from 773 a client. Though an immediate response confirming receipt and 774 processing of the command is produced by the server, a server operator 775 MAY perform an offline review of requested transform commands before 776 completing the requested action. In such situations the response from 777 the server MUST clearly note that the transform command has been 778 received and processed, but the requested action is pending. The 779 status of the corresponding object MUST clearly reflect processing of 780 the pending action. The server MUST notify the client when offline 781 processing of the action has been completed. 783 Examples describing a command that requires offline review 784 are included here. Note the result code and message returned in 785 response to the command. 787 S: 788 S: 792 S: 793 S: 794 S: Command completed successfully; action pending 795 S: 796 S: 797 S: 801 S: ns1.example.com 802 S: 1999-04-03T22:00:00.0Z 803 S: 804 S: 805 S: 806 S: ABC-12345 807 S: 54322-XYZ 808 S: 809 S: 810 S: 812 The status of the host object after returning this response MUST 813 include "pendingCreate". The server operator reviews the request 814 offline, and informs the client of the outcome of the review by 815 queuing a service message for retrieval via the command. 817 The service message MUST contain text in the , , 818 element that describes the notification. In addition, the EPP 819 element MUST contain a child element that 820 identifies the host namespace and the location of the host schema. 821 The element contains the following child elements: 823 - A element that contains the fully qualified name of the 824 host object. The element contains a REQUIRED "paResult" 825 attribute. A positive boolean value indicates that the request has 826 been approved and completed. A negative boolean value indicates that 827 the request has been denied and the requested action has not been 828 taken. 830 - A element that contains the client transaction 831 identifier and server transaction identifier returned with the 832 original response to process the command. The client transaction 833 identifier is OPTIONAL and will only be returned if the client 834 provided an identifier with the original command. 836 - A element that contains the date and time describing 837 when review of the requested action was completed. 839 Example "review completed" service message: 841 S: 842 S: 846 S: 847 S: 848 S: Command completed successfully; ack to dequeue 849 S: 850 S: 851 S: 1999-04-04T22:01:00.0Z 852 S: Pending action completed successfully. 853 S: 854 S: 855 S: 859 S: ns1.example.com 860 S: 861 S: ABC-12345 862 S: 54322-XYZ 863 S: 864 S: 1999-04-04T22:00:00.0Z 865 S: 866 S: 867 S: 868 S: BCD-23456 869 S: 65432-WXY 870 S: 871 S: 872 S: 874 4. Formal Syntax 876 An EPP object mapping is specified in XML Schema notation. The formal 877 syntax presented here is a complete schema representation of the 878 object mapping suitable for automated validation of EPP XML instances. 879 The BEGIN and END tags are not part of the schema; they are used to 880 note the beginning and ending of the schema for URI registration 881 purposes. 883 BEGIN 884 886 893 896 898 901 902 903 Extensible Provisioning Protocol v1.0 904 host provisioning schema. 905 906 908 911 912 913 914 915 917 920 921 922 923 925 926 928 929 930 931 933 934 935 937 938 939 940 941 942 944 945 946 947 948 949 951 954 955 956 957 958 960 963 964 965 967 968 970 973 974 975 976 978 980 982 983 985 988 989 990 992 994 995 997 1000 1001 1002 1003 1004 1006 1009 1010 1011 1012 1014 1017 1018 1019 1021 1022 1024 1025 1026 1027 1029 1030 1032 1033 1034 1035 1037 1038 1039 1041 1044 1045 1046 1047 1048 1049 1051 1054 1055 1056 1057 1058 1060 1062 1063 1064 1065 1067 1069 1071 1072 1074 1078 1079 1080 1081 1083 1085 1086 1087 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1104 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1119 1120 1121 1123 1126 1127 END 1129 5. Internationalization Considerations 1131 EPP is represented in XML, which provides native support for encoding 1132 information using the Unicode character set and its more compact 1133 representations including UTF-8. Conformant XML processors recognize 1134 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1135 identify and use other character encodings through use of an 1136 "encoding" attribute in an declaration, use of UTF-8 is 1137 RECOMMENDED in environments where parser encoding support 1138 incompatibility exists. 1140 All date-time values presented via EPP MUST be expressed in Universal 1141 Coordinated Time using the Gregorian calendar. XML Schema allows use 1142 of time zone identifiers to indicate offsets from the zero meridian, 1143 but this option MUST NOT be used with EPP. The extended date-time 1144 form using upper case "T" and "Z" characters defined in [RFC3339] MUST 1145 be used to represent date-time values as XML Schema does not support 1146 truncated date-time forms or lower case "T" and "Z" characters. 1148 This document requires host name syntax as specified in [RFC952] as 1149 updated by [RFC1123]. These conformance requirements might change as 1150 a result of progressing work in developing standards for 1151 internationalized host names. 1153 6. IANA Considerations 1155 This document uses URNs to describe XML namespaces and XML schemas 1156 conforming to a registry mechanism described in [IETF-XML]. Two URI 1157 assignments are requested. 1159 Registration request for the host namespace: 1161 URI: urn:ietf:params:xml:ns:host-1.0 1163 Registrant Contact: See the "Author's Address" section of this 1164 document. 1166 XML: None. Namespace URIs do not represent an XML specification. 1168 Registration request for the host XML schema: 1170 URI: urn:ietf:params:xml:schema:host-1.0 1172 Registrant Contact: See the "Author's Address" section of this 1173 document. 1175 XML: See the "Formal Syntax" section of this document. 1177 7. Security Considerations 1179 The object mapping described in this document does not provide any 1180 security services or introduce any additional considerations beyond 1181 those described by [EPP] and protocol layers used by EPP. 1183 8. Acknowledgements 1185 This document was originally written as an individual submission 1186 Internet-Draft. The provreg working group later adopted it as a 1187 working group document and provided many invaluable comments and 1188 suggested improvements. The author wishes to acknowledge the efforts 1189 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1190 editorial contributions. 1192 Specific suggestions that have been incorporated into this document 1193 were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony 1194 Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, 1195 Patrick Mevzek, and Rick Wesson. 1197 9. References 1199 Normative References: 1201 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 1202 progress. 1204 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 1206 [RFC791] J. Postel: "Internet Protocol", RFC 791, September 1981. 1208 [RFC952] K. Harrenstien et al.: "DOD Internet Host Table 1209 Specification", RFC 952, October 1985. 1211 [RFC1034] P. Mockapetris: "DOMAIN NAMES - CONCEPTS AND FACILITIES", 1212 RFC 1034, STD 13, November 1987. 1214 [RFC1035] P. Mockapetris: "DOMAIN NAMES - IMPLEMENTATION AND 1215 SPECIFICATION", RFC 1035, STD 13, November 1987. 1217 [RFC1123] R. Braden: "Requirements for Internet Hosts -- Application 1218 and Support", RFC 1123, October 1989. 1220 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, March 1997. 1223 [RFC3339] G. Klyne, C. Newman: "Date and Time on the Internet: 1224 Timestamps", RFC 3339, July 2002. 1226 [RFC3513] R. Hinden, S. Deering: "IP Version 6 Addressing 1227 Architecture", RFC 3513, April 2003. 1229 [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 1230 (Second Edition)", W3C Recommendation 6 October 2000. 1232 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 1233 W3C Recommendation 2 May 2001. 1235 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 1236 Datatypes", W3C Recommendation 2 May 2001. 1238 Informative References: 1240 [RFC1886] S. Thomson, C. Huitema: "DNS Extensions to support IP 1241 version 6", RFC 1886, December 1995. 1243 [RFC2781] P. Hoffman, F. Yergeau, "UTF-16, an encoding of ISO 10646", 1244 RFC 2781, February 2000. 1246 [RFC2874] M. Crawford, C. Huitema: "DNS Extensions to Support IPv6 1247 Address Aggregation and Renumbering", RFC 2874, July 2000. 1249 [RFC3152] R. Bush: "Delegation of IP6.ARPA", RFC 3152, BCP 49, August 1250 2001. 1252 10. Author's Address 1254 Scott Hollenbeck 1255 VeriSign Global Registry Services 1256 21345 Ridgetop Circle 1257 Dulles, VA 20166-6503 1258 USA 1259 shollenbeck@verisign.com 1261 A. Revisions From Previous Version 1263 (Note to RFC editor: please remove this section completely before 1264 publication as an RFC.) 1266 -06 to -07 (IESG review): 1268 Updated references to use RFC 3513 instead of 2373. 3513 obsoletes 1269 2373. 1271 B. Full Copyright Statement 1273 Copyright (C) The Internet Society 2003. All Rights Reserved. 1275 This document and translations of it may be copied and furnished to 1276 others, and derivative works that comment on or otherwise explain it 1277 or assist in its implementation may be prepared, copied, published and 1278 distributed, in whole or in part, without restriction of any kind, 1279 provided that the above copyright notice and this paragraph are 1280 included on all such copies and derivative works. However, this 1281 document itself may not be modified in any way, such as by removing 1282 the copyright notice or references to the Internet Society or other 1283 Internet organizations, except as needed for the purpose of developing 1284 Internet standards in which case the procedures for copyrights defined 1285 in the Internet Standards process must be followed, or as required to 1286 translate it into languages other than English. 1288 The limited permissions granted above are perpetual and will not be 1289 revoked by the Internet Society or its successors or assigns. 1291 This document and the information contained herein is provided on an 1292 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1293 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1294 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1295 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1296 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1298 Acknowledgement 1300 Funding for the RFC Editor function is currently provided by the 1301 Internet Society.