idnits 2.17.1 draft-hollenbeck-epp-contact-01.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. 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) == Missing Reference: 'IANA-XML' is mentioned on line 1237, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CHARSET' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164a' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164b' -- No information found for draft-ietf-provref-epp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EPP' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- 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' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 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 9, 2001 Expires: October 9, 2001 6 Extensible Provisioning Protocol Contact 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 individual or 33 organizational social information identifiers (known as "contacts") 34 stored in a shared central repository. Specified in XML, the mapping 35 defines EPP command syntax and semantics as applied to contacts. 37 Conventions Used In This Document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 In examples, "C:" represents lines sent by a protocol client and "S:" 44 represents lines returned by a protocol server. Indentation in 45 examples is provided only to illustrate element relationships and is 46 not a REQUIRED feature of this protocol. 48 XML protocol elements are case sensitive. Data carried in XML is case 49 insensitive unless stated otherwise. 51 Table of Contents 53 1. Introduction ................................................. 3 54 2. Object Attributes ............................................ 4 55 2.1 Contact Identifiers ......................................... 4 56 2.2 Client Identifiers .......................................... 4 57 2.3 Individual and Organizational Names ......................... 4 58 2.4 Address ..................................................... 4 59 2.4.1 Street, City, and State or Province ....................... 4 60 2.4.2 Postal Code ............................................... 4 61 2.4.3 Country ................................................... 5 62 2.5 Telephone Numbers ........................................... 5 63 2.6 E-Mail Addresses ............................................ 5 64 2.7 Dates and Times ............................................. 5 65 2.8 Authorization Identifiers ................................... 5 66 3. EPP Command mapping .......................................... 6 67 3.1 EPP Query Commands .......................................... 6 68 3.1.1 EPP Command ....................................... 6 69 3.1.2 EPP Command ........................................ 7 70 3.1.3 EPP Command .................................... 11 71 3.2 EPP Transform Commands ...................................... 13 72 3.2.1 EPP Command ...................................... 13 73 3.2.2 EPP Command ...................................... 15 74 3.2.3 EPP Command ....................................... 16 75 3.2.4 EPP Command .................................... 17 76 3.2.5 EPP Command ...................................... 19 77 4. Formal Syntax ................................................ 22 78 5. Internationalization Considerations .......................... 29 79 6. IANA Considerations .......................................... 29 80 7. Security Considerations ...................................... 29 81 8. References ................................................... 30 82 9. Author's Address ............................................. 32 83 A. Full Copyright Statement ..................................... 33 85 1. Introduction 87 This document describes a personal and organizational identifier 88 mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). 89 This mapping is specified using the Extensible Markup Language (XML) 90 1.0 as described in [XML] and XML Schema notation as described in 91 [XMLS-1] and [XMLS-2]. 93 [EPP] provides a complete description of EPP command and response 94 structures. A thorough understanding of the base protocol 95 specification is necessary to understand the mapping described in this 96 document. 98 It is important to note that XML is case sensitive. XML 99 specifications and examples provided in this document MUST be 100 interpreted in the exact character case presented to develop a 101 conforming implementation. 103 This document is being discussed on the "rrp" mailing list. To join 104 the list, send a message to with the 105 words "subscribe rrp" in the body of the message. There is a web site 106 for the list archives at . 108 2. Object Attributes 110 An EPP contact object has attributes and associated values that may be 111 viewed and modified by the sponsoring client or the server. This 112 section describes each attribute type in detail. The formal syntax 113 for the attribute values described here can be found in the "Formal 114 Syntax" section of this document. 116 2.1 Contact Identifiers 118 All EPP contacts are identified by a server-unique identifier. 119 Contact identifiers are character strings with a specified minimum 120 length, a specified maximum length, and a specified format. Contact 121 identifiers use the "roidType" syntax described in [EPP]. 123 2.2 Client Identifiers 125 All EPP clients are identified by a server-unique identifier. Client 126 identifiers use the "clIDType" syntax described in [EPP]. 128 2.3 Individual and Organizational Names 130 Individual and organizational names associated with a contact are 131 represented using character strings. These strings have a specified 132 minimum length and a specified maximum length. Individual and 133 organizational names MAY be provided in both 7-bit ASCII format 134 defined in [US-ASCII] and UTF-8 format defined in [RFC2279]. 136 2.4 Address 138 Every contact has associated postal address information. A postal 139 address contains street information, city information, OPTIONAL 140 state/province information, a postal code, and a country identifier. 141 Address information MAY be provided in both 7-bit ASCII format defined 142 in [US-ASCII] and UTF-8 format defined in [RFC2279]. Address elements 143 MUST be exchanged in the order described in the protocol schema, but 144 display order MAY be altered to reflect local preferences. 146 2.4.1 Street, City, and State or Province 148 Contact street, city, and state or province information is represented 149 using character strings. These strings have a specified minimum 150 length and a specified maximum length. 152 2.4.2 Postal Code 154 Contact postal codes are represented using character strings. These 155 strings have a specified minimum length and a specified maximum 156 length. 158 2.4.3 Country 160 Contact country identifiers are represented using two-character 161 identifiers specified in [ISO3166]. 163 2.5 Telephone Numbers 165 Contact telephone number structure requirements are defined in 166 [E164a]. Telephone numbers described in this mapping are character 167 strings that MUST begin with a plus sign ("+", ASCII value 0x002B), 168 followed by a country code defined in [E164b], followed by a dot (".", 169 ASCII value 0x002E), followed by a sequence of digits representing the 170 telephone number. An optional "x" attribute is provided to note 171 telephone extension information. 173 2.6 E-Mail Addresses 175 E-mail address syntax is defined in [RFC822]. This mapping does not 176 prescribe minimum or maximum lengths for character strings used to 177 represent e-mail addresses. 179 2.7 Dates and Times 181 Date and time attribute values MUST be represented in Universal 182 Coordinated Time (UTC). Both extended and truncated date and time 183 forms defined in [ISO8601] MAY be used, though a server SHOULD use one 184 form or the other consistently. 186 2.8 Authorization Identifiers 188 Authorization identifiers are associated with contact objects to 189 facilitate authorization of transfer requests. Authorization 190 identifiers use the transaction identifier syntax described in [EPP]. 192 3. EPP Command mapping 194 A detailed description of the EPP syntax and semantics can be found in 195 [EPP]. The command mappings described here are specifically for use 196 in provisioning and managing contact objects via EPP. 198 3.1 EPP Query Commands 200 EPP provides three commands to retrieve contact information: 201 to determine if a contact object is known to the server, to 202 retrieve detailed information associated with a contact object, and 203 to retrieve contact object transfer status information. 205 3.1.1 EPP Command 207 The EPP command is used to determine if a contact object is 208 known to the server. In addition to the standard EPP command 209 elements, the command MUST contain a element 210 that identifies the contact namespace and the location of the contact 211 schema. The element SHALL contain the following child 212 elements: 214 - One or more elements that contain the repository 215 object identifier of the contact objects to be queried. 217 Example command: 219 C: 220 C: 223 C: 224 C: 225 C: 227 C: JD1234-VRSN 228 C: JD1233-VRSN 229 C: JD1232-VRSN 230 C: 231 C: 232 C: 233 C: ABC-12346 234 C: 235 C: 237 When a command has been processed successfully, the EPP 238 element MUST contain a child element that 239 identifies the contact namespace and the location of the contact 240 schema. The element SHALL contain the following 241 child elements: 243 - One or more elements that contain the repository object 244 identifier for the queried contact objects and an "x" attribute whose 245 value identifies the object as either "+" for a known object or "-" 246 for an unknown object. 248 Example response: 250 S: 251 S: 254 S: 255 S: 256 S: Command completed successfully 257 S: 258 S: 259 S: 261 S: JD1234-VRSN 262 S: JD1233-VRSN 263 S: JD1232-VRSN 264 S: 265 S: 266 S: 267 S: 268 S: ABC-12346 269 S: 54322-XYZ 270 S: 271 S: 272 S: 274 An EPP error response MUST be returned if a command can not be 275 processed for any reason. 277 3.1.2 EPP Command 279 The EPP command is used to retrieve information associated with 280 a contact object. In addition to the standard EPP command elements, 281 the command MUST contain a element that 282 identifies the contact namespace and the location of the contact 283 schema. The element SHALL contain the following child 284 elements: 286 - A element that contains the repository object 287 identifier of the contact object to be queried. 289 Example command: 291 C: 292 C: 295 C: 296 C: 297 C: 299 C: JD1234-VRSN 300 C: 301 C: 302 C: 303 C: ABC-12346 304 C: 305 C: 307 When an command has been processed successfully, the EPP 308 element MUST contain a child element that 309 identifies the contact namespace and the location of the contact 310 schema. The element SHALL contain the following 311 child elements: 313 - A element that contains the contact object's 314 repository object identifier. 316 - A element that contains child element social 317 information represented in 7-bit US-ASCII. 319 - A ("i15d" is short for "internationalized") element 320 that contains child element social information represented in UTF-8 321 characters other than those represented in the US-ASCII character set. 322 The and elements SHALL contain the 323 following child elements: 325 - A element that contains the name of the individual 326 or role represented by the contact. 328 - An OPTIONAL element that contains the name of the 329 organization with which the contact is affiliated. 331 - A element that contains address information 332 associated with the contact. A element SHALL contain 333 the following child elements: 335 - One, two, or three elements that contain the 336 contact's street address. 338 - A element that contains the contact's city. 340 - An OPTIONAL element that contains the contact's 341 state or province. 343 - A element that contains the contact's postal code. 345 - A element that contains the contact's country code. 347 - An OPTIONAL element that contains the contact's 348 voice telephone number. 350 - An OPTIONAL element that contains the contact's 351 facsimile telephone number. 353 - A element that contains the contact's e-mail 354 address. 356 - A element that contains the identifier of the 357 sponsoring client. 359 - A element that contains the identifier of the client 360 that created the contact object. 362 - A element that contains the date and time of 363 contact object creation. 365 - A element that contains the identifier of the client 366 that last updated the contact object. This element MUST NOT be 367 present if the contact has never been modified. 369 - A element that contains the date and time of the 370 most recent contact object modification. This element MUST NOT be 371 present if the contact object has never been modified. 373 - A elements that contains the date and time of the 374 most recent successful contact object transfer. This element MUST NOT 375 be provided if the contact object has never been transferred. 377 - A element derived from either the original contact 378 object creation transaction or the most recent successful transfer 379 transaction. This element MUST NOT be provided if the querying client 380 is not the current sponsoring client. 382 Example response: 384 S: 385 S: 388 S: 389 S: 390 S: Command completed successfully 391 S: 392 S: 393 S: 395 S: JD1234-VRSN 396 S: 397 S: John Doe 398 S: Example Inc. 399 S: 400 S: 123 Example Dr. 401 S: Suite 100 402 S: Dulles 403 S: VA 404 S: 20166-6503 405 S: US 406 S: 407 S: 408 S: +1.7035555555 409 S: +1.7035555556 410 S: jdoe@example.com 411 S: ClientY 412 S: ClientX 413 S: 1999-04-03T22:00:00.0Z 414 S: ClientX 415 S: 1999-12-03T09:00:00.0Z 416 S: 2000-04-08T09:00:00.0Z 417 S: 418 S: ABC-12345 419 S: 54321-XYZ 420 S: 421 S: 422 S: 423 S: 424 S: 425 S: ABC-12346 426 S: 54322-XYZ 427 S: 428 S: 429 S: 431 An EPP error response MUST be returned if an command can not be 432 processed for any reason. 434 3.1.3 EPP Command 436 The EPP command provides a query operation that allows a 437 client to determine real-time status of pending and completed transfer 438 requests. In addition to the standard EPP command elements, the 439 command MUST contain an "op" attribute with value "query", 440 and a element that identifies the contact 441 namespace and the location of the contact schema. The 442 element MUST contain the following child elements: 444 - A element that contains the repository object 445 identifier of the contact object to be queried. 447 Example query command: 449 C: 450 C: 453 C: 454 C: 455 C: 457 C: JD1234-VRSN 458 C: 459 C: 460 C: ABC-12345 461 C: 54321-XYZ 462 C: 463 C: 464 C: 465 C: ABC-12346 466 C: 467 C: 469 When a query command has been processed successfully, the 470 EPP element MUST contain a child element 471 that identifies the contact namespace and the location of the contact 472 schema. The element SHALL contain the following 473 child elements: 475 - A element that contains the contact object's 476 repository object identifier. 478 - A element that contains the state of the most 479 recent transfer request. Valid values are "PENDING", "APPROVED", 480 "REJECTED", "AUTO-APPROVED", "AUTO-REJECTED", and "CANCELLED". 482 - A element that contains the identifier of the client 483 that requested the object transfer. 485 - A element that contains the date and time that the 486 transfer was requested. 488 - A element that contains the identifier of the client 489 that SHOULD act upon the transfer request. 491 - A element that contains the date and time of a 492 required or completed response. For a PENDING request, the value 493 identifies the date and time by which a response is required before an 494 automated response action MUST be taken by the server. For all other 495 status types, the value identifies the date and time when the request 496 was completed. 498 Example query response: 500 S: 501 S: 504 S: 505 S: 506 S: Command completed successfully 507 S: 508 S: 509 S: 511 S: JD1234-VRSN 512 S: PENDING 513 S: ClientX 514 S: 2000-06-06T22:00:00.0Z 515 S: ClientY 516 S: 2000-06-11T22:00:00.0Z 517 S: 518 S: 519 S: 520 S: 521 S: ABC-12346 522 S: 54322-XYZ 523 S: 524 S: 525 S: 526 An EPP error response MUST be returned if a query command 527 can not be processed for any reason. 529 3.2 EPP Transform Commands 531 EPP provides four commands to transform contact object information: 532 to create an instance of a contact object, to delete 533 an instance of a contact object, to manage contact object 534 sponsorship changes, and to change information associated 535 with a contact object. This document does not define a mapping for 536 the EPP command. 538 3.2.1 EPP Command 540 The EPP command provides a transform operation that allows a 541 client to create a contact object. In addition to the standard EPP 542 command elements, the command MUST contain a 543 element that identifies the contact namespace and the location of the 544 contact schema. The element SHALL contain the 545 following child elements: 547 - A element that contains child element social 548 information represented in 7-bit US-ASCII. 550 - An OPTIONAL ("i15d" is short for "internationalized") 551 element that contains child element social information represented in 552 UTF-8 characters other than those represented in the US-ASCII 553 character set. The and elements SHALL 554 contain the following child elements: 556 - A element that contains the name of the individual 557 or role represented by the contact. 559 - An OPTIONAL element that contains the name of the 560 organization with which the contact is affiliated. 562 - A element that contains address information 563 associated with the contact. A element SHALL contain 564 the following child elements: 566 - One, two, or three elements that contain the 567 contact's street address. 569 - A element that contains the contact's city. 571 - An OPTIONAL element that contains the contact's 572 state or province. 574 - A element that contains the contact's postal code. 576 - A element that contains the contact's country code. 578 - An OPTIONAL element that contains the contact's 579 voice telephone number. 581 - An OPTIONAL element that contains the contact's 582 facsimile telephone number. 584 - A element that contains the contact's e-mail 585 address. 587 Example command: 589 C: 590 C: 593 C: 594 C: 595 C: 597 C: 598 C: John Doe 599 C: Example Inc. 600 C: 601 C: 123 Example Dr. 602 C: Suite 100 603 C: Dulles 604 C: VA 605 C: 20166-6503 606 C: US 607 C: 608 C: 609 C: +1.7035555555 610 C: +1.7035555556 611 C: jdoe@example.com 612 C: 613 C: 614 C: 615 C: ABC-12345 616 C: 617 C: 619 When a command has been processed successfully, the EPP 620 element MUST contain a child element that 621 identifies the contact namespace and the location of the contact 622 schema. The element SHALL contain the following 623 child elements: 625 - A element that contains the contact object's 626 repository object identifier. 628 Example response: 630 S: 631 S: 634 S: 635 S: 636 S: Command completed successfully 637 S: 638 S: 639 S: 641 S: JD1234-VRSN 642 S: 643 S: 644 S: 645 S: 646 S: ABC-12345 647 S: 54321-XYZ 648 S: 649 S: 650 S: 652 An EPP error response MUST be returned if a command can not 653 be processed for any reason. 655 3.2.2 EPP Command 657 The EPP command provides a transform operation that allows a 658 client to delete a contact object. In addition to the standard EPP 659 command elements, the command MUST contain a 660 element that identifies the contact namespace and the location of the 661 contact schema. The element MUST contain the 662 following child elements: 664 - A element that contains the repository object 665 identifier of the contact object to be deleted. 667 A contact object MUST NOT be deleted if it is associated with other 668 known objects. An associated contact MUST NOT be deleted until the 669 association with other known objects has been broken. 671 Example command: 673 C: 674 C: 677 C: 678 C: 679 C: 681 C: JD1234-VRSN 682 C: 683 C: 684 C: ABC-12345 685 C: 54321-XYZ 686 C: 687 C: 688 C: 689 C: ABC-12346 690 C: 691 C: 693 When a command has been processed successfully, a server MUST 694 respond with an EPP response with no element. 696 Example response: 698 S: 699 S: 702 S: 703 S: 704 S: Command completed successfully 705 S: 706 S: 707 S: 708 S: ABC-12346 709 S: 54322-XYZ 710 S: 711 S: 712 S: 714 An EPP error response MUST be returned if a command can not 715 be processed for any reason. 717 3.2.3 EPP Command 718 Renewal semantics do not apply to contact objects, so there is no 719 mapping defined for the EPP command. 721 3.2.4 EPP Command 723 The EPP command provides a transform operation that allows 724 a client to manage requests to transfer the sponsorship of a contact 725 object. In addition to the standard EPP command elements, the 726 command MUST contain a element that 727 identifies the contact namespace and the location of the contact 728 schema. The element SHALL contain the following 729 child elements: 731 - A element that contains the repository object 732 identifier of the contact object for which a transfer request is to be 733 created, approved, rejected, or cancelled. 735 Every EPP command MUST contain an "op" attribute that 736 identifies the transfer operation to be performed. Valid values, 737 definitions, and authorizations for all attribute values are defined 738 in [EPP]. 740 Every EPP command MUST also contain an authorization 741 identifier as described in [EPP]. It is important to note that the 742 transaction identifier associated with successful transfer of a domain 743 object becomes the authorization identifier required to transfer 744 sponsorship of the domain object. A client MUST retain all 745 transaction identifiers associated with domain object creation and 746 protect them from disclosure. A client acting as a proxy for a 747 registrant MUST provide a copy of the transaction identifier 748 information to the registrant, who will need this information to 749 request a domain transfer through a different client. 751 Example request command: 753 C: 754 C: 757 C: 758 C: 759 C: 761 C: JD1234-VRSN 762 C: 763 C: 764 C: ABC-12345 765 C: 54321-XYZ 766 C: 767 C: 768 C: 769 C: ABC-12346 770 C: 771 C: 773 When a command has been processed successfully, the EPP 774 element MUST contain a child element that 775 identifies the contact namespace and the location of the contact 776 schema. The element SHALL contain the same child 777 elements defined for a transfer query response. 779 Example response: 781 S: 782 S: 785 S: 786 S: 787 S: Command completed successfully 788 S: 789 S: 790 S: 792 S: JD1234-VRSN 793 S: PENDING 794 S: ClientX 795 S: 2000-06-08T22:00:00.0Z 796 S: ClientY 797 S: 2000-06-13T22:00:00.0Z 798 S: 799 S: 800 S: 801 S: 802 S: ABC-12346 803 S: 54322-XYZ 804 S: 805 S: 806 S: 808 An EPP error response MUST be returned if a command can not 809 be processed for any reason. 811 3.2.5 EPP Command 813 The EPP command provides a transform operation that allows a 814 client to modify the attributes of a contact object. In addition to 815 the standard EPP command elements, the command MUST contain a 816 element that identifies the contact namespace and the 817 location of the contact schema. The element SHALL 818 contain the following child elements: 820 - A element that contains the repository object 821 identifier of the contact object to be updated. 823 - A element that contains object attribute values to be 824 changed. The element SHALL contain the following 825 OPTIONAL child elements: 827 - A element that contains the name of the individual 828 or role represented by the contact. 830 - A element that contains the name of the organization 831 with which the contact is affiliated. 833 - A element that contains address information 834 associated with the contact. A element SHALL contain 835 the following OPTIONAL child elements: 837 - One, two, or three elements that contain the 838 contact's street address. 840 - A element that contains the contact's city. 842 - A element that contains the contact's state or 843 province. 845 - A element that contains the contact's postal code. 847 - A element that contains the contact's country code. 849 - A element that contains the contact's voice 850 telephone number. 852 - A element that contains the contact's facsimile 853 telephone number. 855 - A element that contains the contact's e-mail 856 address. 858 Example command: 860 C: 861 C: 864 C: 865 C: 866 C: 868 C: JD1234-VRSN 869 C: 870 C: 871 C: 872 C: 873 C: 124 Example Dr. 874 C: Suite 200 875 C: Dulles 876 C: VA 877 C: 20166-6503 878 C: US 879 C: 880 C: 881 C: +1.7034444444 882 C: 883 C: 884 C: 885 C: 886 C: ABC-12345 887 C: 54321-XYZ 888 C: 889 C: 890 C: 891 C: ABC-12346 892 C: 893 C: 895 When an command has been processed successfully, a server 896 MUST respond with an EPP response with no element. 898 Example response: 900 S: 901 S: 904 S: 905 S: 906 S: Command completed successfully 907 S: 908 S: 909 S: 910 S: ABC-12346 911 S: 54322-XYZ 912 S: 913 S: 914 S: 916 An EPP error response MUST be returned if an command can not 917 be processed for any reason. 919 4. Formal Syntax 921 An EPP object mapping is specified in XML Schema notation. The formal 922 syntax presented here is a complete schema representation of the 923 object mapping suitable for automated validation of EPP XML instances. 925 927 934 937 939 942 943 944 Extensible Provisioning Protocol v1.0 945 contact provisioning schema. 946 947 949 952 954 957 958 959 960 961 962 963 965 968 969 970 971 972 973 975 976 977 978 979 980 982 983 984 985 986 987 989 990 991 992 994 996 997 998 999 1000 1001 1002 1004 1005 1006 1007 1008 1009 1010 1012 1013 1014 1015 1016 1018 1019 1020 1021 1022 1024 1025 1026 1027 1028 1029 1031 1034 1035 1036 1037 1039 1040 1043 1044 1045 1047 1048 1049 1050 1052 1053 1054 1056 1057 1058 1060 1061 1063 1064 1065 1066 1068 1071 1072 1073 1074 1075 1077 1080 1081 1082 1084 1085 1087 1090 1091 1092 1093 1095 1096 1098 1101 1102 1103 1105 1107 1109 1111 1113 1114 1116 1119 1120 1121 1123 1125 1127 1128 1130 1133 1134 1135 1136 1138 1141 1142 1143 1145 1146 1148 1149 1150 1151 1153 1154 1155 1157 1160 1161 1162 1163 1164 1166 1169 1170 1171 1172 1173 1175 1176 1178 1179 1180 1181 1182 1184 1186 1188 1190 1191 1193 1196 1197 1198 1199 1200 1201 1202 1203 1204 1206 1207 1209 1212 1214 5. Internationalization Considerations 1216 EPP is represented in XML, which provides native support for encoding 1217 information using the double-byte Unicode character set and its more 1218 compact representations including UTF-8. Compliant XML processors are 1219 required to understand both UTF-8 and raw Unicode character sets; XML 1220 also includes a provision for identifying other character sets through 1221 use of an "encoding" attribute in an processing instruction. 1222 The complete list of character set encoding identifiers is maintained 1223 by IANA and is described in [CHARSET] and [RFC1700]. 1225 All date-time values presented via EPP MUST be expressed in Universal 1226 Coordinated Time. The XML Schema "date" format allows use of time 1227 zone identifiers to indicate offsets from the zero meridian, but this 1228 option MUST NOT be used within EPP. Both extended and truncated date 1229 and time forms defined in [ISO8601] MAY be used. 1231 6. IANA Considerations 1233 XML schemas require a URI for unique identification. Schemas MUST be 1234 registered to ensure URI uniqueness, but the IETF does not currently 1235 have a recommended repository for the registration of XML schemas. 1236 This document uses URNs to describe XML namespaces and XML schemas 1237 conforming to a registry mechanism described in [IANA-XML]. 1239 IANA SHOULD maintain a registry of XML namespace and schema URI 1240 assignments. Per policies described in [IANA], URI assignment 1241 requests SHOULD be reviewed by a designated expert, and values SHOULD 1242 be assigned only as a result of standards action taken by the IESG. 1244 This document requests assignment of the following URIs: 1246 urn:iana:xml:ns:contact: The XML namespace URI for this EPP contact 1247 mapping. 1249 urn:iana:xml:xmlschema:contact: The XML Schema URI for this EPP 1250 contact mapping. 1252 7. Security Considerations 1254 The object mapping described in this document does not provide any 1255 security services beyond those specified by [EPP] and protocol layers 1256 used by EPP. 1258 8. References 1260 [CHARSET] ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 1262 [E164a] ITU-T Recommendation E.164: "The International Public 1263 Telecommunication Numbering Plan", May 1997. 1265 [E164b] Complement To ITU-T Recommendation E.164 (05/1997): "List of 1266 ITU-T Recommendation E.164 assigned country codes", June 2000. 1268 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", draft-ietf- 1269 provref-epp-01.txt, work in progress. 1271 [IANA] T. Narten, H. Alvestrand: "Guidelines for Writing an IANA 1272 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1274 [ISO3166] ISO 3166-1: "Codes for the representation of names of 1275 countries and their subdivisions - Part 1: Country codes", October 1276 1997. 1278 [ISO8601] ISO 8601:1988 (E): "Data elements and interchange formats - 1279 Information interchange - Representation of dates and times - The 1280 International Organization for Standardization". 1282 [RFC822] D. Crocker: "Standard for the Format Of ARPA Internet Text 1283 Messages", RFC 822, August 1982. 1285 [RFC1700] J. Reynolds, J. Postel: "Assigned Numbers", STD 2, RFC 1700, 1286 October 1994. 1288 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 1289 Requirement Levels", BCP 14, RFC 2119, March 1997. 1291 [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646", 1292 RFC 2279, January 1998. 1294 [US-ASCII] Coded Character Set -- 7-bit American Standard Code for 1295 Information Interchange, ANSI X3.4-1986; also: ISO/IEC 646 (IRV). 1297 [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 1298 (Second Edition)", http://www.w3.org/TR/REC-xml, W3C Recommendation 6 1299 October 2000. 1301 [XMLS-1] Editor H. Thompson et al.: "XML Schema Part 1: Structures", 1302 http://www.w3.org/TR/xmlschema-1, W3C Candidate Recommendation 24 1303 October 2000. 1305 [XMLS-2] Editors P. Biron and A. Malhotra: "XML Schema Part 2: 1307 Datatypes", http://www.w3.org/TR/xmlschema-2, W3C Candidate 1308 Recommendation 24 October 2000. 1310 9. Author's Address 1312 Scott Hollenbeck 1313 VeriSign Global Registry Services 1314 21345 Ridgetop Circle 1315 Dulles, VA 20166-6503 1316 USA 1317 shollenbeck@verisign.com 1319 A. Full Copyright Statement 1321 Copyright (C) The Internet Society 2001. All Rights Reserved. 1323 This document and translations of it may be copied and furnished to 1324 others, and derivative works that comment on or otherwise explain it 1325 or assist in its implementation may be prepared, copied, published and 1326 distributed, in whole or in part, without restriction of any kind, 1327 provided that the above copyright notice and this paragraph are 1328 included on all such copies and derivative works. However, this 1329 document itself may not be modified in any way, such as by removing 1330 the copyright notice or references to the Internet Society or other 1331 Internet organizations, except as needed for the purpose of developing 1332 Internet standards in which case the procedures for copyrights defined 1333 in the Internet Standards process must be followed, or as required to 1334 translate it into languages other than English. 1336 The limited permissions granted above are perpetual and will not be 1337 revoked by the Internet Society or its successors or assigns. 1339 This document and the information contained herein is provided on an 1340 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1341 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1342 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1343 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1344 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1346 Acknowledgement 1348 Funding for the RFC Editor function is currently provided by the 1349 Internet Society.