idnits 2.17.1 draft-ietf-provreg-epp-contact-04.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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. 'DATE-TIME' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Possible downref: Non-RFC (?) normative reference: ref. 'E164a' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164b' -- 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 January 24, 2002 Expires: July 24, 2002 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 and white 45 space in examples is provided only to illustrate element relationships 46 and is not a REQUIRED feature of this protocol. 48 Table of Contents 50 1. Introduction ................................................. 3 51 2. Object Attributes ............................................ 4 52 2.1 Contact and Client Identifiers .............................. 4 53 2.2 Status Values ............................................... 4 54 2.3 Individual and Organizational Names ......................... 5 55 2.4 Address ..................................................... 5 56 2.4.1 Street, City, and State or Province ....................... 6 57 2.4.2 Postal Code ............................................... 6 58 2.4.3 Country ................................................... 6 59 2.5 Telephone Numbers ........................................... 6 60 2.6 Email Addresses ............................................. 6 61 2.7 Dates and Times ............................................. 6 62 2.8 Authorization Information ................................... 6 63 3. EPP Command mapping .......................................... 8 64 3.1 EPP Query Commands .......................................... 8 65 3.1.1 EPP Command ....................................... 8 66 3.1.2 EPP Command ........................................ 10 67 3.1.3 EPP Command .................................... 14 68 3.2 EPP Transform Commands ...................................... 16 69 3.2.1 EPP Command ...................................... 16 70 3.2.2 EPP Command ...................................... 19 71 3.2.3 EPP Command ....................................... 21 72 3.2.4 EPP Command .................................... 21 73 3.2.5 EPP Command ...................................... 22 74 4. Formal Syntax ................................................ 27 75 5. Internationalization Considerations .......................... 34 76 6. IANA Considerations .......................................... 34 77 7. Security Considerations ...................................... 35 78 8. Acknowledgements ............................................. 35 79 9. References ................................................... 36 80 10. Author's Address ............................................ 37 81 A. Revisions From Previous Version .............................. 38 82 B. Full Copyright Statement ..................................... 39 84 1. Introduction 86 This document describes a personal and organizational identifier 87 mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). 88 This mapping is specified using the Extensible Markup Language (XML) 89 1.0 as described in [XML] and XML Schema notation as described in 90 [XMLS-1] and [XMLS-2]. 92 [EPP] provides a complete description of EPP command and response 93 structures. A thorough understanding of the base protocol 94 specification is necessary to understand the mapping described in this 95 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 This document is being discussed on the "ietf-provreg" mailing list. 102 To join the list, send a message to with the 103 words "subscribe ietf-provreg" in the body of the message. There is a 104 web site for the list archives at http://www.cafax.se/ietf-provreg. 106 2. Object Attributes 108 An EPP contact object has attributes and associated values that can be 109 viewed and modified by the sponsoring client or the server. This 110 section describes each attribute type in detail. The formal syntax 111 for the attribute values described here can be found in the "Formal 112 Syntax" section of this document and in the appropriate normative 113 references. 115 2.1 Contact and Client Identifiers 117 All EPP contacts are identified by a server-unique identifier. 118 Contact identifiers are character strings with a specified minimum 119 length, a specified maximum length, and a specified format. Contact 120 identifiers use the "clIDType" client identifier syntax described in 121 [EPP]. 123 2.2 Status Values 125 A contact object MUST always have at least one associated status 126 value. Status values can be set only by the client that sponsors a 127 contact object and by the server on which the object resides. A 128 client can change the status of a contact object using the EPP 129 command. Each status value MAY be accompanied by a string of 130 human-readable text that describes the rationale for the status 131 applied to the object. 133 A client MUST NOT alter status values set by the server. A server MAY 134 alter or override status values set by a client subject to local 135 server policies. 137 Status values that can be added or removed by a client are prefixed 138 with "client". Corresponding status values that can be added or 139 removed by a server are prefixed with "server". Status values that do 140 not begin with either "client" or "server" are server-managed. 142 Status Value Descriptions: 144 clientDeleteProhibited, serverDeleteProhibited 146 Requests to delete the object MUST be rejected. 148 clientTransferProhibited, serverTransferProhibited 150 Requests to transfer the object MUST be rejected. 152 clientUpdateProhibited, serverUpdateProhibited 153 Requests to update the object (other than to remove this status) MUST 154 be rejected. 156 linked 158 The contact object has at least one active association with another 159 object, such as a domain object. Servers SHOULD provide services to 160 determine existing object associations. 162 ok 164 This is the nominal status value for an object that has no pending 165 operations or prohibitions. 167 pendingDelete 169 A delete request has been received for the object, but the object has 170 not yet been purged from the server database. 172 pendingTransfer 174 A transfer request has been received for the object, and completion of 175 the request is pending. Transform commands other than MUST 176 be rejected while an object is in this state. 178 "ok" status MAY only be combined with "linked" status. "linked" 179 status MAY be combined with any status. "pendingDelete" status MUST 180 NOT be combined with either "clientDeleteProhibited" or 181 "serverDeleteProhibited" status. "pendingTransfer" status MUST NOT be 182 combined with either "clientTransferProhibited" or 183 "serverTransferProhibited" status. All other status value 184 combinations are valid. 186 2.3 Individual and Organizational Names 188 Individual and organizational names associated with a contact are 189 represented using character strings. These strings have a specified 190 minimum length and a specified maximum length. Individual and 191 organizational names MAY be provided in both UTF-8 [RFC2279] and a 192 subset of UTF-8 that can be represented in 7-bit ASCII depending on 193 local needs. 195 2.4 Address 197 Every contact has associated postal address information. A postal 198 address contains OPTIONAL street information, city information, 199 OPTIONAL state/province information, an OPTIONAL postal code, and a 200 country identifier. Address information MAY be provided in both UTF-8 201 and a subset of UTF-8 that can be represented in 7-bit ASCII depending 202 on local needs. 204 2.4.1 Street, City, and State or Province 206 Contact street, city, and state or province information is represented 207 using character strings. These strings have a specified minimum 208 length and a specified maximum length. 210 2.4.2 Postal Code 212 Contact postal codes are represented using character strings. These 213 strings have a specified minimum length and a specified maximum 214 length. 216 2.4.3 Country 218 Contact country identifiers are represented using two-character 219 identifiers specified in [ISO3166]. 221 2.5 Telephone Numbers 223 Contact telephone number structure is derived from structures defined 224 in [E164a]. Telephone numbers described in this mapping are character 225 strings that MUST begin with a plus sign ("+", ASCII value 0x002B), 226 followed by a country code defined in [E164b], followed by a dot (".", 227 ASCII value 0x002E), followed by a sequence of digits representing the 228 telephone number. An optional "x" attribute is provided to note 229 telephone extension information. 231 2.6 Email Addresses 233 Email address syntax is defined in [RFC2822]. This mapping does not 234 prescribe minimum or maximum lengths for character strings used to 235 represent email addresses. 237 2.7 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 defined in [DATE-TIME] MUST be used to represent date- 242 time values as XML Schema does not support truncated date-time forms. 244 2.8 Authorization Information 246 Authorization information is associated with contact objects to 247 facilitate transfer operations. Authorization information is assigned 248 when a contact object is created, and it might be updated in the 249 future. This specification describes password-based authorization 250 information, though other mechanisms are possible. 252 3. EPP Command mapping 254 A detailed description of the EPP syntax and semantics can be found in 255 [EPP]. The command mappings described here are specifically for use 256 in provisioning and managing contact objects via EPP. 258 3.1 EPP Query Commands 260 EPP provides three commands to retrieve contact information: 261 to determine if a contact object can be provisioned within a 262 repository, to retrieve detailed information associated with a 263 contact object, and to retrieve contact object transfer 264 status information. 266 3.1.1 EPP Command 268 The EPP command is used to determine if an object can be 269 provisioned within a repository. It provides a hint that allows a 270 client to anticipate the success or failure of provisioning an object 271 using the command. Object availability and provisioning 272 conditions are a matter of server policy. 274 In addition to the standard EPP command elements, the command 275 MUST contain a element that identifies the contact 276 namespace and the location of the contact schema. The 277 element contains the following child elements: 279 - One or more elements that contain the server-unique 280 identifier of the contact objects to be queried. 282 Example command: 284 C: 285 C: 289 C: 290 C: 291 C: 295 C: sh8013 296 C: sah8013 297 C: 8013sah 298 C: 299 C: 300 C: ABC-12345 301 C: 302 C: 304 When a command has been processed successfully, the EPP 305 element MUST contain a child element that 306 identifies the contact namespace and the location of the contact 307 schema. The element contains one or more 308 elements that contain the following child elements: 310 - A element that identifies the queried object. This 311 element MUST contain an "avail" attribute whose value indicates object 312 availability at the moment the command was completed. A value 313 of "1" or "true" means that the object is available. A value of "0" 314 or "false" means that the object is not available. 316 - An OPTIONAL element that MAY be provided when an 317 object is not available for provisioning. If present, this element 318 contains server-specific text to help explain why the object is 319 unavailable. This text MUST be represented in the response language 320 previously negotiated with the client; an OPTIONAL "lang" attribute 321 MAY be present to identify the language if the negotiated value is 322 something other than the default value of "en" (English). 324 Example response: 326 S: 327 S: 331 S: 332 S: 333 S: Command completed successfully 334 S: 335 S: 336 S: 340 S: 341 S: sh8013 342 S: 343 S: 344 S: sah8013 345 S: In use 346 S: 347 S: 348 S: 8013sah 349 S: 350 S: 351 S: 352 S: 353 S: ABC-12345 354 S: 54322-XYZ 355 S: 356 S: 357 S: 359 An EPP error response MUST be returned if a command can not be 360 processed for any reason. 362 3.1.2 EPP Command 364 The EPP command is used to retrieve information associated with 365 a contact object. In addition to the standard EPP command elements, 366 the command MUST contain a element that 367 identifies the contact namespace and the location of the contact 368 schema. The element contains the following child 369 elements: 371 - A element that contains the server-unique identifier of 372 the contact object to be queried. 374 Example command: 376 C: 377 C: 381 C: 382 C: 383 C: 387 C: sh8013 388 C: 389 C: 390 C: ABC-12345 391 C: 392 C: 394 When an command has been processed successfully, the EPP 395 element MUST contain a child element that 396 identifies the contact namespace and the location of the contact 397 schema. The element contains the following child 398 elements: 400 - A element that contains the server-unique identifier of 401 the contact object. 403 - A element that contains the Repository Object 404 IDentifier assigned to the contact object when the object was created. 406 - One or more elements that describe the status of 407 the contact object. 409 - One or two elements that contain postal address 410 information. Two elements are provided so that address information 411 can be provided in both internationalized and localized forms. If an 412 internationalized form is provided, it MUST be listed first and 413 element content MUST be represented in a subset of UTF-8 that can be 414 represented in the 7-bit US-ASCII character set. If a localized form 415 is provided, element content MAY be represented in unrestricted UTF-8. 416 The element contains the following child 417 elements: 419 - A element that contains the name of the individual 420 or role represented by the contact. 422 - An OPTIONAL element that contains the name of the 423 organization with which the contact is affiliated. 425 - A element that contains address information 426 associated with the contact. A element contains the 427 following child elements: 429 - One, two, or three OPTIONAL elements that 430 contain the contact's street address. 432 - A element that contains the contact's city. 434 - An OPTIONAL element that contains the contact's 435 state or province. 437 - An OPTIONAL element that contains the contact's 438 postal code. 440 - A element that contains the contact's country code. 442 - An OPTIONAL element that contains the contact's 443 voice telephone number. 445 - An OPTIONAL element that contains the contact's 446 facsimile telephone number. 448 - A element that contains the contact's email address. 450 - A element that contains the identifier of the 451 sponsoring client. 453 - A element that contains the identifier of the client 454 that created the contact object. 456 - A element that contains the date and time of 457 contact object creation. 459 - A element that contains the identifier of the client 460 that last updated the contact object. This element MUST NOT be 461 present if the contact has never been modified. 463 - A element that contains the date and time of the 464 most recent contact object modification. This element MUST NOT be 465 present if the contact object has never been modified. 467 - A elements that contains the date and time of the 468 most recent successful contact object transfer. This element MUST NOT 469 be provided if the contact object has never been transferred. 471 - A element that contains authorization information 472 associated with the contact object. This element MUST NOT be provided 473 if the querying client is not the current sponsoring client. 475 Example response: 477 S: 478 S: 482 S: 483 S: 484 S: Command completed successfully 485 S: 486 S: 487 S: 491 S: sh8013 492 S: SH8013-REP 493 S: 494 S: 495 S: 496 S: John Doe 497 S: Example Inc. 498 S: 499 S: 123 Example Dr. 500 S: Suite 100 501 S: Dulles 502 S: VA 503 S: 20166-6503 504 S: US 505 S: 506 S: 507 S: +1.7035555555 508 S: +1.7035555556 509 S: jdoe@example.tld 510 S: ClientY 511 S: ClientX 512 S: 1999-04-03T22:00:00.0Z 513 S: ClientX 514 S: 1999-12-03T09:00:00.0Z 515 S: 2000-04-08T09:00:00.0Z 516 S: 2fooBAR 517 S: 518 S: 519 S: 520 S: ABC-12345 521 S: 54322-XYZ 522 S: 523 S: 524 S: 526 An EPP error response MUST be returned if an command can not be 527 processed for any reason. 529 3.1.3 EPP Command 531 The EPP command provides a query operation that allows a 532 client to determine real-time status of pending and completed transfer 533 requests. In addition to the standard EPP command elements, the 534 command MUST contain an "op" attribute with value "query", 535 and a element that identifies the contact namespace 536 and the location of the contact schema. The 537 element MUST contain the following child elements: 539 - A element that contains the server-unique identifier of 540 the contact object to be queried. 542 - A element that contains authorization information 543 associated with the contact object. 545 Example query command: 547 C: 548 C: 552 C: 553 C: 554 C: 558 C: sh8013 559 C: 2fooBAR 560 C: 561 C: 562 C: ABC-12345 563 C: 564 C: 566 When a query command has been processed successfully, the 567 EPP element MUST contain a child element 568 that identifies the contact namespace and the location of the contact 569 schema. The element contains the following child 570 elements: 572 - A element that contains the server-unique identifier 573 for the queried contact. 575 - A element that contains the state of the most 576 recent transfer request. 578 - A element that contains the identifier of the client 579 that requested the object transfer. 581 - A element that contains the date and time that the 582 transfer was requested. 584 - A element that contains the identifier of the client 585 that SHOULD act upon the transfer request. 587 - A element that contains the date and time of a 588 required or completed response. For a pending request, the value 589 identifies the date and time by which a response is required before an 590 automated response action SHOULD be taken by the server. For all 591 other status types, the value identifies the date and time when the 592 request was completed. 594 Example query response: 596 S: 597 S: 601 S: 602 S: 603 S: Command completed successfully 604 S: 605 S: 606 S: 610 S: sh8013 611 S: pending 612 S: ClientX 613 S: 2000-06-06T22:00:00.0Z 614 S: ClientY 615 S: 2000-06-11T22:00:00.0Z 616 S: 617 S: 618 S: 619 S: ABC-12345 620 S: 54322-XYZ 621 S: 622 S: 623 S: 625 An EPP error response MUST be returned if a query command 626 can not be processed for any reason. 628 3.2 EPP Transform Commands 630 EPP provides four commands to transform contact object information: 631 to create an instance of a contact object, to delete 632 an instance of a contact object, to manage contact object 633 sponsorship changes, and to change information associated 634 with a contact object. This document does not define a mapping for 635 the EPP command. 637 3.2.1 EPP Command 639 The EPP command provides a transform operation that allows a 640 client to create a contact object. In addition to the standard EPP 641 command elements, the command MUST contain a 642 element that identifies the contact namespace and the location of the 643 contact schema. The element contains the following 644 child elements: 646 - A element that contains the desired server-unique 647 identifier for the contact to be created. 649 - One or two elements that contain postal address 650 information. Two elements are provided so that address information 651 can be provided in both internationalized and localized forms. If an 652 internationalized form is provided, it MUST be listed first and 653 element content MUST be represented in a subset of UTF-8 that can be 654 represented in the 7-bit US-ASCII character set. If a localized form 655 is provided, element content MAY be represented in unrestricted UTF-8. 656 The element contains the following child 657 elements: 659 - A element that contains the name of the individual 660 or role represented by the contact. 662 - An OPTIONAL element that contains the name of the 663 organization with which the contact is affiliated. 665 - A element that contains address information 666 associated with the contact. A element contains the 667 following child elements: 669 - One, two, or three OPTIONAL elements that 670 contain the contact's street address. 672 - A element that contains the contact's city. 674 - An OPTIONAL element that contains the contact's 675 state or province. 677 - An OPTIONAL element that contains the contact's 678 postal code. 680 - A element that contains the contact's country code. 682 - An OPTIONAL element that contains the contact's 683 voice telephone number. 685 - An OPTIONAL element that contains the contact's 686 facsimile telephone number. 688 - A element that contains the contact's email address. 690 - A element that contains authorization information 691 to be associated with the contact object. 693 Example command: 695 C: 696 C: 700 C: 701 C: 702 C: 706 C: sh8013 707 C: 708 C: John Doe 709 C: Example Inc. 710 C: 711 C: 123 Example Dr. 712 C: Suite 100 713 C: Dulles 714 C: VA 715 C: 20166-6503 716 C: US 717 C: 718 C: 719 C: +1.7035555555 720 C: +1.7035555556 721 C: jdoe@example.tld 722 C: 2fooBAR 723 C: 724 C: 725 C: ABC-12345 726 C: 727 C: 729 When a command has been processed successfully, the EPP 730 element MUST contain a child element that 731 identifies the contact namespace and the location of the contact 732 schema. The element contains the following child 733 elements: 735 - A element that contains the server-unique identifier 736 for the created contact. 738 - A element that contains the date and time of 739 contact object creation. 741 Example response: 743 S: 744 S: 748 S: 749 S: 750 S: Command completed successfully 751 S: 752 S: 753 S: 757 S: sh8013 758 S: 1999-04-03T22:00:00.0Z 759 S: 760 S: 761 S: 762 S: ABC-12345 763 S: 54321-XYZ 764 S: 765 S: 766 S: 768 An EPP error response MUST be returned if a command can not 769 be processed for any reason. 771 3.2.2 EPP Command 773 The EPP command provides a transform operation that allows a 774 client to delete a contact object. In addition to the standard EPP 775 command elements, the command MUST contain a 776 element that identifies the contact namespace and the location of the 777 contact schema. The element MUST contain the 778 following child elements: 780 - A element that contains the server-unique identifier of 781 the contact object to be deleted. 783 A contact object SHOULD NOT be deleted if it is associated with other 784 known objects. An associated contact SHOULD NOT be deleted until 785 associations with other known objects have been broken. A server 786 SHOULD notify clients of object relationships when a command 787 is attempted and fails due to existing object relationships. 789 Example command: 791 C: 792 C: 796 C: 797 C: 798 C: 802 C: sh8013 803 C: 804 C: 805 C: ABC-12345 806 C: 807 C: 809 When a command has been processed successfully, a server MUST 810 respond with an EPP response with no element. 812 Example response: 814 S: 815 S: 819 S: 820 S: 821 S: Command completed successfully 822 S: 823 S: 824 S: ABC-12345 825 S: 54321-XYZ 826 S: 827 S: 828 S: 830 An EPP error response MUST be returned if a command can not 831 be processed for any reason. 833 3.2.3 EPP Command 835 Renewal semantics do not apply to contact objects, so there is no 836 mapping defined for the EPP command. 838 3.2.4 EPP Command 840 The EPP command provides a transform operation that allows 841 a client to manage requests to transfer the sponsorship of a contact 842 object. In addition to the standard EPP command elements, the 843 command MUST contain a element that 844 identifies the contact namespace and the location of the contact 845 schema. The element contains the following child 846 elements: 848 - A element that contains the server-unique identifier of 849 the contact object for which a transfer request is to be created, 850 approved, rejected, or cancelled. 852 - A element that contains authorization information 853 associated with the contact object. 855 Every EPP command MUST contain an "op" attribute that 856 identifies the transfer operation to be performed as defined in [EPP]. 858 Example request command: 860 C: 861 C: 865 C: 866 C: 867 C: 871 C: sh8013 872 C: 2fooBAR 873 C: 874 C: 875 C: ABC-12345 876 C: 877 C: 879 When a command has been processed successfully, the EPP 880 element MUST contain a child element that 881 identifies the contact namespace and the location of the contact 882 schema. The element contains the same child 883 elements defined for a transfer query response. 885 Example response: 887 S: 888 S: 892 S: 893 S: 894 S: Command completed successfully 895 S: 896 S: 897 S: 901 S: sh8013 902 S: pending 903 S: ClientX 904 S: 2000-06-08T22:00:00.0Z 905 S: ClientY 906 S: 2000-06-13T22:00:00.0Z 907 S: 908 S: 909 S: 910 S: ABC-12345 911 S: 54322-XYZ 912 S: 913 S: 914 S: 916 An EPP error response MUST be returned if a command can not 917 be processed for any reason. 919 3.2.5 EPP Command 921 The EPP command provides a transform operation that allows a 922 client to modify the attributes of a contact object. In addition to 923 the standard EPP command elements, the command MUST contain a 924 element that identifies the contact namespace and the 925 location of the contact schema. The element contains 926 the following child elements: 928 - A element that contains the server-unique identifier of 929 the contact object to be updated. 931 - An OPTIONAL element that contains attribute values to 932 be added to the object. 934 - An OPTIONAL element that contains attribute values to 935 be removed from the object. 937 - An OPTIONAL element that contains object attribute 938 values to be changed. 940 At least one , , or element 941 MUST be provided. The and elements 942 contain the following child elements: 944 - One or more elements that contain status values to 945 be associated with or removed from the object. When specifying a 946 value to be removed, only the attribute value is significant; element 947 text is not required to match a value for removal. 949 A element contains the following OPTIONAL child 950 elements. At least one child element MUST be present: 952 - One or two elements that contain postal address 953 information. Two elements are provided so that address information 954 can be provided in both internationalized and localized forms. If an 955 internationalized form is provided, it MUST be listed first and 956 element content MUST be represented in a subset of UTF-8 that can be 957 represented in the 7-bit US-ASCII character set. If a localized form 958 is provided, element content MAY be represented in unrestricted UTF-8. 959 The element contains the following child 960 elements: 962 - A element that contains the name of the individual 963 or role represented by the contact. 965 - A element that contains the name of the organization 966 with which the contact is affiliated. 968 - A element that contains address information 969 associated with the contact. A element contains the 970 following child elements: 972 - One, two, or three OPTIONAL elements that 973 contain the contact's street address. 975 - A element that contains the contact's city. 977 - An OPTIONAL element that contains the contact's 978 state or province. 980 - An OPTIONAL element that contains the contact's 981 postal code. 983 - A element that contains the contact's country code. 985 - A element that contains the contact's voice 986 telephone number. 988 - A element that contains the contact's facsimile 989 telephone number. 991 - A element that contains the contact's email address. 993 - A element that contains authorization information 994 associated with the contact object. 996 Example command: 998 C: 999 C: 1003 C: 1004 C: 1005 C: 1009 C: sh8013 1010 C: 1011 C: 1012 C: 1013 C: 1014 C: 1015 C: 1016 C: 1017 C: 124 Example Dr. 1018 C: Suite 200 1019 C: Dulles 1020 C: VA 1021 C: 20166-6503 1022 C: US 1023 C: 1024 C: 1025 C: +1.7034444444 1026 C: 1027 C: 2BARfoo 1028 C: 1029 C: 1030 C: 1031 C: ABC-12345 1032 C: 1033 C: 1035 When an command has been processed successfully, a server 1036 MUST respond with an EPP response with no element. 1038 Example response: 1040 S: 1041 S: 1045 S: 1046 S: 1047 S: Command completed successfully 1048 S: 1049 S: 1050 S: ABC-12345 1051 S: 54321-XYZ 1052 S: 1053 S: 1054 S: 1056 An EPP error response MUST be returned if an command can not 1057 be processed for any reason. 1059 4. Formal Syntax 1061 An EPP object mapping is specified in XML Schema notation. The formal 1062 syntax presented here is a complete schema representation of the 1063 object mapping suitable for automated validation of EPP XML instances. 1064 The BEGIN and END tags are not part of the schema; they are used to 1065 note the beginning and ending of the schema for URI registration 1066 purposes. 1068 BEGIN 1069 1071 1078 1081 1083 1086 1087 1088 Extensible Provisioning Protocol v1.0 1089 contact provisioning schema. 1090 1091 1093 1096 1097 1098 1099 1100 1101 1103 1106 1107 1108 1109 1110 1112 1113 1114 1115 1116 1117 1118 1120 1121 1122 1123 1124 1125 1127 1128 1129 1130 1131 1133 1134 1135 1136 1137 1138 1140 1141 1142 1143 1144 1146 1149 1150 1151 1152 1154 1156 1158 1159 1160 1161 1163 1164 1165 1166 1168 1169 1170 1172 1173 1174 1176 1177 1179 1181 1182 1183 1185 1188 1189 1190 1191 1192 1194 1197 1198 1199 1201 1202 1204 1207 1208 1209 1210 1211 1212 1214 1217 1218 1219 1220 1222 1224 1226 1227 1229 1232 1233 1234 1236 1237 1239 1242 1243 1244 1246 1248 1250 1253 1255 1256 1258 1259 1260 1262 1264 1266 1267 1269 1272 1273 1274 1275 1277 1280 1281 1282 1284 1285 1287 1288 1289 1290 1292 1293 1295 1296 1297 1298 1300 1302 1303 1305 1308 1309 1310 1311 1312 1313 1315 1318 1319 1320 1321 1322 1324 1326 1328 1330 1331 1332 1333 1334 1336 1338 1340 1342 1343 1345 1349 1350 1351 1352 1354 1356 1357 1358 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1375 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1389 1392 1393 END 1395 5. Internationalization Considerations 1397 EPP is represented in XML, which provides native support for encoding 1398 information using the Unicode character set and its more compact 1399 representations including UTF-8. Compliant XML processors are 1400 REQUIRED to understand both UTF-8 and UTF-16. Though XML includes 1401 provisions to identify other character set encodings through use of an 1402 "encoding" attribute in an declaration, EPP use with character 1403 sets other than UTF-8 is NOT RECOMMENDED. 1405 All date-time values presented via EPP MUST be expressed in Universal 1406 Coordinated Time using the Gregorian calendar. XML Schema allows use 1407 of time zone identifiers to indicate offsets from the zero meridian, 1408 but this option MUST NOT be used with EPP. The extended date-time 1409 form defined in [DATE-TIME] MUST be used to represent date-time values 1410 as XML Schema does not support truncated date-time forms. 1412 Humans, organizations, and other entities often need to represent 1413 social information in both a commonly understood character set and a 1414 locally optimized character set. This specification provides features 1415 allowing representation of social information in both a subset of 1416 UTF-8 for broad readability and unrestricted UTF-8 for local 1417 optimization. 1419 6. IANA Considerations 1421 This document uses URNs to describe XML namespaces and XML schemas 1422 conforming to a registry mechanism described in [IETF-XML]. Two URI 1423 assignments are requested. 1425 Registration request for the contact namespace: 1427 URI: urn:ietf:params:xml:ns:contact-1.0 1429 Registrant Contact: See the "Author's Address" section of this 1430 document. 1432 XML: None. Namespace URIs do not represent an XML specification. 1434 Registration request for the contact XML schema: 1436 URI: urn:ietf:params:xml:schema:contact-1.0 1438 Registrant Contact: See the "Author's Address" section of this 1439 document. 1441 XML: See the "Formal Syntax" section of this document. 1443 7. Security Considerations 1445 An authorization token is REQUIRED to create a contact object. This 1446 token is used in transfer operations as an additional means of 1447 determining client authorization to perform the command. Failure to 1448 protect authorization tokens can result in unauthorized transfer 1449 operations. Both client and server MUST ensure that tokens are stored 1450 and exchanged with high-grade encryption mechanisms to provide privacy 1451 services. 1453 The object mapping described in this document does not provide any 1454 other security services or introduce any additional considerations 1455 beyond those described by [EPP] and protocol layers used by EPP. 1457 8. Acknowledgements 1459 This document was originally written as an individual submission 1460 Internet-Draft. The provreg working group later adopted it as a 1461 working group document and provided many invaluable comments and 1462 suggested improvements. The author wishes to acknowledge the efforts 1463 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1464 editorial contributions. 1466 Specific suggestions that have been incorporated into this document 1467 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1468 Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer El-Showk, Dipankar 1469 Ghosh, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, 1470 Asbjorn Steira, and Rick Wesson. 1472 9. References 1474 Normative References: 1476 [DATE-TIME] G. Klyne, C. Newman: "Date and Time on the Internet: 1477 Timestamps", work in progress. 1479 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 1480 progress. 1482 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 1484 [ISO3166] ISO 3166-1: "Codes for the representation of names of 1485 countries and their subdivisions - Part 1: Country codes", October 1486 1997. 1488 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 1489 Requirement Levels", BCP 14, RFC 2119, March 1997. 1491 [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646", 1492 RFC 2279, January 1998. 1494 [RFC2822] P. Resnick: "Internet Message Format", RFC 2822, April 2001. 1496 Informative References: 1498 [E164a] ITU-T Recommendation E.164: "The International Public 1499 Telecommunication Numbering Plan", May 1997. 1501 [E164b] Complement To ITU-T Recommendation E.164 (05/1997): "List of 1502 ITU-T Recommendation E.164 assigned country codes", June 2000. 1504 [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 1505 (Second Edition)", W3C Recommendation 6 October 2000. 1507 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 1508 W3C Recommendation 2 May 2001. 1510 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 1511 Datatypes", W3C Recommendation 2 May 2001. 1513 10. Author's Address 1515 Scott Hollenbeck 1516 VeriSign Global Registry Services 1517 21345 Ridgetop Circle 1518 Dulles, VA 20166-6503 1519 USA 1520 shollenbeck@verisign.com 1522 A. Revisions From Previous Version 1524 (Note to RFC editor: please remove this section completely before 1525 publication as an RFC.) 1527 -03 to -04 (WG last call updates): 1529 Fixed typos. 1531 Fixed the e164StringType to allow full-length numbers with country 1532 codes of less than three characters. 1534 Increased the maximum postalLineType length from 64 to 255. 1536 Changed type of email and telephone number types to "token" from 1537 "normalizedString" since these values should never contain certain 1538 acceptable normalizedString characters. 1540 Fixed schema to prevent multiple choices in updates, replacing 1541 with . 1543 Made mandatory for transfer queries. 1545 Added a sentence to section 3.2.2 to encourage server implementers to 1546 notify clients when a delete command fails due to existing object 1547 relationships. 1549 Modified the schema to collapse the and elements into a 1550 single element that may occur once or twice depending on 1551 context. 1553 Modified the schema to ensure that required string fields can't be 1554 specified as empty strings. 1556 Changed some lower-case "must"s, "may"s, etc. to avoid confusion with 1557 RFC 2119 directives. 1559 Updated the security considerations section to note the need to 1560 protect authorization tokens. 1562 Separated references into normative and informative subsections. 1564 Removed unneeded references to ISO 11180 and US-ASCII. 1566 Replaced reference to ISO 8601 with an IMPP I-D that will hopefully be 1567 an RFC soon. 1569 B. Full Copyright Statement 1571 Copyright (C) The Internet Society 2002. All Rights Reserved. 1573 This document and translations of it may be copied and furnished to 1574 others, and derivative works that comment on or otherwise explain it 1575 or assist in its implementation may be prepared, copied, published and 1576 distributed, in whole or in part, without restriction of any kind, 1577 provided that the above copyright notice and this paragraph are 1578 included on all such copies and derivative works. However, this 1579 document itself may not be modified in any way, such as by removing 1580 the copyright notice or references to the Internet Society or other 1581 Internet organizations, except as needed for the purpose of developing 1582 Internet standards in which case the procedures for copyrights defined 1583 in the Internet Standards process must be followed, or as required to 1584 translate it into languages other than English. 1586 The limited permissions granted above are perpetual and will not be 1587 revoked by the Internet Society or its successors or assigns. 1589 This document and the information contained herein is provided on an 1590 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1591 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1592 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1593 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1594 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1596 Acknowledgement 1598 Funding for the RFC Editor function is currently provided by the 1599 Internet Society.