idnits 2.17.00 (12 Aug 2021) /tmp/idnits3492/draft-hollenbeck-rfc4933bis-01.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 (May 14, 2009) is 4754 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) == Outdated reference: draft-hollenbeck-rfc4930bis has been published as RFC 5730 -- 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 (~~), 2 warnings (==), 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) May 14, 2009 5 Intended status: Standards Track 6 Expires: November 15, 2009 8 Extensible Provisioning Protocol (EPP) Contact Mapping 9 draft-hollenbeck-rfc4933bis-01 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 November 15, 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 . . . . . . . . . . . . . . . . 7 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, pendingRenew, pendingTransfer, 190 pendingUpdate 192 A transform command has been processed for the object, but the 193 action has not been completed by the server. Server operators can 194 delay action completion for a variety of reasons, such as to allow 195 for human review or third-party action. A transform command that 196 is processed, but whose requested action is pending, is noted with 197 response code 1001. 199 When the requested action has been completed, the pendingCreate, 200 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 201 removed. All clients involved in the transaction MUST be notified 202 using a service message that the action has been completed and that 203 the status of the object has changed. 205 "ok" status MAY only be combined with "linked" status. 207 "linked" status MAY be combined with any status. 209 "pendingDelete" status MUST NOT be combined with either 210 "clientDeleteProhibited" or "serverDeleteProhibited" status. 212 "pendingTransfer" status MUST NOT be combined with either 213 "clientTransferProhibited" or "serverTransferProhibited" status. 214 "pendingUpdate" status MUST NOT be combined with either 215 "clientUpdateProhibited" or "serverUpdateProhibited" status. 217 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 218 status values MUST NOT be combined with each other. 220 Other status combinations not expressly prohibited MAY be used. 222 2.3. Individual and Organizational Names 224 Individual and organizational names associated with a contact are 225 represented using character strings. These strings have a specified 226 minimum length and a specified maximum length. Individual and 227 organizational names MAY be provided in both UTF-8 [RFC3629] and a 228 subset of UTF-8 that can be represented in 7-bit ASCII depending on 229 local needs. 231 2.4. Address 233 Every contact has associated postal address information. A postal 234 address contains OPTIONAL street information, city information, 235 OPTIONAL state/province information, an OPTIONAL postal code, and a 236 country identifier. Address information MAY be provided in both 237 UTF-8 and a subset of UTF-8 that can be represented in 7-bit ASCII 238 depending on local needs. 240 2.4.1. Street, City, and State or Province 242 Contact street, city, and state or province information is 243 represented using character strings. These strings have a specified 244 minimum length and a specified maximum length. 246 2.4.2. Postal Code 248 Contact postal codes are represented using character strings. These 249 strings have a specified minimum length and a specified maximum 250 length. 252 2.4.3. Country 254 Contact country identifiers are represented using two-character 255 identifiers specified in [ISO3166-1]. 257 2.5. Telephone Numbers 259 Contact telephone number structure is derived from structures defined 260 in [ITU.E164.2005]. Telephone numbers described in this mapping are 261 character strings that MUST begin with a plus sign ("+", ASCII value 262 0x002B), followed by a country code defined in [ITU.E164.2005], 263 followed by a dot (".", ASCII value 0x002E), followed by a sequence 264 of digits representing the telephone number. An optional "x" 265 attribute is provided to note telephone extension information. 267 2.6. Email Addresses 269 Email address syntax is defined in [RFC5322]. This mapping does not 270 prescribe minimum or maximum lengths for character strings used to 271 represent email addresses. 273 2.7. Dates and Times 275 Date and time attribute values MUST be represented in Universal 276 Coordinated Time (UTC) using the Gregorian calendar. The extended 277 date-time form using upper case "T" and "Z" characters defined in 278 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 279 values as XML Schema does not support truncated date-time forms or 280 lower case "T" and "Z" characters. 282 2.8. Authorization Information 284 Authorization information is associated with contact objects to 285 facilitate transfer operations. Authorization information is 286 assigned when a contact object is created, and it might be updated in 287 the future. This specification describes password-based 288 authorization information, though other mechanisms are possible. 290 2.9. Disclosure of Data Elements and Attributes 292 The EPP core protocol requires a server operator to announce data 293 collection policies to clients; see Section 2.4 of 294 [I-D.hollenbeck-rfc4930bis]. In conjunction with this disclosure 295 requirement, this mapping includes data elements that allow a client 296 to identify elements that require exceptional server operator 297 handling to allow or restrict disclosure to third parties. 299 A server operator announces a default disclosure policy when 300 establishing a session with a client. When an object is created or 301 updated, the client can specify contact attributes that require 302 exceptional disclosure handling using an OPTIONAL 303 element. Once set, disclosure preferences can be reviewed using a 304 contact information query. A server operator MUST reject any 305 transaction that requests disclosure practices that do not conform to 306 the announced data collection policy with a 2308 error response code. 308 If present, the element MUST contain a "flag" 309 attribute. The "flag" attribute contains an XML Schema boolean 310 value. A value of "true" or "1" (one) notes a client preference to 311 allow disclosure of the specified elements as an exception to the 312 stated data collection policy. A value of "false" or "0" (zero) 313 notes a client preference to not allow disclosure of the specified 314 elements as an exception to the stated data collection policy. 316 The element MUST contain at least one of the 317 following child elements: 319 320 321 322 323 324 325 326 327 328 Example element, flag="0": 330 331 332 333 335 In this example, the contact email address and voice telephone number 336 cannot be disclosed. All other elements are subject to disclosure in 337 accordance with the server's data collection policy. 339 Example element, flag="1": 341 342 343 344 345 347 In this example, the internationalized contact name, organization, 348 and address information can be disclosed. All other elements are 349 subject to disclosure in accordance with the server's data collection 350 policy. 352 Client identification features provided by the EPP command 353 and contact authorization information are used to determine if a 354 client is authorized to perform contact information query commands. 355 These features also determine if a client is authorized to receive 356 data that is otherwise marked for non-disclosure in a query response. 358 3. EPP Command Mapping 360 A detailed description of the EPP syntax and semantics can be found 361 in [I-D.hollenbeck-rfc4930bis]. The command mappings described here 362 are specifically for use in provisioning and managing contact objects 363 via EPP. 365 3.1. EPP Query Commands 367 EPP provides three commands to retrieve contact information: 368 to determine if a contact object can be provisioned within a 369 repository, to retrieve detailed information associated with a 370 contact object, and to retrieve contact object transfer 371 status information. 373 3.1.1. EPP Command 375 The EPP command is used to determine if an object can be 376 provisioned within a repository. It provides a hint that allows a 377 client to anticipate the success or failure of provisioning an object 378 using the command as object provisioning requirements are 379 ultimately a matter of server policy. 381 In addition to the standard EPP command elements, the command 382 MUST contain a element that identifies the contact 383 namespace. The element contains the following child 384 elements: 386 - One or more elements that contain the server-unique 387 identifier of the contact objects to be queried. 389 Example command: 391 C: 392 C: 393 C: 394 C: 395 C: 397 C: sh8013 398 C: sah8013 399 C: 8013sah 400 C: 401 C: 402 C: ABC-12345 403 C: 404 C: 406 When a command has been processed successfully, the EPP 407 element MUST contain a child element that 408 identifies the contact namespace. The element 409 contains one or more elements that contain the following 410 child elements: 412 - A element that identifies the queried object. This 413 element MUST contain an "avail" attribute whose value indicates 414 object availability (can it be provisioned or not) at the moment 415 the command was completed. A value of "1" or "true" means 416 that the object can be provisioned. A value of "0" or "false" 417 means that the object cannot be provisioned. 419 - An OPTIONAL element that MAY be provided when an 420 object cannot be provisioned. If present, this element contains 421 server-specific text to help explain why the object cannot be 422 provisioned. This text MUST be represented in the response 423 language previously negotiated with the client; an OPTIONAL "lang" 424 attribute MAY be present to identify the language if the 425 negotiated value is something other than the default value of "en" 426 (English). 428 Example response: 430 S: 431 S: 432 S: 433 S: 434 S: Command completed successfully 435 S: 436 S: 437 S: 439 S: 440 S: sh8013 441 S: 442 S: 443 S: sah8013 444 S: In use 445 S: 446 S: 447 S: 8013sah 448 S: 449 S: 450 S: 451 S: 452 S: ABC-12345 453 S: 54322-XYZ 454 S: 455 S: 456 S: 458 An EPP error response MUST be returned if a command cannot be 459 processed for any reason. 461 3.1.2. EPP Command 463 The EPP command is used to retrieve information associated 464 with a contact object. In addition to the standard EPP command 465 elements, the command MUST contain a element 466 that identifies the contact namespace. The element 467 contains the following child elements: 469 - A element that contains the server-unique identifier 470 of the contact object to be queried. 472 - An OPTIONAL element that contains authorization 473 information associated with the contact object. If this element 474 is not provided or if the authorization information is invalid, 475 server policy determines if the command is rejected or if response 476 information will be returned to the client. 478 Example command: 480 C: 481 C: 482 C: 483 C: 484 C: 486 C: sh8013 487 C: 488 C: 2fooBAR 489 C: 490 C: 491 C: 492 C: ABC-12345 493 C: 494 C: 496 When an command has been processed successfully, the EPP 497 element MUST contain a child element that 498 identifies the contact namespace. The element 499 contains the following child elements: 501 - A element that contains the server-unique identifier 502 of the contact object. 504 - A element that contains the Repository Object 505 IDentifier assigned to the contact object when the object was 506 created. 508 - One or more elements that describe the status of 509 the contact object. 511 - One or two elements that contain postal 512 address information. Two elements are provided so that address 513 information can be provided in both internationalized and 514 localized forms; a "type" attribute is used to identify the two 515 forms. If an internationalized form (type="int") is provided, 516 element content MUST be represented in a subset of UTF-8 that can 517 be represented in the 7-bit US-ASCII character set. If a 518 localized form (type="loc") is provided, element content MAY be 519 represented in unrestricted UTF-8. The 520 element contains the following child elements: 522 - A element that contains the name of the 523 individual or role represented by the contact. 525 - An OPTIONAL element that contains the name of the 526 organization with which the contact is affiliated. 528 - A element that contains address information 529 associated with the contact. A element contains 530 the following child elements: 532 - One, two, or three OPTIONAL elements that 533 contain the contact's street address. 535 - A element that contains the contact's city. 537 - An OPTIONAL element that contains the contact's 538 state or province. 540 - An OPTIONAL element that contains the contact's 541 postal code. 543 - A element that contains the contact's country 544 code. 546 - An OPTIONAL element that contains the contact's 547 voice telephone number. 549 - An OPTIONAL element that contains the contact's 550 facsimile telephone number. 552 - A element that contains the contact's email 553 address. 555 - A element that contains the identifier of the 556 sponsoring client. 558 - A element that contains the identifier of the 559 client that created the contact object. 561 - A element that contains the date and time of 562 contact object creation. 564 - A element that contains the identifier of the 565 client that last updated the contact object. This element MUST 566 NOT be present if the contact has never been modified. 568 - A element that contains the date and time of the 569 most recent contact object modification. This element MUST NOT be 570 present if the contact object has never been modified. 572 - A element that contains the date and time of the 573 most recent successful contact object transfer. This element MUST 574 NOT be provided if the contact object has never been transferred. 576 - A element that contains authorization 577 information associated with the contact object. This element MUST 578 NOT be provided if the querying client is not the current 579 sponsoring client. 581 - An OPTIONAL element that identifies elements 582 that require exceptional server operator handling to allow or 583 restrict disclosure to third parties. See Section 2.9 for a 584 description of the child elements contained within the element. 587 Example response for an authorized client: 589 S: 590 S: 591 S: 592 S: 593 S: Command completed successfully 594 S: 595 S: 596 S: 598 S: sh8013 599 S: SH8013-REP 600 S: 601 S: 602 S: 603 S: John Doe 604 S: Example Inc. 605 S: 606 S: 123 Example Dr. 607 S: Suite 100 608 S: Dulles 609 S: VA 610 S: 20166-6503 611 S: US 612 S: 613 S: 614 S: +1.7035555555 615 S: +1.7035555556 616 S: jdoe@example.com 617 S: ClientY 618 S: ClientX 619 S: 1999-04-03T22:00:00.0Z 620 S: ClientX 621 S: 1999-12-03T09:00:00.0Z 622 S: 2000-04-08T09:00:00.0Z 623 S: 624 S: 2fooBAR 625 S: 626 S: 627 S: 628 S: 629 S: 630 S: 631 S: 632 S: 633 S: ABC-12345 634 S: 54322-XYZ 635 S: 636 S: 637 S: 639 An EPP error response MUST be returned if an command cannot be 640 processed for any reason. 642 3.1.3. EPP Query Command 644 The EPP command provides a query operation that allows a 645 client to determine real-time status of pending and completed 646 transfer requests. In addition to the standard EPP command elements, 647 the command MUST contain an "op" attribute with value 648 "query", and a element that identifies the contact 649 namespace. The element MUST contain the following 650 child elements: 652 - A element that contains the server-unique identifier 653 of the contact object to be queried. 655 - An OPTIONAL element that contains authorization 656 information associated with the contact object. If this element 657 is not provided or if the authorization information is invalid, 658 server policy determines whether the command is rejected or the 659 response information will be returned to the client. 661 Example query command: 663 C: 664 C: 665 C: 666 C: 667 C: 669 C: sh8013 670 C: 671 C: 2fooBAR 672 C: 673 C: 674 C: 675 C: ABC-12345 676 C: 677 C: 679 When a query command has been processed successfully, the 680 EPP element MUST contain a child element 681 that identifies the contact namespace. The element 682 contains the following child elements: 684 - A element that contains the server-unique identifier 685 for the queried contact. 687 - A element that contains the state of the most 688 recent transfer request. 690 - A element that contains the identifier of the 691 client that requested the object transfer. 693 - A element that contains the date and time that 694 the transfer was requested. 696 - A element that contains the identifier of the 697 client that SHOULD act upon a PENDING transfer request. For all 698 other status types, the value identifies the client that took the 699 indicated action. 701 - A element that contains the date and time of a 702 required or completed response. For a pending request, the value 703 identifies the date and time by which a response is required 704 before an automated response action SHOULD be taken by the server. 705 For all other status types, the value identifies the date and time 706 when the request was completed. 708 Example query response: 710 S: 711 S: 712 S: 713 S: 714 S: Command completed successfully 715 S: 716 S: 717 S: 719 S: sh8013 720 S: pending 721 S: ClientX 722 S: 2000-06-06T22:00:00.0Z 723 S: ClientY 724 S: 2000-06-11T22:00:00.0Z 725 S: 726 S: 727 S: 728 S: ABC-12345 729 S: 54322-XYZ 730 S: 731 S: 732 S: 734 An EPP error response MUST be returned if a query command 735 cannot be processed for any reason. 737 3.2. EPP Transform Commands 739 EPP provides four commands to transform contact object information: 740 to create an instance of a contact object, to 741 delete an instance of a contact object, to manage contact 742 object sponsorship changes, and to change information 743 associated with a contact object. This document does not define a 744 mapping for the EPP command. 746 Transform commands are typically processed and completed in real 747 time. Server operators MAY receive and process transform commands, 748 but defer completing the requested action if human or third-party 749 review is required before the requested action can be completed. In 750 such situations, the server MUST return a 1001 response code to the 751 client to note that the command has been received and processed, but 752 the requested action is pending. The server MUST also manage the 753 status of the object that is the subject of the command to reflect 754 the initiation and completion of the requested action. Once the 755 action has been completed, all clients involved in the transaction 756 MUST be notified using a service message that the action has been 757 completed and that the status of the object has changed. Other 758 notification methods MAY be used in addition to the required service 759 message. 761 Server operators SHOULD confirm that a client is authorized to 762 perform a transform command on a given object. Any attempt to 763 transform an object by an unauthorized client MUST be rejected, and 764 the server MUST return a 2201 response code to the client to note 765 that the client lacks privileges to execute the requested command. 767 3.2.1. EPP Command 769 The EPP command provides a transform operation that allows a 770 client to create a contact object. In addition to the standard EPP 771 command elements, the command MUST contain a element that identifies the contact namespace. The element contains the following child elements: 775 - A element that contains the desired server-unique 776 identifier for the contact to be created. 778 - One or two elements that contain postal 779 address information. Two elements are provided so that address 780 information can be provided in both internationalized and 781 localized forms; a "type" attribute is used to identify the two 782 forms. If an internationalized form (type="int") is provided, 783 element content MUST be represented in a subset of UTF-8 that can 784 be represented in the 7-bit US-ASCII character set. If a 785 localized form (type="loc") is provided, element content MAY be 786 represented in unrestricted UTF-8. The 787 element contains the following child elements: 789 - A element that contains the name of the 790 individual or role represented by the contact. 792 - An OPTIONAL element that contains the name of the 793 organization with which the contact is affiliated. 795 - A element that contains address information 796 associated with the contact. A element contains 797 the following child elements: 799 - One, two, or three OPTIONAL elements that 800 contain the contact's street address. 802 - A element that contains the contact's city. 804 - An OPTIONAL element that contains the contact's 805 state or province. 807 - An OPTIONAL element that contains the contact's 808 postal code. 810 - A element that contains the contact's country 811 code. 813 - An OPTIONAL element that contains the contact's 814 voice telephone number. 816 - An OPTIONAL element that contains the contact's 817 facsimile telephone number. 819 - A element that contains the contact's email 820 address. 822 - A element that contains authorization 823 information to be associated with the contact object. This 824 mapping includes a password-based authentication mechanism, but 825 the schema allows new mechanisms to be defined in new schemas. 827 - An OPTIONAL element that allows a client to 828 identify elements that require exceptional server operator 829 handling to allow or restrict disclosure to third parties. See 830 Section 2.9 for a description of the child elements contained 831 within the element. 833 Example command: 835 C: 836 C: 837 C: 838 C: 839 C: 841 C: sh8013 842 C: 843 C: John Doe 844 C: Example Inc. 845 C: 846 C: 123 Example Dr. 847 C: Suite 100 848 C: Dulles 849 C: VA 850 C: 20166-6503 851 C: US 852 C: 853 C: 854 C: +1.7035555555 855 C: +1.7035555556 856 C: jdoe@example.com 857 C: 858 C: 2fooBAR 859 C: 860 C: 861 C: 862 C: 863 C: 864 C: 865 C: 866 C: ABC-12345 867 C: 868 C: 870 When a command has been processed successfully, the EPP 871 element MUST contain a child element that 872 identifies the contact namespace. The element 873 contains the following child elements: 875 - A element that contains the server-unique identifier 876 for the created contact. 878 - A element that contains the date and time of 879 contact object creation. 881 Example response: 883 S: 884 S: 885 S: 886 S: 887 S: Command completed successfully 888 S: 889 S: 890 S: 892 S: sh8013 893 S: 1999-04-03T22:00:00.0Z 894 S: 895 S: 896 S: 897 S: ABC-12345 898 S: 54321-XYZ 899 S: 900 S: 901 S: 903 An EPP error response MUST be returned if a command cannot 904 be processed for any reason. 906 3.2.2. EPP Command 908 The EPP command provides a transform operation that allows a 909 client to delete a contact object. In addition to the standard EPP 910 command elements, the command MUST contain a element that identifies the contact namespace. The element MUST contain the following child element: 914 - A element that contains the server-unique identifier 915 of the contact object to be deleted. 917 A contact object SHOULD NOT be deleted if it is associated with other 918 known objects. An associated contact SHOULD NOT be deleted until 919 associations with other known objects have been broken. A server 920 SHOULD notify clients that object relationships exist by sending a 921 2305 error response code when a command is attempted and 922 fails due to existing object relationships. 924 Example command: 926 C: 927 C: 928 C: 929 C: 930 C: 932 C: sh8013 933 C: 934 C: 935 C: ABC-12345 936 C: 937 C: 939 When a command has been processed successfully, a server 940 MUST respond with an EPP response with no element. 942 Example response: 944 S: 945 S: 946 S: 947 S: 948 S: Command completed successfully 949 S: 950 S: 951 S: ABC-12345 952 S: 54321-XYZ 953 S: 954 S: 955 S: 957 An EPP error response MUST be returned if a command cannot 958 be processed for any reason. 960 3.2.3. EPP Command 962 Renewal semantics do not apply to contact objects, so there is no 963 mapping defined for the EPP command. 965 3.2.4. EPP Command 967 The EPP command provides a transform operation that allows 968 a client to manage requests to transfer the sponsorship of a contact 969 object. In addition to the standard EPP command elements, the 970 command MUST contain a element that 971 identifies the contact namespace. The element 972 contains the following child elements: 974 - A element that contains the server-unique identifier 975 of the contact object for which a transfer request is to be 976 created, approved, rejected, or cancelled. 978 - A element that contains authorization 979 information associated with the contact object. 981 Every EPP command MUST contain an "op" attribute that 982 identifies the transfer operation to be performed as defined in 983 [I-D.hollenbeck-rfc4930bis]. 985 Example request command: 987 C: 988 C: 989 C: 990 C: 991 C: 993 C: sh8013 994 C: 995 C: 2fooBAR 996 C: 997 C: 998 C: 999 C: ABC-12345 1000 C: 1001 C: 1003 When a command has been processed successfully, the EPP 1004 element MUST contain a child element that 1005 identifies the contact namespace. The element 1006 contains the same child elements defined for a query 1007 response. 1009 Example response: 1011 S: 1012 S: 1013 S: 1014 S: 1015 S: Command completed successfully; action pending 1016 S: 1017 S: 1018 S: 1020 S: sh8013 1021 S: pending 1022 S: ClientX 1023 S: 2000-06-08T22:00:00.0Z 1024 S: ClientY 1025 S: 2000-06-13T22:00:00.0Z 1026 S: 1027 S: 1028 S: 1029 S: ABC-12345 1030 S: 54322-XYZ 1031 S: 1032 S: 1033 S: 1035 An EPP error response MUST be returned if a command cannot 1036 be processed for any reason. 1038 3.2.5. EPP Command 1040 The EPP command provides a transform operation that allows a 1041 client to modify the attributes of a contact object. In addition to 1042 the standard EPP command elements, the command MUST contain 1043 a element that identifies the contact namespace. 1044 The element contains the following child elements: 1046 - A element that contains the server-unique identifier 1047 of the contact object to be updated. 1049 - An OPTIONAL element that contains attribute values 1050 to be added to the object. 1052 - An OPTIONAL element that contains attribute values 1053 to be removed from the object. 1055 - An OPTIONAL element that contains object attribute 1056 values to be changed. 1058 At least one , , or element 1059 MUST be provided if the command is not being extended. All of these 1060 elements MAY be omitted if an extension is present. The 1061 and elements contain the following child 1062 elements: 1064 - One or more elements that contain status values 1065 to be associated with or removed from the object. When specifying 1066 a value to be removed, only the attribute value is significant; 1067 element text is not required to match a value for removal. 1069 A element contains the following OPTIONAL child 1070 elements. At least one child element MUST be present: 1072 - One or two elements that contain postal 1073 address information. Two elements are provided so that address 1074 information can be provided in both internationalized and 1075 localized forms; a "type" attribute is used to identify the two 1076 forms. If an internationalized form (type="int") is provided, 1077 element content MUST be represented in a subset of UTF-8 that can 1078 be represented in the 7-bit US-ASCII character set. If a 1079 localized form (type="loc") is provided, element content MAY be 1080 represented in unrestricted UTF-8. The 1081 element contains the following OPTIONAL child elements: 1083 - A element that contains the name of the 1084 individual or role represented by the contact. 1086 - A element that contains the name of the 1087 organization with which the contact is affiliated. 1089 - A element that contains address information 1090 associated with the contact. A element contains 1091 the following child elements: 1093 - One, two, or three OPTIONAL elements that 1094 contain the contact's street address. 1096 - A element that contains the contact's city. 1098 - An OPTIONAL element that contains the contact's 1099 state or province. 1101 - An OPTIONAL element that contains the contact's 1102 postal code. 1104 - A element that contains the contact's country 1105 code. 1107 - A element that contains the contact's voice 1108 telephone number. 1110 - A element that contains the contact's facsimile 1111 telephone number. 1113 - A element that contains the contact's email 1114 address. 1116 - A element that contains authorization 1117 information associated with the contact object. This mapping 1118 includes a password-based authentication mechanism, but the schema 1119 allows new mechanisms to be defined in new schemas. 1121 - A element that allows a client to identify 1122 elements that require exceptional server operator handling to 1123 allow or restrict disclosure to third parties. See Section 2.9 1124 for a description of the child elements contained within the 1125 element. 1127 Example command: 1129 C: 1130 C: 1131 C: 1132 C: 1133 C: 1135 C: sh8013 1136 C: 1137 C: 1138 C: 1139 C: 1140 C: 1141 C: 1142 C: 1143 C: 124 Example Dr. 1144 C: Suite 200 1145 C: Dulles 1146 C: VA 1147 C: 20166-6503 1148 C: US 1149 C: 1150 C: 1151 C: +1.7034444444 1152 C: 1153 C: 1154 C: 2fooBAR 1155 C: 1156 C: 1157 C: 1158 C: 1159 C: 1160 C: 1161 C: 1162 C: 1163 C: ABC-12345 1164 C: 1165 C: 1167 When an command has been processed successfully, a server 1168 MUST respond with an EPP response with no element. 1170 Example response: 1172 S: 1173 S: 1174 S: 1175 S: 1176 S: Command completed successfully 1177 S: 1178 S: 1179 S: ABC-12345 1180 S: 54321-XYZ 1181 S: 1182 S: 1183 S: 1185 An EPP error response MUST be returned if an command cannot 1186 be processed for any reason. 1188 3.3. Offline Review of Requested Actions 1190 Commands are processed by a server in the order they are received 1191 from a client. Though an immediate response confirming receipt and 1192 processing of the command is produced by the server, a server 1193 operator MAY perform an offline review of requested transform 1194 commands before completing the requested action. In such situations, 1195 the response from the server MUST clearly note that the transform 1196 command has been received and processed, but the requested action is 1197 pending. The status of the corresponding object MUST clearly reflect 1198 processing of the pending action. The server MUST notify the client 1199 when offline processing of the action has been completed. 1201 Examples describing a command that requires offline review 1202 are included here. Note the result code and message returned in 1203 response to the command. 1205 S: 1206 S: 1207 S: 1208 S: 1209 S: Command completed successfully; action pending 1210 S: 1211 S: 1212 S: 1214 S: sh8013 1215 S: 1999-04-03T22:00:00.0Z 1216 S: 1217 S: 1218 S: 1219 S: ABC-12345 1220 S: 54321-XYZ 1221 S: 1222 S: 1223 S: 1225 The status of the contact object after returning this response MUST 1226 include "pendingCreate". The server operator reviews the request 1227 offline, and informs the client of the outcome of the review either 1228 by queuing a service message for retrieval via the command or 1229 by using an out-of-band mechanism to inform the client of the 1230 request. 1232 The service message MUST contain text in the , , 1233 element that describes the notification. In addition, the EPP 1234 element MUST contain a child element that 1235 identifies the contact namespace. The element 1236 contains the following child elements: 1238 - A element that contains the server-unique identifier 1239 of the contact object. The element contains a 1240 REQUIRED "paResult" attribute. A positive boolean value indicates 1241 that the request has been approved and completed. A negative 1242 boolean value indicates that the request has been denied and the 1243 requested action has not been taken. 1245 - A element that contains the client transaction 1246 identifier and server transaction identifier returned with the 1247 original response to process the command. The client transaction 1248 identifier is OPTIONAL and will only be returned if the client 1249 provided an identifier with the original command. 1251 - A element that contains the date and time 1252 describing when review of the requested action was completed. 1254 Example "review completed" service message: 1256 S: 1257 S: 1258 S: 1259 S: 1260 S: Command completed successfully; ack to dequeue 1261 S: 1262 S: 1263 S: 1999-04-04T22:01:00.0Z 1264 S: Pending action completed successfully. 1265 S: 1266 S: 1267 S: 1269 S: sh8013 1270 S: 1271 S: ABC-12345 1272 S: 54321-XYZ 1273 S: 1274 S: 1999-04-04T22:00:00.0Z 1275 S: 1276 S: 1277 S: 1278 S: BCD-23456 1279 S: 65432-WXY 1280 S: 1281 S: 1282 S: 1284 4. Formal Syntax 1286 An EPP object mapping is specified in XML Schema notation. The 1287 formal syntax presented here is a complete schema representation of 1288 the object mapping suitable for automated validation of EPP XML 1289 instances. The BEGIN and END tags are not part of the schema; they 1290 are used to note the beginning and ending of the schema for URI 1291 registration purposes. 1293 BEGIN 1294 1296 1303 1306 1307 1309 1310 1311 Extensible Provisioning Protocol v1.0 1312 contact provisioning schema. 1313 1314 1316 1319 1320 1321 1322 1323 1324 1326 1329 1330 1331 1332 1333 1335 1336 1337 1338 1339 1340 1341 1343 1344 1345 1346 1348 1349 1351 1352 1353 1354 1355 1357 1358 1359 1360 1361 1362 1364 1365 1366 1367 1368 1370 1373 1374 1375 1376 1378 1380 1382 1383 1384 1386 1387 1389 1390 1391 1392 1394 1395 1396 1398 1400 1401 1402 1403 1404 1405 1407 1408 1409 1411 1412 1414 1416 1417 1418 1420 1421 1422 1423 1424 1425 1427 1428 1429 1431 1433 1435 1436 1437 1438 1439 1440 1442 1443 1445 1447 1450 1451 1452 1453 1454 1456 1459 1460 1461 1463 1464 1466 1469 1470 1471 1472 1474 1475 1477 1480 1481 1482 1483 1485 1487 1489 1490 1492 1495 1496 1497 1499 1500 1502 1505 1506 1507 1509 1511 1513 1515 1517 1519 1520 1522 1523 1524 1526 1528 1530 1531 1533 1535 1538 1539 1540 1541 1542 1544 1547 1548 1549 1551 1552 1554 1555 1556 1557 1559 1560 1562 1563 1564 1565 1567 1568 1569 1571 1574 1575 1576 1577 1578 1579 1581 1584 1585 1586 1587 1588 1590 1592 1594 1596 1597 1598 1599 1600 1602 1604 1606 1608 1610 1611 1613 1617 1618 1619 1620 1622 1624 1625 1626 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1645 1648 1649 1650 1651 1652 1653 1654 1656 1657 1658 1659 1661 1662 1663 1665 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1679 1682 1683 END 1685 5. Internationalization Considerations 1687 EPP is represented in XML, which provides native support for encoding 1688 information using the Unicode character set and its more compact 1689 representations including UTF-8. Conformant XML processors recognize 1690 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1691 identify and use other character encodings through use of an 1692 "encoding" attribute in an declaration, use of UTF-8 is 1693 RECOMMENDED in environments where parser encoding support 1694 incompatibility exists. 1696 All date-time values presented via EPP MUST be expressed in Universal 1697 Coordinated Time using the Gregorian calendar. The XML Schema allows 1698 use of time zone identifiers to indicate offsets from the zero 1699 meridian, but this option MUST NOT be used with EPP. The extended 1700 date-time form using upper case "T" and "Z" characters defined in 1701 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1702 values as the XML Schema does not support truncated date-time forms 1703 or lower case "T" and "Z" characters. 1705 Humans, organizations, and other entities often need to represent 1706 social information in both a commonly understood character set and a 1707 locally optimized character set. This specification provides 1708 features allowing representation of social information in both a 1709 subset of UTF-8 for broad readability and unrestricted UTF-8 for 1710 local optimization. 1712 6. IANA Considerations 1714 This document uses URNs to describe XML namespaces and XML schemas 1715 conforming to a registry mechanism described in [RFC3688]. Two URI 1716 assignments have been registered by the IANA. 1718 Registration request for the contact namespace: 1720 URI: urn:ietf:params:xml:ns:contact-1.0 1722 Registrant Contact: See the "Author's Address" section of this 1723 document. 1725 XML: None. Namespace URIs do not represent an XML specification. 1727 Registration request for the contact XML schema: 1729 URI: urn:ietf:params:xml:schema:contact-1.0 1731 Registrant Contact: See the "Author's Address" section of this 1732 document. 1734 XML: See the "Formal Syntax" section of this document. 1736 7. Security Considerations 1738 Authorization information as described in Section 2.8 is REQUIRED to 1739 create a contact object. This information is used in some query and 1740 transfer operations as an additional means of determining client 1741 authorization to perform the command. Failure to protect 1742 authorization information from inadvertent disclosure can result in 1743 unauthorized transfer operations and unauthorized information 1744 release. Both client and server MUST ensure that authorization 1745 information is stored and exchanged with high-grade encryption 1746 mechanisms to provide privacy services. 1748 The object mapping described in this document does not provide any 1749 other security services or introduce any additional considerations 1750 beyond those described by [I-D.hollenbeck-rfc4930bis] and protocol 1751 layers used by EPP. 1753 8. Acknowledgements 1755 This document was originally written as an individual submission 1756 Internet-Draft. The PROVREG working group later adopted it as a 1757 working group document and provided many invaluable comments and 1758 suggested improvements. The author wishes to acknowledge the efforts 1759 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1760 editorial contributions. 1762 Specific suggestions that have been incorporated into this document 1763 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1764 Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1765 El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael 1766 Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson. 1768 9. References 1770 9.1. Normative References 1772 [I-D.hollenbeck-rfc4930bis] 1773 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1774 draft-hollenbeck-rfc4930bis-01 (work in progress), 1775 May 2009. 1777 [ISO3166-1] 1778 International Organization for Standardization, "Codes for 1779 the representation of names of countries and their 1780 subdivisions -- Part 1: Country codes", ISO Standard 3166, 1781 November 2006. 1783 [ITU.E164.2005] 1784 International Telecommunication Union, "The international 1785 public telecommunication numbering plan", ITU- 1786 T Recommendation E.164, February 2005. 1788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1789 Requirement Levels", BCP 14, RFC 2119, March 1997. 1791 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1792 10646", STD 63, RFC 3629, November 2003. 1794 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1795 January 2004. 1797 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1798 October 2008. 1800 [W3C.REC-xml-20040204] 1801 Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., 1802 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1803 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1804 20040204, February 2004, 1805 . 1807 [W3C.REC-xmlschema-1-20041028] 1808 Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, 1809 "XML Schema Part 1: Structures Second Edition", World Wide 1810 Web Consortium Recommendation REC-xmlschema-1-20041028, 1811 October 2004, 1812 . 1814 [W3C.REC-xmlschema-2-20041028] 1815 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1816 Second Edition", World Wide Web Consortium 1817 Recommendation REC-xmlschema-2-20041028, October 2004, 1818 . 1820 9.2. Informative References 1822 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1823 10646", RFC 2781, February 2000. 1825 [RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1826 Contact Mapping", RFC 4933, May 2007. 1828 Appendix A. Changes from RFC 4933 1830 1. Changed "This document obsoletes RFC 3733" to "This document is 1831 intended to obsolete RFC 4933". 1832 2. Replaced references to RFC 0822 with references to 5322. 1833 3. Replaced references to RFC 3733 with references to 4933. 1834 4. Replaced references to RFC 4930 with references to 4930bis. 1835 5. Updated reference to ISO 3166-1. 1836 6. Modified text in Section 3.2.2 to include 2305 response code. 1837 7. Updated Section 5. 1838 8. Added "Other notification methods MAY be used in addition to the 1839 required service message" in Section 3.2. 1840 9. Added 2201 response code text in Section 3.2. 1842 Author's Address 1844 Scott Hollenbeck 1845 VeriSign, Inc. 1846 21345 Ridgetop Circle 1847 Dulles, VA 20166-6503 1848 US 1850 EMail: shollenbeck@verisign.com