idnits 2.17.1 draft-hollenbeck-rfc4933bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4933, but the abstract doesn't seem to directly say this. It does mention RFC4933 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 15, 2009) is 5427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4930bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.E164.2005' -- Obsolete informational reference (is this intentional?): RFC 4933 (Obsoleted by RFC 5733) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 Obsoletes: 4933 (if approved) June 15, 2009 5 Intended status: Standards Track 6 Expires: December 17, 2009 8 Extensible Provisioning Protocol (EPP) Contact Mapping 9 draft-hollenbeck-rfc4933bis-02 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 17, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes an Extensible Provisioning Protocol (EPP) 48 mapping for the provisioning and management of individual or 49 organizational social information identifiers (known as "contacts") 50 stored in a shared central repository. Specified in Extensible 51 Markup Language (XML), the mapping defines EPP command syntax and 52 semantics as applied to contacts. This document is intended to 53 obsolete RFC 4933. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Contact and Client Identifiers . . . . . . . . . . . . . . 3 61 2.2. Status Values . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Individual and Organizational Names . . . . . . . . . . . 5 63 2.4. Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.4.1. Street, City, and State or Province . . . . . . . . . 6 65 2.4.2. Postal Code . . . . . . . . . . . . . . . . . . . . . 6 66 2.4.3. Country . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.5. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 6 68 2.6. Email Addresses . . . . . . . . . . . . . . . . . . . . . 6 69 2.7. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6 70 2.8. Authorization Information . . . . . . . . . . . . . . . . 6 71 2.9. Disclosure of Data Elements and Attributes . . . . . . . . 7 72 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 8 74 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 9 75 3.1.2. EPP Command . . . . . . . . . . . . . . . . . . 10 76 3.1.3. EPP Query Command . . . . . . . . . . . . . 14 77 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 16 78 3.2.1. EPP Command . . . . . . . . . . . . . . . . . 17 79 3.2.2. EPP Command . . . . . . . . . . . . . . . . . 20 80 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 81 3.2.4. EPP Command . . . . . . . . . . . . . . . . 21 82 3.2.5. EPP Command . . . . . . . . . . . . . . . . . 23 83 3.3. Offline Review of Requested Actions . . . . . . . . . . . 27 84 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 85 5. Internationalization Considerations . . . . . . . . . . . . . 38 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 40 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 41 92 Appendix A. Changes from RFC 4933 . . . . . . . . . . . . . . . . 41 94 1. Introduction 96 This document describes a personal and organizational identifier 97 mapping for version 1.0 of the Extensible Provisioning Protocol 98 (EPP). This mapping is specified using the Extensible Markup 99 Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML 100 Schema notation as described in [W3C.REC-xmlschema-1-20041028] and 101 [W3C.REC-xmlschema-2-20041028]. This document is intended to 102 obsolete RFC 4933 [RFC4933]. 104 [I-D.hollenbeck-rfc4930bis] provides a complete description of EPP 105 command and response structures. A thorough understanding of the 106 base protocol specification is necessary to understand the mapping 107 described in this document. 109 XML is case sensitive. Unless stated otherwise, XML specifications 110 and examples provided in this document MUST be interpreted in the 111 character case presented to develop a conforming implementation. 113 1.1. Conventions Used in This Document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 In examples, "C:" represents lines sent by a protocol client and "S:" 120 represents lines returned by a protocol server. Indentation and 121 white space in examples are provided only to illustrate element 122 relationships and are not a REQUIRED feature of this protocol. 124 2. Object Attributes 126 An EPP contact object has attributes and associated values that can 127 be viewed and modified by the sponsoring client or the server. This 128 section describes each attribute type in detail. The formal syntax 129 for the attribute values described here can be found in the "Formal 130 Syntax" section of this document and in the appropriate normative 131 references. 133 2.1. Contact and Client Identifiers 135 All EPP contacts are identified by a server-unique identifier. 136 Contact identifiers are character strings with a specified minimum 137 length, a specified maximum length, and a specified format. Contact 138 identifiers use the "clIDType" client identifier syntax described in 139 [I-D.hollenbeck-rfc4930bis]. 141 2.2. Status Values 143 A contact object MUST always have at least one associated status 144 value. Status values can be set only by the client that sponsors a 145 contact object and by the server on which the object resides. A 146 client can change the status of a contact object using the EPP 147 command. Each status value MAY be accompanied by a string 148 of human-readable text that describes the rationale for the status 149 applied to the object. 151 A client MUST NOT alter status values set by the server. A server 152 MAY alter or override status values set by a client subject to local 153 server policies. The status of an object MAY change as a result of 154 either a client-initiated transform command or an action performed by 155 a server operator. 157 Status values that can be added or removed by a client are prefixed 158 with "client". Corresponding status values that can be added or 159 removed by a server are prefixed with "server". Status values that 160 do not begin with either "client" or "server" are server-managed. 162 Status Value Descriptions: 164 - clientDeleteProhibited, serverDeleteProhibited 166 Requests to delete the object MUST be rejected. 168 - clientTransferProhibited, serverTransferProhibited 170 Requests to transfer the object MUST be rejected. 172 - clientUpdateProhibited, serverUpdateProhibited 174 Requests to update the object (other than to remove this status) 175 MUST be rejected. 177 - linked 179 The contact object has at least one active association with 180 another object, such as a domain object. Servers SHOULD provide 181 services to determine existing object associations. 183 - ok 185 This is the normal status value for an object that has no pending 186 operations or prohibitions. This value is set and removed by the 187 server as other status values are added or removed. 189 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 191 A transform command has been processed for the object, but the 192 action has not been completed by the server. Server operators can 193 delay action completion for a variety of reasons, such as to allow 194 for human review or third-party action. A transform command that 195 is processed, but whose requested action is pending, is noted with 196 response code 1001. 198 When the requested action has been completed, the pendingCreate, 199 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 200 removed. All clients involved in the transaction MUST be notified 201 using a service message that the action has been completed and that 202 the status of the object has changed. 204 "ok" status MAY only be combined with "linked" status. 206 "linked" status MAY be combined with any status. 208 "pendingDelete" status MUST NOT be combined with either 209 "clientDeleteProhibited" or "serverDeleteProhibited" status. 211 "pendingTransfer" status MUST NOT be combined with either 212 "clientTransferProhibited" or "serverTransferProhibited" status. 213 "pendingUpdate" status MUST NOT be combined with either 214 "clientUpdateProhibited" or "serverUpdateProhibited" status. 216 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 217 status values MUST NOT be combined with each other. 219 Other status combinations not expressly prohibited MAY be used. 221 2.3. Individual and Organizational Names 223 Individual and organizational names associated with a contact are 224 represented using character strings. These strings have a specified 225 minimum length and a specified maximum length. Individual and 226 organizational names MAY be provided in both UTF-8 [RFC3629] and a 227 subset of UTF-8 that can be represented in 7-bit ASCII depending on 228 local needs. 230 2.4. Address 232 Every contact has associated postal address information. A postal 233 address contains OPTIONAL street information, city information, 234 OPTIONAL state/province information, an OPTIONAL postal code, and a 235 country identifier. Address information MAY be provided in both 236 UTF-8 and a subset of UTF-8 that can be represented in 7-bit ASCII 237 depending on local needs. 239 2.4.1. Street, City, and State or Province 241 Contact street, city, and state or province information is 242 represented using character strings. These strings have a specified 243 minimum length and a specified maximum length. 245 2.4.2. Postal Code 247 Contact postal codes are represented using character strings. These 248 strings have a specified minimum length and a specified maximum 249 length. 251 2.4.3. Country 253 Contact country identifiers are represented using two-character 254 identifiers specified in [ISO3166-1]. 256 2.5. Telephone Numbers 258 Contact telephone number structure is derived from structures defined 259 in [ITU.E164.2005]. Telephone numbers described in this mapping are 260 character strings that MUST begin with a plus sign ("+", ASCII value 261 0x002B), followed by a country code defined in [ITU.E164.2005], 262 followed by a dot (".", ASCII value 0x002E), followed by a sequence 263 of digits representing the telephone number. An optional "x" 264 attribute is provided to note telephone extension information. 266 2.6. Email Addresses 268 Email address syntax is defined in [RFC5322]. This mapping does not 269 prescribe minimum or maximum lengths for character strings used to 270 represent email addresses. 272 2.7. Dates and Times 274 Date and time attribute values MUST be represented in Universal 275 Coordinated Time (UTC) using the Gregorian calendar. The extended 276 date-time form using upper case "T" and "Z" characters defined in 277 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 278 values as XML Schema does not support truncated date-time forms or 279 lower case "T" and "Z" characters. 281 2.8. Authorization Information 283 Authorization information is associated with contact objects to 284 facilitate transfer operations. Authorization information is 285 assigned when a contact object is created, and it might be updated in 286 the future. This specification describes password-based 287 authorization information, though other mechanisms are possible. 289 2.9. Disclosure of Data Elements and Attributes 291 The EPP core protocol requires a server operator to announce data 292 collection policies to clients; see Section 2.4 of 293 [I-D.hollenbeck-rfc4930bis]. In conjunction with this disclosure 294 requirement, this mapping includes data elements that allow a client 295 to identify elements that require exceptional server operator 296 handling to allow or restrict disclosure to third parties. 298 A server operator announces a default disclosure policy when 299 establishing a session with a client. When an object is created or 300 updated, the client can specify contact attributes that require 301 exceptional disclosure handling using an OPTIONAL 302 element. Once set, disclosure preferences can be reviewed using a 303 contact information query. A server operator MUST reject any 304 transaction that requests disclosure practices that do not conform to 305 the announced data collection policy with a 2308 error response code. 307 If present, the element MUST contain a "flag" 308 attribute. The "flag" attribute contains an XML Schema boolean 309 value. A value of "true" or "1" (one) notes a client preference to 310 allow disclosure of the specified elements as an exception to the 311 stated data collection policy. A value of "false" or "0" (zero) 312 notes a client preference to not allow disclosure of the specified 313 elements as an exception to the stated data collection policy. 315 The element MUST contain at least one of the 316 following child elements: 318 319 320 321 322 323 324 325 326 327 Example element, flag="0": 329 330 331 332 334 In this example, the contact email address and voice telephone number 335 cannot be disclosed. All other elements are subject to disclosure in 336 accordance with the server's data collection policy. 338 Example element, flag="1": 340 341 342 343 344 346 In this example, the internationalized contact name, organization, 347 and address information can be disclosed. All other elements are 348 subject to disclosure in accordance with the server's data collection 349 policy. 351 Client identification features provided by the EPP command 352 and contact authorization information are used to determine if a 353 client is authorized to perform contact information query commands. 354 These features also determine if a client is authorized to receive 355 data that is otherwise marked for non-disclosure in a query response. 357 3. EPP Command Mapping 359 A detailed description of the EPP syntax and semantics can be found 360 in [I-D.hollenbeck-rfc4930bis]. The command mappings described here 361 are specifically for use in provisioning and managing contact objects 362 via EPP. 364 3.1. EPP Query Commands 366 EPP provides three commands to retrieve contact information: 367 to determine if a contact object can be provisioned within a 368 repository, to retrieve detailed information associated with a 369 contact object, and to retrieve contact object transfer 370 status information. 372 3.1.1. EPP Command 374 The EPP command is used to determine if an object can be 375 provisioned within a repository. It provides a hint that allows a 376 client to anticipate the success or failure of provisioning an object 377 using the command as object provisioning requirements are 378 ultimately a matter of server policy. 380 In addition to the standard EPP command elements, the command 381 MUST contain a element that identifies the contact 382 namespace. The element contains the following child 383 elements: 385 - One or more elements that contain the server-unique 386 identifier of the contact objects to be queried. 388 Example command: 390 C: 391 C: 392 C: 393 C: 394 C: 396 C: sh8013 397 C: sah8013 398 C: 8013sah 399 C: 400 C: 401 C: ABC-12345 402 C: 403 C: 405 When a command has been processed successfully, the EPP 406 element MUST contain a child element that 407 identifies the contact namespace. The element 408 contains one or more elements that contain the following 409 child elements: 411 - A element that identifies the queried object. This 412 element MUST contain an "avail" attribute whose value indicates 413 object availability (can it be provisioned or not) at the moment 414 the command was completed. A value of "1" or "true" means 415 that the object can be provisioned. A value of "0" or "false" 416 means that the object cannot be provisioned. 418 - An OPTIONAL element that MAY be provided when an 419 object cannot be provisioned. If present, this element contains 420 server-specific text to help explain why the object cannot be 421 provisioned. This text MUST be represented in the response 422 language previously negotiated with the client; an OPTIONAL "lang" 423 attribute MAY be present to identify the language if the 424 negotiated value is something other than the default value of "en" 425 (English). 427 Example response: 429 S: 430 S: 431 S: 432 S: 433 S: Command completed successfully 434 S: 435 S: 436 S: 438 S: 439 S: sh8013 440 S: 441 S: 442 S: sah8013 443 S: In use 444 S: 445 S: 446 S: 8013sah 447 S: 448 S: 449 S: 450 S: 451 S: ABC-12345 452 S: 54322-XYZ 453 S: 454 S: 455 S: 457 An EPP error response MUST be returned if a command cannot be 458 processed for any reason. 460 3.1.2. EPP Command 462 The EPP command is used to retrieve information associated 463 with a contact object. In addition to the standard EPP command 464 elements, the command MUST contain a element 465 that identifies the contact namespace. The element 466 contains the following child elements: 468 - A element that contains the server-unique identifier 469 of the contact object to be queried. 471 - An OPTIONAL element that contains authorization 472 information associated with the contact object. If this element 473 is not provided or if the authorization information is invalid, 474 server policy determines if the command is rejected or if response 475 information will be returned to the client. 477 Example command: 479 C: 480 C: 481 C: 482 C: 483 C: 485 C: sh8013 486 C: 487 C: 2fooBAR 488 C: 489 C: 490 C: 491 C: ABC-12345 492 C: 493 C: 495 When an command has been processed successfully, the EPP 496 element MUST contain a child element that 497 identifies the contact namespace. The element 498 contains the following child elements: 500 - A element that contains the server-unique identifier 501 of the contact object. 503 - A element that contains the Repository Object 504 IDentifier assigned to the contact object when the object was 505 created. 507 - One or more elements that describe the status of 508 the contact object. 510 - One or two elements that contain postal 511 address information. Two elements are provided so that address 512 information can be provided in both internationalized and 513 localized forms; a "type" attribute is used to identify the two 514 forms. If an internationalized form (type="int") is provided, 515 element content MUST be represented in a subset of UTF-8 that can 516 be represented in the 7-bit US-ASCII character set. If a 517 localized form (type="loc") is provided, element content MAY be 518 represented in unrestricted UTF-8. The 519 element contains the following child elements: 521 - A element that contains the name of the 522 individual or role represented by the contact. 524 - An OPTIONAL element that contains the name of the 525 organization with which the contact is affiliated. 527 - A element that contains address information 528 associated with the contact. A element contains 529 the following child elements: 531 - One, two, or three OPTIONAL elements that 532 contain the contact's street address. 534 - A element that contains the contact's city. 536 - An OPTIONAL element that contains the contact's 537 state or province. 539 - An OPTIONAL element that contains the contact's 540 postal code. 542 - A element that contains the contact's country 543 code. 545 - An OPTIONAL element that contains the contact's 546 voice telephone number. 548 - An OPTIONAL element that contains the contact's 549 facsimile telephone number. 551 - A element that contains the contact's email 552 address. 554 - A element that contains the identifier of the 555 sponsoring client. 557 - A element that contains the identifier of the 558 client that created the contact object. 560 - A element that contains the date and time of 561 contact object creation. 563 - A element that contains the identifier of the 564 client that last updated the contact object. This element MUST 565 NOT be present if the contact has never been modified. 567 - A element that contains the date and time of the 568 most recent contact object modification. This element MUST NOT be 569 present if the contact object has never been modified. 571 - A element that contains the date and time of the 572 most recent successful contact object transfer. This element MUST 573 NOT be provided if the contact object has never been transferred. 575 - A element that contains authorization 576 information associated with the contact object. This element MUST 577 NOT be provided if the querying client is not the current 578 sponsoring client. 580 - An OPTIONAL element that identifies elements 581 that require exceptional server operator handling to allow or 582 restrict disclosure to third parties. See Section 2.9 for a 583 description of the child elements contained within the element. 586 Example response for an authorized client: 588 S: 589 S: 590 S: 591 S: 592 S: Command completed successfully 593 S: 594 S: 595 S: 597 S: sh8013 598 S: SH8013-REP 599 S: 600 S: 601 S: 602 S: John Doe 603 S: Example Inc. 604 S: 605 S: 123 Example Dr. 606 S: Suite 100 607 S: Dulles 608 S: VA 609 S: 20166-6503 610 S: US 611 S: 612 S: 613 S: +1.7035555555 614 S: +1.7035555556 615 S: jdoe@example.com 616 S: ClientY 617 S: ClientX 618 S: 1999-04-03T22:00:00.0Z 619 S: ClientX 620 S: 1999-12-03T09:00:00.0Z 621 S: 2000-04-08T09:00:00.0Z 622 S: 623 S: 2fooBAR 624 S: 625 S: 626 S: 627 S: 628 S: 629 S: 630 S: 631 S: 632 S: ABC-12345 633 S: 54322-XYZ 634 S: 635 S: 636 S: 638 An EPP error response MUST be returned if an command cannot be 639 processed for any reason. 641 3.1.3. EPP Query Command 643 The EPP command provides a query operation that allows a 644 client to determine real-time status of pending and completed 645 transfer requests. In addition to the standard EPP command elements, 646 the command MUST contain an "op" attribute with value 647 "query", and a element that identifies the contact 648 namespace. The element MUST contain the following 649 child elements: 651 - A element that contains the server-unique identifier 652 of the contact object to be queried. 654 - An OPTIONAL element that contains authorization 655 information associated with the contact object. If this element 656 is not provided or if the authorization information is invalid, 657 server policy determines whether the command is rejected or the 658 response information will be returned to the client. 660 Example query command: 662 C: 663 C: 664 C: 665 C: 666 C: 668 C: sh8013 669 C: 670 C: 2fooBAR 671 C: 672 C: 673 C: 674 C: ABC-12345 675 C: 676 C: 678 When a query command has been processed successfully, the 679 EPP element MUST contain a child element 680 that identifies the contact namespace. The element 681 contains the following child elements: 683 - A element that contains the server-unique identifier 684 for the queried contact. 686 - A element that contains the state of the most 687 recent transfer request. 689 - A element that contains the identifier of the 690 client that requested the object transfer. 692 - A element that contains the date and time that 693 the transfer was requested. 695 - A element that contains the identifier of the 696 client that SHOULD act upon a PENDING transfer request. For all 697 other status types, the value identifies the client that took the 698 indicated action. 700 - A element that contains the date and time of a 701 required or completed response. For a pending request, the value 702 identifies the date and time by which a response is required 703 before an automated response action SHOULD be taken by the server. 704 For all other status types, the value identifies the date and time 705 when the request was completed. 707 Example query response: 709 S: 710 S: 711 S: 712 S: 713 S: Command completed successfully 714 S: 715 S: 716 S: 718 S: sh8013 719 S: pending 720 S: ClientX 721 S: 2000-06-06T22:00:00.0Z 722 S: ClientY 723 S: 2000-06-11T22:00:00.0Z 724 S: 725 S: 726 S: 727 S: ABC-12345 728 S: 54322-XYZ 729 S: 730 S: 731 S: 733 An EPP error response MUST be returned if a query command 734 cannot be processed for any reason. 736 3.2. EPP Transform Commands 738 EPP provides four commands to transform contact object information: 739 to create an instance of a contact object, to 740 delete an instance of a contact object, to manage contact 741 object sponsorship changes, and to change information 742 associated with a contact object. This document does not define a 743 mapping for the EPP command. 745 Transform commands are typically processed and completed in real 746 time. Server operators MAY receive and process transform commands, 747 but defer completing the requested action if human or third-party 748 review is required before the requested action can be completed. In 749 such situations, the server MUST return a 1001 response code to the 750 client to note that the command has been received and processed, but 751 the requested action is pending. The server MUST also manage the 752 status of the object that is the subject of the command to reflect 753 the initiation and completion of the requested action. Once the 754 action has been completed, all clients involved in the transaction 755 MUST be notified using a service message that the action has been 756 completed and that the status of the object has changed. Other 757 notification methods MAY be used in addition to the required service 758 message. 760 Server operators SHOULD confirm that a client is authorized to 761 perform a transform command on a given object. Any attempt to 762 transform an object by an unauthorized client MUST be rejected, and 763 the server MUST return a 2201 response code to the client to note 764 that the client lacks privileges to execute the requested command. 766 3.2.1. EPP Command 768 The EPP command provides a transform operation that allows a 769 client to create a contact object. In addition to the standard EPP 770 command elements, the command MUST contain a element that identifies the contact namespace. The element contains the following 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 778 address information. Two elements are provided so that address 779 information can be provided in both internationalized and 780 localized forms; a "type" attribute is used to identify the two 781 forms. If an internationalized form (type="int") is provided, 782 element content MUST be represented in a subset of UTF-8 that can 783 be represented in the 7-bit US-ASCII character set. If a 784 localized form (type="loc") is provided, element content MAY be 785 represented in unrestricted UTF-8. The 786 element contains the following child elements: 788 - A element that contains the name of the 789 individual 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 796 the 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 810 code. 812 - An OPTIONAL element that contains the contact's 813 voice telephone number. 815 - An OPTIONAL element that contains the contact's 816 facsimile telephone number. 818 - A element that contains the contact's email 819 address. 821 - A element that contains authorization 822 information to be associated with the contact object. This 823 mapping includes a password-based authentication mechanism, but 824 the schema allows new mechanisms to be defined in new schemas. 826 - An OPTIONAL element that allows a client to 827 identify elements that require exceptional server operator 828 handling to allow or restrict disclosure to third parties. See 829 Section 2.9 for a description of the child elements contained 830 within the element. 832 Example command: 834 C: 835 C: 836 C: 837 C: 838 C: 840 C: sh8013 841 C: 842 C: John Doe 843 C: Example Inc. 844 C: 845 C: 123 Example Dr. 846 C: Suite 100 847 C: Dulles 848 C: VA 849 C: 20166-6503 850 C: US 851 C: 852 C: 853 C: +1.7035555555 854 C: +1.7035555556 855 C: jdoe@example.com 856 C: 857 C: 2fooBAR 858 C: 859 C: 860 C: 861 C: 862 C: 863 C: 864 C: 865 C: ABC-12345 866 C: 867 C: 869 When a command has been processed successfully, the EPP 870 element MUST contain a child element that 871 identifies the contact namespace. The element 872 contains the following child elements: 874 - A element that contains the server-unique identifier 875 for the created contact. 877 - A element that contains the date and time of 878 contact object creation. 880 Example response: 882 S: 883 S: 884 S: 885 S: 886 S: Command completed successfully 887 S: 888 S: 889 S: 891 S: sh8013 892 S: 1999-04-03T22:00:00.0Z 893 S: 894 S: 895 S: 896 S: ABC-12345 897 S: 54321-XYZ 898 S: 899 S: 900 S: 902 An EPP error response MUST be returned if a command cannot 903 be processed for any reason. 905 3.2.2. EPP Command 907 The EPP command provides a transform operation that allows a 908 client to delete a contact object. In addition to the standard EPP 909 command elements, the command MUST contain a element that identifies the contact namespace. The element MUST contain the following child element: 913 - A element that contains the server-unique identifier 914 of the contact object to be deleted. 916 A contact object SHOULD NOT be deleted if it is associated with other 917 known objects. An associated contact SHOULD NOT be deleted until 918 associations with other known objects have been broken. A server 919 SHOULD notify clients that object relationships exist by sending a 920 2305 error response code when a command is attempted and 921 fails due to existing object relationships. 923 Example command: 925 C: 926 C: 927 C: 928 C: 929 C: 931 C: sh8013 932 C: 933 C: 934 C: ABC-12345 935 C: 936 C: 938 When a command has been processed successfully, a server 939 MUST respond with an EPP response with no element. 941 Example response: 943 S: 944 S: 945 S: 946 S: 947 S: Command completed successfully 948 S: 949 S: 950 S: ABC-12345 951 S: 54321-XYZ 952 S: 953 S: 954 S: 956 An EPP error response MUST be returned if a command cannot 957 be processed for any reason. 959 3.2.3. EPP Command 961 Renewal semantics do not apply to contact objects, so there is no 962 mapping defined for the EPP command. 964 3.2.4. EPP Command 966 The EPP command provides a transform operation that allows 967 a client to manage requests to transfer the sponsorship of a contact 968 object. In addition to the standard EPP command elements, the 969 command MUST contain a element that 970 identifies the contact namespace. The element 971 contains the following child elements: 973 - A element that contains the server-unique identifier 974 of the contact object for which a transfer request is to be 975 created, approved, rejected, or cancelled. 977 - A element that contains authorization 978 information associated with the contact object. 980 Every EPP command MUST contain an "op" attribute that 981 identifies the transfer operation to be performed as defined in 982 [I-D.hollenbeck-rfc4930bis]. 984 Example request command: 986 C: 987 C: 988 C: 989 C: 990 C: 992 C: sh8013 993 C: 994 C: 2fooBAR 995 C: 996 C: 997 C: 998 C: ABC-12345 999 C: 1000 C: 1002 When a command has been processed successfully, the EPP 1003 element MUST contain a child element that 1004 identifies the contact namespace. The element 1005 contains the same child elements defined for a query 1006 response. 1008 Example response: 1010 S: 1011 S: 1012 S: 1013 S: 1014 S: Command completed successfully; action pending 1015 S: 1016 S: 1017 S: 1019 S: sh8013 1020 S: pending 1021 S: ClientX 1022 S: 2000-06-08T22:00:00.0Z 1023 S: ClientY 1024 S: 2000-06-13T22:00:00.0Z 1025 S: 1026 S: 1027 S: 1028 S: ABC-12345 1029 S: 54322-XYZ 1030 S: 1031 S: 1032 S: 1034 An EPP error response MUST be returned if a command cannot 1035 be processed for any reason. 1037 3.2.5. EPP Command 1039 The EPP command provides a transform operation that allows a 1040 client to modify the attributes of a contact object. In addition to 1041 the standard EPP command elements, the command MUST contain 1042 a element that identifies the contact namespace. 1043 The element contains the following child elements: 1045 - A element that contains the server-unique identifier 1046 of the contact object to be updated. 1048 - An OPTIONAL element that contains attribute values 1049 to be added to the object. 1051 - An OPTIONAL element that contains attribute values 1052 to be removed from the object. 1054 - An OPTIONAL element that contains object attribute 1055 values to be changed. 1057 At least one , , or element 1058 MUST be provided if the command is not being extended. All of these 1059 elements MAY be omitted if an extension is present. The 1060 and elements contain the following child 1061 elements: 1063 - One or more elements that contain status values 1064 to be associated with or removed from the object. When specifying 1065 a value to be removed, only the attribute value is significant; 1066 element text is not required to match a value for removal. 1068 A element contains the following OPTIONAL child 1069 elements. At least one child element MUST be present: 1071 - One or two elements that contain postal 1072 address information. Two elements are provided so that address 1073 information can be provided in both internationalized and 1074 localized forms; a "type" attribute is used to identify the two 1075 forms. If an internationalized form (type="int") is provided, 1076 element content MUST be represented in a subset of UTF-8 that can 1077 be represented in the 7-bit US-ASCII character set. If a 1078 localized form (type="loc") is provided, element content MAY be 1079 represented in unrestricted UTF-8. The 1080 element contains the following OPTIONAL child elements: 1082 - A element that contains the name of the 1083 individual or role represented by the contact. 1085 - A element that contains the name of the 1086 organization with which the contact is affiliated. 1088 - A element that contains address information 1089 associated with the contact. A element contains 1090 the following child elements: 1092 - One, two, or three OPTIONAL elements that 1093 contain the contact's street address. 1095 - A element that contains the contact's city. 1097 - An OPTIONAL element that contains the contact's 1098 state or province. 1100 - An OPTIONAL element that contains the contact's 1101 postal code. 1103 - A element that contains the contact's country 1104 code. 1106 - A element that contains the contact's voice 1107 telephone number. 1109 - A element that contains the contact's facsimile 1110 telephone number. 1112 - A element that contains the contact's email 1113 address. 1115 - A element that contains authorization 1116 information associated with the contact object. This mapping 1117 includes a password-based authentication mechanism, but the schema 1118 allows new mechanisms to be defined in new schemas. 1120 - A element that allows a client to identify 1121 elements that require exceptional server operator handling to 1122 allow or restrict disclosure to third parties. See Section 2.9 1123 for a description of the child elements contained within the 1124 element. 1126 Example command: 1128 C: 1129 C: 1130 C: 1131 C: 1132 C: 1134 C: sh8013 1135 C: 1136 C: 1137 C: 1138 C: 1139 C: 1140 C: 1141 C: 1142 C: 124 Example Dr. 1143 C: Suite 200 1144 C: Dulles 1145 C: VA 1146 C: 20166-6503 1147 C: US 1148 C: 1149 C: 1150 C: +1.7034444444 1151 C: 1152 C: 1153 C: 2fooBAR 1154 C: 1155 C: 1156 C: 1157 C: 1158 C: 1159 C: 1160 C: 1161 C: 1162 C: ABC-12345 1163 C: 1164 C: 1166 When an command has been processed successfully, a server 1167 MUST respond with an EPP response with no element. 1169 Example response: 1171 S: 1172 S: 1173 S: 1174 S: 1175 S: Command completed successfully 1176 S: 1177 S: 1178 S: ABC-12345 1179 S: 54321-XYZ 1180 S: 1181 S: 1182 S: 1184 An EPP error response MUST be returned if an command cannot 1185 be processed for any reason. 1187 3.3. Offline Review of Requested Actions 1189 Commands are processed by a server in the order they are received 1190 from a client. Though an immediate response confirming receipt and 1191 processing of the command is produced by the server, a server 1192 operator MAY perform an offline review of requested transform 1193 commands before completing the requested action. In such situations, 1194 the response from the server MUST clearly note that the transform 1195 command has been received and processed, but the requested action is 1196 pending. The status of the corresponding object MUST clearly reflect 1197 processing of the pending action. The server MUST notify the client 1198 when offline processing of the action has been completed. 1200 Examples describing a command that requires offline review 1201 are included here. Note the result code and message returned in 1202 response to the command. 1204 S: 1205 S: 1206 S: 1207 S: 1208 S: Command completed successfully; action pending 1209 S: 1210 S: 1211 S: 1213 S: sh8013 1214 S: 1999-04-03T22:00:00.0Z 1215 S: 1216 S: 1217 S: 1218 S: ABC-12345 1219 S: 54321-XYZ 1220 S: 1221 S: 1222 S: 1224 The status of the contact object after returning this response MUST 1225 include "pendingCreate". The server operator reviews the request 1226 offline, and informs the client of the outcome of the review either 1227 by queuing a service message for retrieval via the command or 1228 by using an out-of-band mechanism to inform the client of the 1229 request. 1231 The service message MUST contain text in the , , 1232 element that describes the notification. In addition, the EPP 1233 element MUST contain a child element that 1234 identifies the contact namespace. The element 1235 contains the following child elements: 1237 - A element that contains the server-unique identifier 1238 of the contact object. The element contains a 1239 REQUIRED "paResult" attribute. A positive boolean value indicates 1240 that the request has been approved and completed. A negative 1241 boolean value indicates that the request has been denied and the 1242 requested action has not been taken. 1244 - A element that contains the client transaction 1245 identifier and server transaction identifier returned with the 1246 original response to process the command. The client transaction 1247 identifier is OPTIONAL and will only be returned if the client 1248 provided an identifier with the original command. 1250 - A element that contains the date and time 1251 describing when review of the requested action was completed. 1253 Example "review completed" service message: 1255 S: 1256 S: 1257 S: 1258 S: 1259 S: Command completed successfully; ack to dequeue 1260 S: 1261 S: 1262 S: 1999-04-04T22:01:00.0Z 1263 S: Pending action completed successfully. 1264 S: 1265 S: 1266 S: 1268 S: sh8013 1269 S: 1270 S: ABC-12345 1271 S: 54321-XYZ 1272 S: 1273 S: 1999-04-04T22:00:00.0Z 1274 S: 1275 S: 1276 S: 1277 S: BCD-23456 1278 S: 65432-WXY 1279 S: 1280 S: 1281 S: 1283 4. Formal Syntax 1285 An EPP object mapping is specified in XML Schema notation. The 1286 formal syntax presented here is a complete schema representation of 1287 the object mapping suitable for automated validation of EPP XML 1288 instances. The BEGIN and END tags are not part of the schema; they 1289 are used to note the beginning and ending of the schema for URI 1290 registration purposes. 1292 BEGIN 1293 1295 1302 1305 1306 1308 1309 1310 Extensible Provisioning Protocol v1.0 1311 contact provisioning schema. 1312 1313 1315 1318 1319 1320 1321 1322 1323 1325 1328 1329 1330 1331 1332 1334 1335 1336 1337 1338 1339 1340 1342 1343 1344 1345 1347 1348 1350 1351 1352 1353 1354 1356 1357 1358 1359 1360 1361 1363 1364 1365 1366 1367 1369 1372 1373 1374 1375 1377 1379 1381 1382 1383 1385 1386 1388 1389 1390 1391 1393 1394 1395 1397 1399 1400 1401 1402 1403 1404 1406 1407 1408 1410 1411 1413 1415 1416 1417 1419 1420 1421 1422 1423 1424 1426 1427 1428 1430 1432 1434 1435 1436 1437 1438 1439 1441 1442 1444 1446 1449 1450 1451 1452 1453 1455 1458 1459 1460 1462 1463 1465 1468 1469 1470 1471 1473 1474 1476 1479 1480 1481 1482 1484 1486 1488 1489 1491 1494 1495 1496 1498 1499 1501 1504 1505 1506 1508 1510 1512 1514 1516 1518 1519 1521 1522 1523 1525 1527 1529 1530 1532 1534 1537 1538 1539 1540 1541 1543 1546 1547 1548 1550 1551 1553 1554 1555 1556 1558 1559 1561 1562 1563 1564 1566 1567 1568 1570 1573 1574 1575 1576 1577 1578 1580 1583 1584 1585 1586 1587 1589 1591 1593 1595 1596 1597 1598 1599 1601 1603 1605 1607 1609 1610 1612 1616 1617 1618 1619 1621 1623 1624 1625 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1644 1647 1648 1649 1650 1651 1652 1653 1655 1656 1657 1658 1660 1661 1662 1664 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1678 1681 1682 END 1684 5. Internationalization Considerations 1686 EPP is represented in XML, which provides native support for encoding 1687 information using the Unicode character set and its more compact 1688 representations including UTF-8. Conformant XML processors recognize 1689 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1690 identify and use other character encodings through use of an 1691 "encoding" attribute in an declaration, use of UTF-8 is 1692 RECOMMENDED in environments where parser encoding support 1693 incompatibility exists. 1695 All date-time values presented via EPP MUST be expressed in Universal 1696 Coordinated Time using the Gregorian calendar. The XML Schema allows 1697 use of time zone identifiers to indicate offsets from the zero 1698 meridian, but this option MUST NOT be used with EPP. The extended 1699 date-time form using upper case "T" and "Z" characters defined in 1700 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1701 values as the XML Schema does not support truncated date-time forms 1702 or lower case "T" and "Z" characters. 1704 Humans, organizations, and other entities often need to represent 1705 social information in both a commonly understood character set and a 1706 locally optimized character set. This specification provides 1707 features allowing representation of social information in both a 1708 subset of UTF-8 for broad readability and unrestricted UTF-8 for 1709 local optimization. 1711 6. IANA Considerations 1713 This document uses URNs to describe XML namespaces and XML schemas 1714 conforming to a registry mechanism described in [RFC3688]. Two URI 1715 assignments have been registered by the IANA. 1717 Registration request for the contact namespace: 1719 URI: urn:ietf:params:xml:ns:contact-1.0 1721 Registrant Contact: See the "Author's Address" section of this 1722 document. 1724 XML: None. Namespace URIs do not represent an XML specification. 1726 Registration request for the contact XML schema: 1728 URI: urn:ietf:params:xml:schema:contact-1.0 1730 Registrant Contact: See the "Author's Address" section of this 1731 document. 1733 XML: See the "Formal Syntax" section of this document. 1735 7. Security Considerations 1737 Authorization information as described in Section 2.8 is REQUIRED to 1738 create a contact object. This information is used in some query and 1739 transfer operations as an additional means of determining client 1740 authorization to perform the command. Failure to protect 1741 authorization information from inadvertent disclosure can result in 1742 unauthorized transfer operations and unauthorized information 1743 release. Both client and server MUST ensure that authorization 1744 information is stored and exchanged with high-grade encryption 1745 mechanisms to provide privacy services. 1747 The object mapping described in this document does not provide any 1748 other security services or introduce any additional considerations 1749 beyond those described by [I-D.hollenbeck-rfc4930bis] and protocol 1750 layers used by EPP. 1752 8. Acknowledgements 1754 This document was originally written as an individual submission 1755 Internet-Draft. The PROVREG working group later adopted it as a 1756 working group document and provided many invaluable comments and 1757 suggested improvements. The author wishes to acknowledge the efforts 1758 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1759 editorial contributions. 1761 Specific suggestions that have been incorporated into this document 1762 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1763 Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1764 El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael 1765 Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson. 1767 9. References 1769 9.1. Normative References 1771 [I-D.hollenbeck-rfc4930bis] 1772 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1773 draft-hollenbeck-rfc4930bis-02 (work in progress), 1774 June 2009. 1776 [ISO3166-1] 1777 International Organization for Standardization, "Codes for 1778 the representation of names of countries and their 1779 subdivisions -- Part 1: Country codes", ISO Standard 3166, 1780 November 2006. 1782 [ITU.E164.2005] 1783 International Telecommunication Union, "The international 1784 public telecommunication numbering plan", ITU- 1785 T Recommendation E.164, February 2005. 1787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1788 Requirement Levels", BCP 14, RFC 2119, March 1997. 1790 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1791 10646", STD 63, RFC 3629, November 2003. 1793 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1794 January 2004. 1796 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1797 October 2008. 1799 [W3C.REC-xml-20040204] 1800 Yergeau, F., Maler, E., Bray, T., Paoli, J., and C. 1801 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 1802 (Third Edition)", World Wide Web Consortium 1803 FirstEdition REC-xml-20040204, February 2004, 1804 . 1806 [W3C.REC-xmlschema-1-20041028] 1807 Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, 1808 "XML Schema Part 1: Structures Second Edition", World Wide 1809 Web Consortium Recommendation REC-xmlschema-1-20041028, 1810 October 2004, 1811 . 1813 [W3C.REC-xmlschema-2-20041028] 1814 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1815 Second Edition", World Wide Web Consortium 1816 Recommendation REC-xmlschema-2-20041028, October 2004, 1817 . 1819 9.2. Informative References 1821 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1822 10646", RFC 2781, February 2000. 1824 [RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1825 Contact Mapping", RFC 4933, May 2007. 1827 Appendix A. Changes from RFC 4933 1829 1. Changed "This document obsoletes RFC 3733" to "This document is 1830 intended to obsolete RFC 4933". 1831 2. Replaced references to RFC 0822 with references to 5322. 1832 3. Replaced references to RFC 3733 with references to 4933. 1833 4. Replaced references to RFC 4930 with references to 4930bis. 1834 5. Updated reference to ISO 3166-1. 1835 6. Removed pendingRenew status from Section 2.2 because this 1836 document does not define a mapping for the EPP command. 1837 7. Modified text in Section 3.2.2 to include 2305 response code. 1838 8. Updated Section 5. 1839 9. Added "Other notification methods MAY be used in addition to the 1840 required service message" in Section 3.2. 1841 10. Added 2201 response code text in Section 3.2. 1843 Author's Address 1845 Scott Hollenbeck 1846 VeriSign, Inc. 1847 21345 Ridgetop Circle 1848 Dulles, VA 20166-6503 1849 US 1851 EMail: shollenbeck@verisign.com