idnits 2.17.1 draft-ietf-provreg-epp-contact-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. 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' -- 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. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-2' ** Downref: Normative reference to an Informational RFC: RFC 2781 -- Possible downref: Non-RFC (?) normative reference: ref. 'E164a' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164b' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 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 ......................... 6 55 2.4 Address ..................................................... 6 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 ............................................. 7 61 2.7 Dates and Times ............................................. 7 62 2.8 Authorization Information ................................... 7 63 2.9 Disclosure of Data Elements and Attributes .................. 7 64 3. EPP Command mapping .......................................... 9 65 3.1 EPP Query Commands .......................................... 9 66 3.1.1 EPP Command ....................................... 9 67 3.1.2 EPP Command ........................................ 11 68 3.1.3 EPP Query Command .............................. 15 69 3.2 EPP Transform Commands ...................................... 17 70 3.2.1 EPP Command ...................................... 18 71 3.2.2 EPP Command ...................................... 21 72 3.2.3 EPP Command ....................................... 23 73 3.2.4 EPP Command .................................... 23 74 3.2.5 EPP Command ...................................... 25 75 3.2.6 Offline Review of Requested Actions ....................... 29 76 4. Formal Syntax ................................................ 32 77 5. Internationalization Considerations .......................... 41 78 6. IANA Considerations .......................................... 41 79 7. Security Considerations ...................................... 42 80 8. Acknowledgements ............................................. 42 81 9. References ................................................... 43 82 10. Author's Address ............................................ 44 83 A. Revisions From Previous Version .............................. 45 84 B. Full Copyright Statement ..................................... 46 86 1. Introduction 88 This document describes a personal and organizational identifier 89 mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). 90 This mapping is specified using the Extensible Markup Language (XML) 91 1.0 as described in [XML] and XML Schema notation as described in 92 [XMLS-1] and [XMLS-2]. 94 [EPP] provides a complete description of EPP command and response 95 structures. A thorough understanding of the base protocol 96 specification is necessary to understand the mapping described in this 97 document. 99 XML is case sensitive. Unless stated otherwise, XML specifications 100 and examples provided in this document MUST be interpreted in the 101 character case presented to develop a conforming implementation. 103 2. Object Attributes 105 An EPP contact object has attributes and associated values that can be 106 viewed and modified by the sponsoring client or the server. This 107 section describes each attribute type in detail. The formal syntax 108 for the attribute values described here can be found in the "Formal 109 Syntax" section of this document and in the appropriate normative 110 references. 112 2.1 Contact and Client Identifiers 114 All EPP contacts are identified by a server-unique identifier. 115 Contact identifiers are character strings with a specified minimum 116 length, a specified maximum length, and a specified format. Contact 117 identifiers use the "clIDType" client identifier syntax described in 118 [EPP]. 120 2.2 Status Values 122 A contact object MUST always have at least one associated status 123 value. Status values can be set only by the client that sponsors a 124 contact object and by the server on which the object resides. A 125 client can change the status of a contact object using the EPP 126 command. Each status value MAY be accompanied by a string of 127 human-readable text that describes the rationale for the status 128 applied to the object. 130 A client MUST NOT alter status values set by the server. A server MAY 131 alter or override status values set by a client subject to local 132 server policies. The status of an object MAY change as a result of 133 either a client-initiated transform command or an action performed by 134 a server operator. 136 Status values that can be added or removed by a client are prefixed 137 with "client". Corresponding status values that can be added or 138 removed by a server are prefixed with "server". Status values that do 139 not begin with either "client" or "server" are server-managed. 141 Status Value Descriptions: 143 - clientDeleteProhibited, serverDeleteProhibited 145 Requests to delete the object MUST be rejected. 147 - clientTransferProhibited, serverTransferProhibited 149 Requests to transfer the object MUST be rejected. 151 - 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 normal status value for an object that has no pending 165 operations or prohibitions. This value is set and removed by the 166 server as other status values are added or removed. 168 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 170 A transform command has been processed for the object, but the action 171 has not been completed by the server. Server operators can delay 172 action completion for a variety of reasons, such as to allow for human 173 review or third-party action. A transform command that is processed, 174 but whose requested action is pending, is noted with response code 175 1001. 177 With one exception, transform commands MUST be rejected when a 178 pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status 179 is set. The only exception is that a command to approve, 180 reject, or cancel a transfer MAY be processed while an object is in 181 "pendingTransfer" status. 183 When the requested action has been completed, the pendingCreate, 184 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 185 removed. All clients involved in the transaction MUST be notified 186 using a service message that the action has been completed and that 187 the status of the object has changed. 189 "ok" status MAY only be combined with "linked" status. 191 "linked" status MAY be combined with any status. 193 "pendingDelete" status MUST NOT be combined with either 194 "clientDeleteProhibited" or "serverDeleteProhibited" status. 196 "pendingTransfer" status MUST NOT be combined with either 197 "clientTransferProhibited" or "serverTransferProhibited" status. 199 "pendingUpdate" status MUST NOT be combined with either 200 "clientUpdateProhibited" or "serverUpdateProhibited" status. 202 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 203 status values MUST NOT be combined with each other. 205 Other status combinations not expressly prohibited MAY be used. 207 2.3 Individual and Organizational Names 209 Individual and organizational names associated with a contact are 210 represented using character strings. These strings have a specified 211 minimum length and a specified maximum length. Individual and 212 organizational names MAY be provided in both UTF-8 [RFC2279] and a 213 subset of UTF-8 that can be represented in 7-bit ASCII depending on 214 local needs. 216 2.4 Address 218 Every contact has associated postal address information. A postal 219 address contains OPTIONAL street information, city information, 220 OPTIONAL state/province information, an OPTIONAL postal code, and a 221 country identifier. Address information MAY be provided in both UTF-8 222 and a subset of UTF-8 that can be represented in 7-bit ASCII depending 223 on local needs. 225 2.4.1 Street, City, and State or Province 227 Contact street, city, and state or province information is represented 228 using character strings. These strings have a specified minimum 229 length and a specified maximum length. 231 2.4.2 Postal Code 233 Contact postal codes are represented using character strings. These 234 strings have a specified minimum length and a specified maximum 235 length. 237 2.4.3 Country 239 Contact country identifiers are represented using two-character 240 identifiers specified in [ISO3166]. 242 2.5 Telephone Numbers 244 Contact telephone number structure is derived from structures defined 245 in [E164a]. Telephone numbers described in this mapping are character 246 strings that MUST begin with a plus sign ("+", ASCII value 0x002B), 247 followed by a country code defined in [E164b], followed by a dot (".", 248 ASCII value 0x002E), followed by a sequence of digits representing the 249 telephone number. An optional "x" attribute is provided to note 250 telephone extension information. 252 2.6 Email Addresses 254 Email address syntax is defined in [RFC2822]. This mapping does not 255 prescribe minimum or maximum lengths for character strings used to 256 represent email addresses. 258 2.7 Dates and Times 260 Date and time attribute values MUST be represented in Universal 261 Coordinated Time (UTC) using the Gregorian calendar. The extended 262 date-time form using upper case "T" and "Z" characters defined in 263 [RFC3339] MUST be used to represent date-time values as XML Schema 264 does not support truncated date-time forms or lower case "T" and "Z" 265 characters. 267 2.8 Authorization Information 269 Authorization information is associated with contact objects to 270 facilitate transfer operations. Authorization information is assigned 271 when a contact object is created, and it might be updated in the 272 future. This specification describes password-based authorization 273 information, though other mechanisms are possible. 275 2.9 Disclosure of Data Elements and Attributes 277 The EPP core protocol requires a server operator to announce data 278 collection policies to clients; see section 2.4 of [EPP]. In 279 conjunction with this disclosure requirement, this mapping includes 280 data elements that allow a client to identify elements that require 281 exceptional server operator handling to allow or restrict disclosure 282 to third parties. 284 A server operator announces a default disclosure policy when 285 establishing a session with a client. When an object is created or 286 updated, the client can specify contact attributes that require 287 exceptional disclosure handling using an OPTIONAL 288 element. Once set, disclosure preferences can be reviewed using a 289 contact information query. A server operator MUST reject any 290 transaction that requests disclosure practices that do not conform to 291 the announced data collection policy with a 2308 error response code. 293 If present, the element MUST contain a "flag" 294 attribute. The "flag" attribute contains an XML Schema boolean value. 296 A value of "true" or "1" (decimal one) notes a client preference to 297 allow disclosure of the specified elements as an exception to the 298 stated data collection policy. A value of "false" or "0" (decimal 299 zero) notes a client preference to not allow disclosure of the 300 specified elements as an exception to the stated data collection 301 policy. 303 The element MUST contain at least one of the 304 following child elements: 306 308 309 311 Example element, flag="0": 313 314 315 316 318 In this example, the contact email address and voice telephone number 319 can not be disclosed. All other elements are subject to disclosure in 320 accordance with the server's data collection policy. 322 Example element, flag="1": 324 325 326 327 328 330 In this example, the internationalized contact name, organization, and 331 address information can be disclosed. All other elements are subject 332 to disclosure in accordance with the server's data collection policy. 334 Client identification features provided by the EPP command and 335 contact authorization information are used to determine if a client is 336 authorized to perform contact information query commands. These 337 features also determine if a client is authorized to receive data that 338 is otherwise marked for non-disclosure in a query response. 340 3. EPP Command mapping 342 A detailed description of the EPP syntax and semantics can be found in 343 [EPP]. The command mappings described here are specifically for use 344 in provisioning and managing contact objects via EPP. 346 3.1 EPP Query Commands 348 EPP provides three commands to retrieve contact information: 349 to determine if a contact object can be provisioned within a 350 repository, to retrieve detailed information associated with a 351 contact object, and to retrieve contact object transfer 352 status information. 354 3.1.1 EPP Command 356 The EPP command is used to determine if an object can be 357 provisioned within a repository. It provides a hint that allows a 358 client to anticipate the success or failure of provisioning an object 359 using the command as object provisioning requirements are 360 ultimately a matter of server policy. 362 In addition to the standard EPP command elements, the command 363 MUST contain a element that identifies the contact 364 namespace and the location of the contact schema. The 365 element contains the following child elements: 367 - One or more elements that contain the server-unique 368 identifier of the contact objects to be queried. 370 Example command: 372 C: 373 C: 377 C: 378 C: 379 C: 383 C: sh8013 384 C: sah8013 385 C: 8013sah 386 C: 387 C: 388 C: ABC-12345 389 C: 390 C: 392 When a command has been processed successfully, the EPP 393 element MUST contain a child element that 394 identifies the contact namespace and the location of the contact 395 schema. The element contains one or more 396 elements that contain the following child elements: 398 - A element that identifies the queried object. This 399 element MUST contain an "avail" attribute whose value indicates object 400 availability (can it be provisioned or not) at the moment the 401 command was completed. A value of "1" or "true" means that the object 402 can be provisioned. A value of "0" or "false" means that the object 403 can not be provisioned. 405 - An OPTIONAL element that MAY be provided when an 406 object can not be provisioned. If present, this element contains 407 server-specific text to help explain why the object can not be 408 provisioned. This text MUST be represented in the response language 409 previously negotiated with the client; an OPTIONAL "lang" attribute 410 MAY be present to identify the language if the negotiated value is 411 something other than the default value of "en" (English). 413 Example response: 415 S: 416 S: 420 S: 421 S: 422 S: Command completed successfully 423 S: 424 S: 425 S: 429 S: 430 S: sh8013 431 S: 432 S: 433 S: sah8013 434 S: In use 435 S: 436 S: 437 S: 8013sah 438 S: 439 S: 440 S: 441 S: 442 S: ABC-12345 443 S: 54322-XYZ 444 S: 445 S: 446 S: 448 An EPP error response MUST be returned if a command can not be 449 processed for any reason. 451 3.1.2 EPP Command 453 The EPP command is used to retrieve information associated with 454 a contact object. In addition to the standard EPP command elements, 455 the command MUST contain a element that 456 identifies the contact namespace and the location of the contact 457 schema. The element contains the following child 458 elements: 460 - A element that contains the server-unique identifier of 461 the contact object to be queried. 463 - An OPTIONAL element that contains authorization 464 information associated with the contact object. If this element is 465 not provided or if the authorization information is invalid, server 466 policy determines if the command is rejected or if response 467 information will be returned to the client. 469 Example command: 471 C: 472 C: 476 C: 477 C: 478 C: 482 C: sh8013 483 C: 484 C: 2fooBAR 485 C: 486 C: 487 C: 488 C: ABC-12345 489 C: 490 C: 492 When an command has been processed successfully, the EPP 493 element MUST contain a child element that 494 identifies the contact namespace and the location of the contact 495 schema. The element contains the following child 496 elements: 498 - A element that contains the server-unique identifier of 499 the contact object. 501 - A element that contains the Repository Object 502 IDentifier assigned to the contact object when the object was created. 504 - One or more elements that describe the status of 505 the contact object. 507 - One or two elements that contain postal address 508 information. Two elements are provided so that address information 509 can be provided in both internationalized and localized forms; a 510 "type" attribute is used to identify the two forms. If an 511 internationalized form (type="int") is provided, element content MUST 512 be represented in a subset of UTF-8 that can be represented in the 7- 513 bit US-ASCII character set. If a localized form (type="loc") is 514 provided, element content MAY be represented in unrestricted UTF-8. 515 The element contains the following child 516 elements: 518 - A element that contains the name of the individual 519 or role represented by the contact. 521 - An OPTIONAL element that contains the name of the 522 organization with which the contact is affiliated. 524 - A element that contains address information 525 associated with the contact. A element contains the 526 following child elements: 528 - One, two, or three OPTIONAL elements that 529 contain the contact's street address. 531 - A element that contains the contact's city. 533 - An OPTIONAL element that contains the contact's 534 state or province. 536 - An OPTIONAL element that contains the contact's 537 postal code. 539 - A element that contains the contact's country code. 541 - An OPTIONAL element that contains the contact's 542 voice telephone number. 544 - An OPTIONAL element that contains the contact's 545 facsimile telephone number. 547 - A element that contains the contact's email address. 549 - A element that contains the identifier of the 550 sponsoring client. 552 - A element that contains the identifier of the client 553 that created the contact object. 555 - A element that contains the date and time of 556 contact object creation. 558 - A element that contains the identifier of the client 559 that last updated the contact object. This element MUST NOT be 560 present if the contact has never been modified. 562 - A element that contains the date and time of the 563 most recent contact object modification. This element MUST NOT be 564 present if the contact object has never been modified. 566 - A elements that contains the date and time of the 567 most recent successful contact object transfer. This element MUST NOT 568 be provided if the contact object has never been transferred. 570 - A element that contains authorization information 571 associated with the contact object. This element MUST NOT be provided 572 if the querying client is not the current sponsoring client. 574 - An OPTIONAL element that identifies elements that 575 require exceptional server operator handling to allow or restrict 576 disclosure to third parties. See section 2.9 for a description of the 577 child elements contained within the element. 579 Example response for an authorized client: 581 S: 582 S: 586 S: 587 S: 588 S: Command completed successfully 589 S: 590 S: 591 S: 595 S: sh8013 596 S: SH8013-REP 597 S: 598 S: 599 S: 600 S: John Doe 601 S: Example Inc. 602 S: 603 S: 123 Example Dr. 604 S: Suite 100 605 S: Dulles 606 S: VA 607 S: 20166-6503 608 S: US 609 S: 610 S: 611 S: +1.7035555555 612 S: +1.7035555556 613 S: jdoe@example.com 614 S: ClientY 615 S: ClientX 616 S: 1999-04-03T22:00:00.0Z 617 S: ClientX 618 S: 1999-12-03T09:00:00.0Z 619 S: 2000-04-08T09:00:00.0Z 620 S: 621 S: 2fooBAR 622 S: 623 S: 624 S: 625 S: 626 S: 627 S: 628 S: 629 S: 630 S: ABC-12345 631 S: 54322-XYZ 632 S: 633 S: 634 S: 636 An EPP error response MUST be returned if an command can not be 637 processed for any reason. 639 3.1.3 EPP Query Command 641 The EPP command provides a query operation that allows a 642 client to determine real-time status of pending and completed transfer 643 requests. In addition to the standard EPP command elements, the 644 command MUST contain an "op" attribute with value "query", 645 and a element that identifies the contact namespace 646 and the location of the contact schema. The 647 element MUST contain the following child elements: 649 - A element that contains the server-unique identifier of 650 the contact object to be queried. 652 - An OPTIONAL element that contains authorization 653 information associated with the contact object. If this element is 654 not provided or if the authorization information is invalid, server 655 policy determines if the command is rejected or if response 656 information will be returned to the client. 658 Example query command: 660 C: 661 C: 665 C: 666 C: 667 C: 671 C: sh8013 672 C: 673 C: 2fooBAR 674 C: 675 C: 676 C: 677 C: ABC-12345 678 C: 679 C: 681 When a query command has been processed successfully, the 682 EPP element MUST contain a child element 683 that identifies the contact namespace and the location of the contact 684 schema. The element contains the following child 685 elements: 687 - A element that contains the server-unique identifier 688 for the queried contact. 690 - A element that contains the state of the most 691 recent transfer request. 693 - A element that contains the identifier of the client 694 that requested the object transfer. 696 - A element that contains the date and time that the 697 transfer was requested. 699 - A element that contains the identifier of the client 700 that SHOULD act upon the transfer request. 702 - A element that contains the date and time of a 703 required or completed response. For a pending request, the value 704 identifies the date and time by which a response is required before an 705 automated response action SHOULD be taken by the server. For all 706 other status types, the value identifies the date and time when the 707 request was completed. 709 Example query response: 711 S: 712 S: 716 S: 717 S: 718 S: Command completed successfully 719 S: 720 S: 721 S: 725 S: sh8013 726 S: pending 727 S: ClientX 728 S: 2000-06-06T22:00:00.0Z 729 S: ClientY 730 S: 2000-06-11T22:00:00.0Z 731 S: 732 S: 733 S: 734 S: ABC-12345 735 S: 54322-XYZ 736 S: 737 S: 738 S: 740 An EPP error response MUST be returned if a query command 741 can not be processed for any reason. 743 3.2 EPP Transform Commands 745 EPP provides four commands to transform contact object information: 746 to create an instance of a contact object, to delete 747 an instance of a contact object, to manage contact object 748 sponsorship changes, and to change information associated 749 with a contact object. This document does not define a mapping for 750 the EPP command. 752 Transform commands are typically processed and completed in real time. 753 Server operators MAY receive and process transform commands, but defer 754 completing the requested action if human or third-party review is 755 required before the requested action can be completed. In such 756 situations the server MUST return a 1001 response code to the client 757 to note that the command has been received and processed, but the 758 requested action is pending. The server MUST also manage the status 759 of the object that is the subject of the command to reflect the 760 initiation and completion of the requested action. Once the action 761 has been completed, all clients involved in the transaction MUST be 762 notified using a service message that the action has been completed 763 and that the status of the object has changed. 765 3.2.1 EPP Command 767 The EPP command provides a transform operation that allows a 768 client to create a contact object. In addition to the standard EPP 769 command elements, the command MUST contain a 770 element that identifies the contact namespace and the location of the 771 contact schema. The element contains the following 772 child elements: 774 - A element that contains the desired server-unique 775 identifier for the contact to be created. 777 - One or two elements that contain postal address 778 information. Two elements are provided so that address information 779 can be provided in both internationalized and localized forms; a 780 "type" attribute is used to identify the two forms. If an 781 internationalized form (type="int") is provided, element content MUST 782 be represented in a subset of UTF-8 that can be represented in the 7- 783 bit US-ASCII character set. If a localized form (type="loc") is 784 provided, element content MAY be represented in unrestricted UTF-8. 785 The element contains the following child 786 elements: 788 - A element that contains the name of the individual 789 or role represented by the contact. 791 - An OPTIONAL element that contains the name of the 792 organization with which the contact is affiliated. 794 - A element that contains address information 795 associated with the contact. A element contains the 796 following child elements: 798 - One, two, or three OPTIONAL elements that 799 contain the contact's street address. 801 - A element that contains the contact's city. 803 - An OPTIONAL element that contains the contact's 804 state or province. 806 - An OPTIONAL element that contains the contact's 807 postal code. 809 - A element that contains the contact's country code. 811 - An OPTIONAL element that contains the contact's 812 voice telephone number. 814 - An OPTIONAL element that contains the contact's 815 facsimile telephone number. 817 - A element that contains the contact's email address. 819 - A element that contains authorization information 820 to be associated with the contact object. This mapping includes a 821 password-based authentication mechanism, but the schema allows new 822 mechanisms to be defined in new schemas. 824 - An OPTIONAL element that allows a client to 825 identify elements that require exceptional server operator handling to 826 allow or restrict disclosure to third parties. See section 2.9 for a 827 description of the child elements contained within the 828 element. 830 Example command: 832 C: 833 C: 837 C: 838 C: 839 C: 843 C: sh8013 844 C: 845 C: John Doe 846 C: Example Inc. 847 C: 848 C: 123 Example Dr. 849 C: Suite 100 850 C: Dulles 851 C: VA 852 C: 20166-6503 853 C: US 854 C: 855 C: 856 C: +1.7035555555 857 C: +1.7035555556 858 C: jdoe@example.com 859 C: 860 C: 2fooBAR 861 C: 862 C: 863 C: 864 C: 865 C: 866 C: 867 C: 868 C: ABC-12345 869 C: 870 C: 872 When a command has been processed successfully, the EPP 873 element MUST contain a child element that 874 identifies the contact namespace and the location of the contact 875 schema. The element contains the following child 876 elements: 878 - A element that contains the server-unique identifier 879 for the created contact. 881 - A element that contains the date and time of 882 contact object creation. 884 Example response: 886 S: 887 S: 891 S: 892 S: 893 S: Command completed successfully 894 S: 895 S: 896 S: 900 S: sh8013 901 S: 1999-04-03T22:00:00.0Z 902 S: 903 S: 904 S: 905 S: ABC-12345 906 S: 54321-XYZ 907 S: 908 S: 909 S: 911 An EPP error response MUST be returned if a command can not 912 be processed for any reason. 914 3.2.2 EPP Command 916 The EPP command provides a transform operation that allows a 917 client to delete a contact object. In addition to the standard EPP 918 command elements, the command MUST contain a 919 element that identifies the contact namespace and the location of the 920 contact schema. The element MUST contain the 921 following child elements: 923 - A element that contains the server-unique identifier of 924 the contact object to be deleted. 926 A contact object SHOULD NOT be deleted if it is associated with other 927 known objects. An associated contact SHOULD NOT be deleted until 928 associations with other known objects have been broken. A server 929 SHOULD notify clients of object relationships when a command 930 is attempted and fails due to existing object relationships. 932 Example command: 934 C: 935 C: 939 C: 940 C: 941 C: 945 C: sh8013 946 C: 947 C: 948 C: ABC-12345 949 C: 950 C: 952 When a command has been processed successfully, a server MUST 953 respond with an EPP response with no element. 955 Example response: 957 S: 958 S: 962 S: 963 S: 964 S: Command completed successfully 965 S: 966 S: 967 S: ABC-12345 968 S: 54321-XYZ 969 S: 970 S: 971 S: 973 An EPP error response MUST be returned if a command can not 974 be processed for any reason. 976 3.2.3 EPP Command 978 Renewal semantics do not apply to contact objects, so there is no 979 mapping defined for the EPP command. 981 3.2.4 EPP Command 983 The EPP command provides a transform operation that allows 984 a client to manage requests to transfer the sponsorship of a contact 985 object. In addition to the standard EPP command elements, the 986 command MUST contain a element that 987 identifies the contact namespace and the location of the contact 988 schema. The element contains the following child 989 elements: 991 - A element that contains the server-unique identifier of 992 the contact object for which a transfer request is to be created, 993 approved, rejected, or cancelled. 995 - A element that contains authorization information 996 associated with the contact object. 998 Every EPP command MUST contain an "op" attribute that 999 identifies the transfer operation to be performed as defined in [EPP]. 1001 Example request command: 1003 C: 1004 C: 1008 C: 1009 C: 1010 C: 1014 C: sh8013 1015 C: 1016 C: 2fooBAR 1017 C: 1018 C: 1019 C: 1020 C: ABC-12345 1021 C: 1022 C: 1024 When a command has been processed successfully, the EPP 1025 element MUST contain a child element that 1026 identifies the contact namespace and the location of the contact 1027 schema. The element contains the same child 1028 elements defined for a transfer query response. 1030 Example response: 1032 S: 1033 S: 1037 S: 1038 S: 1039 S: Command completed successfully 1040 S: 1041 S: 1042 S: 1046 S: sh8013 1047 S: pending 1048 S: ClientX 1049 S: 2000-06-08T22:00:00.0Z 1050 S: ClientY 1051 S: 2000-06-13T22:00:00.0Z 1052 S: 1053 S: 1054 S: 1055 S: ABC-12345 1056 S: 54322-XYZ 1057 S: 1058 S: 1059 S: 1061 An EPP error response MUST be returned if a command can not 1062 be processed for any reason. 1064 3.2.5 EPP Command 1066 The EPP command provides a transform operation that allows a 1067 client to modify the attributes of a contact object. In addition to 1068 the standard EPP command elements, the command MUST contain a 1069 element that identifies the contact namespace and the 1070 location of the contact schema. The element contains 1071 the following child elements: 1073 - A element that contains the server-unique identifier of 1074 the contact object to be updated. 1076 - An OPTIONAL element that contains attribute values to 1077 be added to the object. 1079 - An OPTIONAL element that contains attribute values to 1080 be removed from the object. 1082 - An OPTIONAL element that contains object attribute 1083 values to be changed. 1085 At least one , , or element 1086 MUST be provided. The and elements 1087 contain the following child elements: 1089 - One or more elements that contain status values to 1090 be associated with or removed from the object. When specifying a 1091 value to be removed, only the attribute value is significant; element 1092 text is not required to match a value for removal. 1094 A element contains the following OPTIONAL child 1095 elements. At least one child element MUST be present: 1097 - One or two elements that contain postal address 1098 information. Two elements are provided so that address information 1099 can be provided in both internationalized and localized forms; a 1100 "type" attribute is used to identify the two forms. If an 1101 internationalized form (type="int") is provided, element content MUST 1102 be represented in a subset of UTF-8 that can be represented in the 7- 1103 bit US-ASCII character set. If a localized form (type="loc") is 1104 provided, element content MAY be represented in unrestricted UTF-8. 1105 The element contains the following child 1106 elements: 1108 - A element that contains the name of the individual 1109 or role represented by the contact. 1111 - A element that contains the name of the organization 1112 with which the contact is affiliated. 1114 - A element that contains address information 1115 associated with the contact. A element contains the 1116 following child elements: 1118 - One, two, or three OPTIONAL elements that 1119 contain the contact's street address. 1121 - A element that contains the contact's city. 1123 - An OPTIONAL element that contains the contact's 1124 state or province. 1126 - An OPTIONAL element that contains the contact's 1127 postal code. 1129 - A element that contains the contact's country code. 1131 - A element that contains the contact's voice 1132 telephone number. 1134 - A element that contains the contact's facsimile 1135 telephone number. 1137 - A element that contains the contact's email address. 1139 - A element that contains authorization information 1140 associated with the contact object. This mapping includes a 1141 password-based authentication mechanism, but the schema allows new 1142 mechanisms to be defined in new schemas. 1144 - A element that allows a client to identify 1145 elements that require exceptional server operator handling to allow or 1146 restrict disclosure to third parties. See section 2.9 for a 1147 description of the child elements contained within the 1148 element. 1150 Example command: 1152 C: 1153 C: 1157 C: 1158 C: 1159 C: 1163 C: sh8013 1164 C: 1165 C: 1166 C: 1167 C: 1168 C: 1169 C: 1170 C: 1171 C: 124 Example Dr. 1172 C: Suite 200 1173 C: Dulles 1174 C: VA 1175 C: 20166-6503 1176 C: US 1177 C: 1178 C: 1179 C: +1.7034444444 1180 C: 1181 C: 1182 C: 2fooBAR 1183 C: 1184 C: 1185 C: 1186 C: 1187 C: 1188 C: 1189 C: 1190 C: 1191 C: ABC-12345 1192 C: 1193 C: 1195 When an command has been processed successfully, a server 1196 MUST respond with an EPP response with no element. 1198 Example response: 1200 S: 1201 S: 1205 S: 1206 S: 1207 S: Command completed successfully 1208 S: 1209 S: 1210 S: ABC-12345 1211 S: 54321-XYZ 1212 S: 1213 S: 1214 S: 1216 An EPP error response MUST be returned if an command can not 1217 be processed for any reason. 1219 3.2.6 Offline Review of Requested Actions 1221 Commands are processed by a server in the order they are received from 1222 a client. Though an immediate response confirming receipt and 1223 processing of the command is produced by the server, a server operator 1224 MAY perform an offline review of requested transform commands before 1225 completing the requested action. In such situations the response from 1226 the server MUST clearly note that the transform command has been 1227 received and processed, but the requested action is pending. The 1228 status of the corresponding object MUST clearly reflect processing of 1229 the pending action. The server MUST notify the client when offline 1230 processing of the action has been completed. 1232 Examples describing a command that requires offline review 1233 are included here. Note the result code and message returned in 1234 response to the command. 1236 S: 1237 S: 1241 S: 1242 S: 1243 S: Command completed successfully; action pending 1244 S: 1245 S: 1246 S: 1250 S: sh8013 1251 S: 1999-04-03T22:00:00.0Z 1252 S: 1253 S: 1254 S: 1255 S: ABC-12345 1256 S: 54321-XYZ 1257 S: 1258 S: 1259 S: 1261 The status of the contact object after returning this response MUST 1262 include "pendingCreate". The server operator reviews the request 1263 offline, and informs the client of the outcome of the review by 1264 queuing a service message for retrieval via the command. 1266 The service message MUST contain text in the , , 1267 element that describes the notification. In addition, the EPP 1268 element MUST contain a child element that 1269 identifies the contact namespace and the location of the contact 1270 schema. The element contains the following child 1271 elements: 1273 - A element that contains the server-unique identifier of 1274 the contact object. The element contains a REQUIRED 1275 "paResult" attribute. A positive boolean value indicates that the 1276 request has been approved and completed. A negative boolean value 1277 indicates that the request has been denied and the requested action 1278 has not been taken. 1280 - A element that contains the client transaction 1281 identifier and server transaction identifier returned with the 1282 original response to process the command. The client transaction 1283 identifier is OPTIONAL and will only be returned if the client 1284 provided an identifier with the original command. 1286 - A element that contains the date and time 1287 describing when review of the requested action was completed. 1289 Example "review completed" service message: 1291 S: 1292 S: 1296 S: 1297 S: 1298 S: Command completed successfully; ack to dequeue 1299 S: 1300 S: 1301 S: 1999-04-04T22:01:00.0Z 1302 S: Pending action completed successfully. 1303 S: 1304 S: 1305 S: 1309 S: sh8013 1310 S: 1311 S: ABC-12345 1312 S: 54321-XYZ 1313 S: 1314 S: 1999-04-04T22:00:00.0Z 1315 S: 1316 S: 1317 S: 1318 S: BCD-23456 1319 S: 65432-WXY 1320 S: 1321 S: 1322 S: 1324 4. Formal Syntax 1326 An EPP object mapping is specified in XML Schema notation. The formal 1327 syntax presented here is a complete schema representation of the 1328 object mapping suitable for automated validation of EPP XML instances. 1329 The BEGIN and END tags are not part of the schema; they are used to 1330 note the beginning and ending of the schema for URI registration 1331 purposes. 1333 BEGIN 1334 1336 1343 1346 1348 1351 1352 1353 Extensible Provisioning Protocol v1.0 1354 contact provisioning schema. 1355 1356 1358 1361 1362 1363 1364 1365 1366 1368 1371 1372 1373 1374 1375 1377 1378 1379 1380 1381 1382 1383 1385 1386 1387 1388 1389 1390 1392 1393 1394 1395 1396 1398 1399 1400 1401 1402 1403 1405 1406 1407 1408 1409 1411 1414 1415 1416 1417 1419 1421 1423 1424 1425 1427 1428 1430 1431 1432 1433 1435 1436 1437 1439 1441 1442 1443 1444 1445 1446 1448 1449 1450 1452 1453 1455 1457 1458 1459 1461 1462 1463 1464 1465 1466 1467 1468 1469 1471 1473 1475 1476 1477 1478 1479 1480 1482 1483 1485 1487 1490 1491 1492 1493 1494 1496 1499 1500 1501 1503 1504 1506 1509 1510 1511 1512 1514 1516 1518 1521 1522 1523 1524 1526 1528 1530 1531 1533 1536 1537 1538 1540 1541 1543 1546 1547 1548 1550 1552 1554 1556 1558 1560 1561 1563 1564 1565 1567 1569 1571 1572 1574 1576 1579 1580 1581 1582 1583 1585 1588 1589 1590 1592 1593 1595 1596 1597 1598 1600 1601 1603 1604 1605 1606 1608 1609 1610 1612 1615 1616 1617 1618 1619 1620 1622 1625 1626 1627 1628 1629 1631 1633 1635 1637 1638 1639 1640 1641 1643 1645 1647 1649 1651 1652 1654 1658 1659 1660 1661 1663 1665 1666 1667 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1686 1689 1690 1691 1692 1693 1694 1695 1697 1698 1699 1700 1702 1703 1704 1706 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1721 1724 1725 END 1727 5. Internationalization Considerations 1729 EPP is represented in XML, which provides native support for encoding 1730 information using the Unicode character set and its more compact 1731 representations including UTF-8. Conformant XML processors recognize 1732 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1733 identify and use other character encodings through use of an 1734 "encoding" attribute in an declaration, use of UTF-8 is 1735 RECOMMENDED in environments where parser encoding support 1736 incompatibility exists. 1738 All date-time values presented via EPP MUST be expressed in Universal 1739 Coordinated Time using the Gregorian calendar. XML Schema allows use 1740 of time zone identifiers to indicate offsets from the zero meridian, 1741 but this option MUST NOT be used with EPP. The extended date-time 1742 form using upper case "T" and "Z" characters defined in [RFC3339] MUST 1743 be used to represent date-time values as XML Schema does not support 1744 truncated date-time forms or lower case "T" and "Z" characters. 1746 Humans, organizations, and other entities often need to represent 1747 social information in both a commonly understood character set and a 1748 locally optimized character set. This specification provides features 1749 allowing representation of social information in both a subset of 1750 UTF-8 for broad readability and unrestricted UTF-8 for local 1751 optimization. 1753 6. IANA Considerations 1755 This document uses URNs to describe XML namespaces and XML schemas 1756 conforming to a registry mechanism described in [IETF-XML]. Two URI 1757 assignments are requested. 1759 Registration request for the contact namespace: 1761 URI: urn:ietf:params:xml:ns:contact-1.0 1763 Registrant Contact: See the "Author's Address" section of this 1764 document. 1766 XML: None. Namespace URIs do not represent an XML specification. 1768 Registration request for the contact XML schema: 1770 URI: urn:ietf:params:xml:schema:contact-1.0 1772 Registrant Contact: See the "Author's Address" section of this 1773 document. 1775 XML: See the "Formal Syntax" section of this document. 1777 7. Security Considerations 1779 Authorization information as described in section 2.8 is REQUIRED to 1780 create a contact object. This information is used in some query and 1781 transfer operations as an additional means of determining client 1782 authorization to perform the command. Failure to protect 1783 authorization information from inadvertent disclosure can result in 1784 unauthorized transfer operations and unauthorized information release. 1785 Both client and server MUST ensure that authorization information is 1786 stored and exchanged with high-grade encryption mechanisms to provide 1787 privacy services. 1789 The object mapping described in this document does not provide any 1790 other security services or introduce any additional considerations 1791 beyond those described by [EPP] and protocol layers used by EPP. 1793 8. Acknowledgements 1795 This document was originally written as an individual submission 1796 Internet-Draft. The provreg working group later adopted it as a 1797 working group document and provided many invaluable comments and 1798 suggested improvements. The author wishes to acknowledge the efforts 1799 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1800 editorial contributions. 1802 Specific suggestions that have been incorporated into this document 1803 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1804 Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1805 El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael Mealling, 1806 Patrick Mevzek, Asbjorn Steira, and Rick Wesson. 1808 9. References 1810 Normative References: 1812 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 1813 progress. 1815 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 1817 [ISO3166] ISO 3166-1: "Codes for the representation of names of 1818 countries and their subdivisions - Part 1: Country codes", October 1819 1997. 1821 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 1822 Requirement Levels", BCP 14, RFC 2119, March 1997. 1824 [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646", 1825 RFC 2279, January 1998. 1827 [RFC2822] P. Resnick: "Internet Message Format", RFC 2822, April 2001. 1829 [RFC3339] G. Klyne, C. Newman: "Date and Time on the Internet: 1830 Timestamps", RFC 3339, July 2002. 1832 [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 1833 (Second Edition)", W3C Recommendation 6 October 2000. 1835 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 1836 W3C Recommendation 2 May 2001. 1838 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 1839 Datatypes", W3C Recommendation 2 May 2001. 1841 Informative References: 1843 [RFC2781] P. Hoffman, F. Yergeau, "UTF-16, an encoding of ISO 10646", 1844 RFC 2781, February 2000. 1846 [E164a] ITU-T Recommendation E.164: "The International Public 1847 Telecommunication Numbering Plan", May 1997. 1849 [E164b] Complement To ITU-T Recommendation E.164 (05/1997): "List of 1850 ITU-T Recommendation E.164 assigned country codes", June 2000. 1852 10. Author's Address 1854 Scott Hollenbeck 1855 VeriSign Global Registry Services 1856 21345 Ridgetop Circle 1857 Dulles, VA 20166-6503 1858 USA 1859 shollenbeck@verisign.com 1861 A. Revisions From Previous Version 1863 (Note to RFC editor: please remove this section completely before 1864 publication as an RFC.) 1866 -06 to -07 (IESG review): 1868 Added section 2.9. 1870 Modified sections 3.1.2, 3.2.1, and 3.2.5 to include descriptions of 1871 the element described in section 2.9. 1873 Added element to command so that authorization 1874 decisions can be made when disclosure elements are also provided. 1876 B. Full Copyright Statement 1878 Copyright (C) The Internet Society 2003. All Rights Reserved. 1880 This document and translations of it may be copied and furnished to 1881 others, and derivative works that comment on or otherwise explain it 1882 or assist in its implementation may be prepared, copied, published and 1883 distributed, in whole or in part, without restriction of any kind, 1884 provided that the above copyright notice and this paragraph are 1885 included on all such copies and derivative works. However, this 1886 document itself may not be modified in any way, such as by removing 1887 the copyright notice or references to the Internet Society or other 1888 Internet organizations, except as needed for the purpose of developing 1889 Internet standards in which case the procedures for copyrights defined 1890 in the Internet Standards process must be followed, or as required to 1891 translate it into languages other than English. 1893 The limited permissions granted above are perpetual and will not be 1894 revoked by the Internet Society or its successors or assigns. 1896 This document and the information contained herein is provided on an 1897 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1898 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1899 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1900 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1901 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1903 Acknowledgement 1905 Funding for the RFC Editor function is currently provided by the 1906 Internet Society.