idnits 2.17.00 (12 Aug 2021) /tmp/idnits9907/draft-hollenbeck-rfc4933bis-00.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 (April 6, 2009) is 4792 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. 'ITU.E164.2005' -- Obsolete informational reference (is this intentional?): RFC 4933 (Obsoleted by RFC 5733) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 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) April 6, 2009 5 Intended status: Standards Track 6 Expires: October 8, 2009 8 Extensible Provisioning Protocol (EPP) Contact Mapping 9 draft-hollenbeck-rfc4933bis-00 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 October 8, 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 [ISO.3166.1997]. 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. 759 3.2.1. EPP Command 761 The EPP command provides a transform operation that allows a 762 client to create a contact object. In addition to the standard EPP 763 command elements, the command MUST contain a element that identifies the contact namespace. The element contains the following child elements: 767 - A element that contains the desired server-unique 768 identifier for the contact to be created. 770 - One or two elements that contain postal 771 address information. Two elements are provided so that address 772 information can be provided in both internationalized and 773 localized forms; a "type" attribute is used to identify the two 774 forms. If an internationalized form (type="int") is provided, 775 element content MUST be represented in a subset of UTF-8 that can 776 be represented in the 7-bit US-ASCII character set. If a 777 localized form (type="loc") is provided, element content MAY be 778 represented in unrestricted UTF-8. The 779 element contains the following child elements: 781 - A element that contains the name of the 782 individual or role represented by the contact. 784 - An OPTIONAL element that contains the name of the 785 organization with which the contact is affiliated. 787 - A element that contains address information 788 associated with the contact. A element contains 789 the following child elements: 791 - One, two, or three OPTIONAL elements that 792 contain the contact's street address. 794 - A element that contains the contact's city. 796 - An OPTIONAL element that contains the contact's 797 state or province. 799 - An OPTIONAL element that contains the contact's 800 postal code. 802 - A element that contains the contact's country 803 code. 805 - An OPTIONAL element that contains the contact's 806 voice telephone number. 808 - An OPTIONAL element that contains the contact's 809 facsimile telephone number. 811 - A element that contains the contact's email 812 address. 814 - A element that contains authorization 815 information to be associated with the contact object. This 816 mapping includes a password-based authentication mechanism, but 817 the schema allows new mechanisms to be defined in new schemas. 819 - An OPTIONAL element that allows a client to 820 identify elements that require exceptional server operator 821 handling to allow or restrict disclosure to third parties. See 822 Section 2.9 for a description of the child elements contained 823 within the element. 825 Example command: 827 C: 828 C: 829 C: 830 C: 831 C: 833 C: sh8013 834 C: 835 C: John Doe 836 C: Example Inc. 837 C: 838 C: 123 Example Dr. 839 C: Suite 100 840 C: Dulles 841 C: VA 842 C: 20166-6503 843 C: US 844 C: 845 C: 846 C: +1.7035555555 847 C: +1.7035555556 848 C: jdoe@example.com 849 C: 850 C: 2fooBAR 851 C: 852 C: 853 C: 854 C: 855 C: 856 C: 857 C: 858 C: ABC-12345 859 C: 860 C: 862 When a command has been processed successfully, the EPP 863 element MUST contain a child element that 864 identifies the contact namespace. The element 865 contains the following child elements: 867 - A element that contains the server-unique identifier 868 for the created contact. 870 - A element that contains the date and time of 871 contact object creation. 873 Example response: 875 S: 876 S: 877 S: 878 S: 879 S: Command completed successfully 880 S: 881 S: 882 S: 884 S: sh8013 885 S: 1999-04-03T22:00:00.0Z 886 S: 887 S: 888 S: 889 S: ABC-12345 890 S: 54321-XYZ 891 S: 892 S: 893 S: 895 An EPP error response MUST be returned if a command cannot 896 be processed for any reason. 898 3.2.2. EPP Command 900 The EPP command provides a transform operation that allows a 901 client to delete a contact object. In addition to the standard EPP 902 command elements, the command MUST contain a element that identifies the contact namespace. The element MUST contain the following child element: 906 - A element that contains the server-unique identifier 907 of the contact object to be deleted. 909 A contact object SHOULD NOT be deleted if it is associated with other 910 known objects. An associated contact SHOULD NOT be deleted until 911 associations with other known objects have been broken. A server 912 SHOULD notify clients of object relationships when a command 913 is attempted and fails due to existing object relationships. 915 Example command: 917 C: 918 C: 919 C: 920 C: 921 C: 923 C: sh8013 924 C: 925 C: 926 C: ABC-12345 927 C: 928 C: 930 When a command has been processed successfully, a server 931 MUST respond with an EPP response with no element. 933 Example response: 935 S: 936 S: 937 S: 938 S: 939 S: Command completed successfully 940 S: 941 S: 942 S: ABC-12345 943 S: 54321-XYZ 944 S: 945 S: 946 S: 948 An EPP error response MUST be returned if a command cannot 949 be processed for any reason. 951 3.2.3. EPP Command 953 Renewal semantics do not apply to contact objects, so there is no 954 mapping defined for the EPP command. 956 3.2.4. EPP Command 958 The EPP command provides a transform operation that allows 959 a client to manage requests to transfer the sponsorship of a contact 960 object. In addition to the standard EPP command elements, the 961 command MUST contain a element that 962 identifies the contact namespace. The element 963 contains the following child elements: 965 - A element that contains the server-unique identifier 966 of the contact object for which a transfer request is to be 967 created, approved, rejected, or cancelled. 969 - A element that contains authorization 970 information associated with the contact object. 972 Every EPP command MUST contain an "op" attribute that 973 identifies the transfer operation to be performed as defined in 974 [I-D.hollenbeck-rfc4930bis]. 976 Example request command: 978 C: 979 C: 980 C: 981 C: 982 C: 984 C: sh8013 985 C: 986 C: 2fooBAR 987 C: 988 C: 989 C: 990 C: ABC-12345 991 C: 992 C: 994 When a command has been processed successfully, the EPP 995 element MUST contain a child element that 996 identifies the contact namespace. The element 997 contains the same child elements defined for a query 998 response. 1000 Example response: 1002 S: 1003 S: 1004 S: 1005 S: 1006 S: Command completed successfully; action pending 1007 S: 1008 S: 1009 S: 1011 S: sh8013 1012 S: pending 1013 S: ClientX 1014 S: 2000-06-08T22:00:00.0Z 1015 S: ClientY 1016 S: 2000-06-13T22:00:00.0Z 1017 S: 1018 S: 1019 S: 1020 S: ABC-12345 1021 S: 54322-XYZ 1022 S: 1023 S: 1024 S: 1026 An EPP error response MUST be returned if a command cannot 1027 be processed for any reason. 1029 3.2.5. EPP Command 1031 The EPP command provides a transform operation that allows a 1032 client to modify the attributes of a contact object. In addition to 1033 the standard EPP command elements, the command MUST contain 1034 a element that identifies the contact namespace. 1035 The element contains the following child elements: 1037 - A element that contains the server-unique identifier 1038 of the contact object to be updated. 1040 - An OPTIONAL element that contains attribute values 1041 to be added to the object. 1043 - An OPTIONAL element that contains attribute values 1044 to be removed from the object. 1046 - An OPTIONAL element that contains object attribute 1047 values to be changed. 1049 At least one , , or element 1050 MUST be provided if the command is not being extended. All of these 1051 elements MAY be omitted if an extension is present. The 1052 and elements contain the following child 1053 elements: 1055 - One or more elements that contain status values 1056 to be associated with or removed from the object. When specifying 1057 a value to be removed, only the attribute value is significant; 1058 element text is not required to match a value for removal. 1060 A element contains the following OPTIONAL child 1061 elements. At least one child element MUST be present: 1063 - One or two elements that contain postal 1064 address information. Two elements are provided so that address 1065 information can be provided in both internationalized and 1066 localized forms; a "type" attribute is used to identify the two 1067 forms. If an internationalized form (type="int") is provided, 1068 element content MUST be represented in a subset of UTF-8 that can 1069 be represented in the 7-bit US-ASCII character set. If a 1070 localized form (type="loc") is provided, element content MAY be 1071 represented in unrestricted UTF-8. The 1072 element contains the following OPTIONAL child elements: 1074 - A element that contains the name of the 1075 individual or role represented by the contact. 1077 - A element that contains the name of the 1078 organization with which the contact is affiliated. 1080 - A element that contains address information 1081 associated with the contact. A element contains 1082 the following child elements: 1084 - One, two, or three OPTIONAL elements that 1085 contain the contact's street address. 1087 - A element that contains the contact's city. 1089 - An OPTIONAL element that contains the contact's 1090 state or province. 1092 - An OPTIONAL element that contains the contact's 1093 postal code. 1095 - A element that contains the contact's country 1096 code. 1098 - A element that contains the contact's voice 1099 telephone number. 1101 - A element that contains the contact's facsimile 1102 telephone number. 1104 - A element that contains the contact's email 1105 address. 1107 - A element that contains authorization 1108 information associated with the contact object. This mapping 1109 includes a password-based authentication mechanism, but the schema 1110 allows new mechanisms to be defined in new schemas. 1112 - A element that allows a client to identify 1113 elements that require exceptional server operator handling to 1114 allow or restrict disclosure to third parties. See Section 2.9 1115 for a description of the child elements contained within the 1116 element. 1118 Example command: 1120 C: 1121 C: 1122 C: 1123 C: 1124 C: 1126 C: sh8013 1127 C: 1128 C: 1129 C: 1130 C: 1131 C: 1132 C: 1133 C: 1134 C: 124 Example Dr. 1135 C: Suite 200 1136 C: Dulles 1137 C: VA 1138 C: 20166-6503 1139 C: US 1140 C: 1141 C: 1142 C: +1.7034444444 1143 C: 1144 C: 1145 C: 2fooBAR 1146 C: 1147 C: 1148 C: 1149 C: 1150 C: 1151 C: 1152 C: 1153 C: 1154 C: ABC-12345 1155 C: 1156 C: 1158 When an command has been processed successfully, a server 1159 MUST respond with an EPP response with no element. 1161 Example response: 1163 S: 1164 S: 1165 S: 1166 S: 1167 S: Command completed successfully 1168 S: 1169 S: 1170 S: ABC-12345 1171 S: 54321-XYZ 1172 S: 1173 S: 1174 S: 1176 An EPP error response MUST be returned if an command cannot 1177 be processed for any reason. 1179 3.3. Offline Review of Requested Actions 1181 Commands are processed by a server in the order they are received 1182 from a client. Though an immediate response confirming receipt and 1183 processing of the command is produced by the server, a server 1184 operator MAY perform an offline review of requested transform 1185 commands before completing the requested action. In such situations, 1186 the response from the server MUST clearly note that the transform 1187 command has been received and processed, but the requested action is 1188 pending. The status of the corresponding object MUST clearly reflect 1189 processing of the pending action. The server MUST notify the client 1190 when offline processing of the action has been completed. 1192 Examples describing a command that requires offline review 1193 are included here. Note the result code and message returned in 1194 response to the command. 1196 S: 1197 S: 1198 S: 1199 S: 1200 S: Command completed successfully; action pending 1201 S: 1202 S: 1203 S: 1205 S: sh8013 1206 S: 1999-04-03T22:00:00.0Z 1207 S: 1208 S: 1209 S: 1210 S: ABC-12345 1211 S: 54321-XYZ 1212 S: 1213 S: 1214 S: 1216 The status of the contact object after returning this response MUST 1217 include "pendingCreate". The server operator reviews the request 1218 offline, and informs the client of the outcome of the review either 1219 by queuing a service message for retrieval via the command or 1220 by using an out-of-band mechanism to inform the client of the 1221 request. 1223 The service message MUST contain text in the , , 1224 element that describes the notification. In addition, the EPP 1225 element MUST contain a child element that 1226 identifies the contact namespace. The element 1227 contains the following child elements: 1229 - A element that contains the server-unique identifier 1230 of the contact object. The element contains a 1231 REQUIRED "paResult" attribute. A positive boolean value indicates 1232 that the request has been approved and completed. A negative 1233 boolean value indicates that the request has been denied and the 1234 requested action has not been taken. 1236 - A element that contains the client transaction 1237 identifier and server transaction identifier returned with the 1238 original response to process the command. The client transaction 1239 identifier is OPTIONAL and will only be returned if the client 1240 provided an identifier with the original command. 1242 - A element that contains the date and time 1243 describing when review of the requested action was completed. 1245 Example "review completed" service message: 1247 S: 1248 S: 1249 S: 1250 S: 1251 S: Command completed successfully; ack to dequeue 1252 S: 1253 S: 1254 S: 1999-04-04T22:01:00.0Z 1255 S: Pending action completed successfully. 1256 S: 1257 S: 1258 S: 1260 S: sh8013 1261 S: 1262 S: ABC-12345 1263 S: 54321-XYZ 1264 S: 1265 S: 1999-04-04T22:00:00.0Z 1266 S: 1267 S: 1268 S: 1269 S: BCD-23456 1270 S: 65432-WXY 1271 S: 1272 S: 1273 S: 1275 4. Formal Syntax 1277 An EPP object mapping is specified in XML Schema notation. The 1278 formal syntax presented here is a complete schema representation of 1279 the object mapping suitable for automated validation of EPP XML 1280 instances. The BEGIN and END tags are not part of the schema; they 1281 are used to note the beginning and ending of the schema for URI 1282 registration purposes. 1284 BEGIN 1285 1287 1294 1297 1298 1300 1301 1302 Extensible Provisioning Protocol v1.0 1303 contact provisioning schema. 1304 1305 1307 1310 1311 1312 1313 1314 1315 1317 1320 1321 1322 1323 1324 1326 1327 1328 1329 1330 1331 1332 1334 1335 1336 1337 1339 1340 1342 1343 1344 1345 1346 1348 1349 1350 1351 1352 1353 1355 1356 1357 1358 1359 1361 1364 1365 1366 1367 1369 1371 1373 1374 1375 1377 1378 1380 1381 1382 1383 1385 1386 1387 1389 1391 1392 1393 1394 1395 1396 1398 1399 1400 1402 1403 1405 1407 1408 1409 1411 1412 1413 1414 1415 1416 1418 1419 1420 1422 1424 1426 1427 1428 1429 1430 1431 1433 1434 1436 1438 1441 1442 1443 1444 1445 1447 1450 1451 1452 1454 1455 1457 1460 1461 1462 1463 1465 1466 1468 1471 1472 1473 1474 1476 1478 1480 1481 1483 1486 1487 1488 1490 1491 1493 1496 1497 1498 1500 1502 1504 1506 1508 1510 1511 1513 1514 1515 1517 1519 1521 1522 1524 1526 1529 1530 1531 1532 1533 1535 1538 1539 1540 1542 1543 1545 1546 1547 1548 1550 1551 1553 1554 1555 1556 1558 1559 1560 1562 1565 1566 1567 1568 1569 1570 1572 1575 1576 1577 1578 1579 1581 1583 1585 1587 1588 1589 1590 1591 1593 1595 1597 1599 1601 1602 1604 1608 1609 1610 1611 1613 1615 1616 1617 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1636 1639 1640 1641 1642 1643 1644 1645 1647 1648 1649 1650 1652 1653 1654 1656 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1670 1673 1674 END 1676 5. Internationalization Considerations 1678 EPP is represented in XML, which provides native support for encoding 1679 information using the Unicode character set and its more compact 1680 representations, including UTF-8. Conformant XML processors 1681 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 1682 provisions to identify and use other character encodings through use 1683 of an "encoding" attribute in an declaration, use of UTF-8 is 1684 REQUIRED with this specification. 1686 All date-time values presented via EPP MUST be expressed in Universal 1687 Coordinated Time using the Gregorian calendar. The XML Schema allows 1688 use of time zone identifiers to indicate offsets from the zero 1689 meridian, but this option MUST NOT be used with EPP. The extended 1690 date-time form using upper case "T" and "Z" characters defined in 1691 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1692 values as the XML Schema does not support truncated date-time forms 1693 or lower case "T" and "Z" characters. 1695 Humans, organizations, and other entities often need to represent 1696 social information in both a commonly understood character set and a 1697 locally optimized character set. This specification provides 1698 features allowing representation of social information in both a 1699 subset of UTF-8 for broad readability and unrestricted UTF-8 for 1700 local optimization. 1702 6. IANA Considerations 1704 This document uses URNs to describe XML namespaces and XML schemas 1705 conforming to a registry mechanism described in [RFC3688]. Two URI 1706 assignments have been registered by the IANA. 1708 Registration request for the contact namespace: 1710 URI: urn:ietf:params:xml:ns:contact-1.0 1712 Registrant Contact: See the "Author's Address" section of this 1713 document. 1715 XML: None. Namespace URIs do not represent an XML specification. 1717 Registration request for the contact XML schema: 1719 URI: urn:ietf:params:xml:schema:contact-1.0 1721 Registrant Contact: See the "Author's Address" section of this 1722 document. 1724 XML: See the "Formal Syntax" section of this document. 1726 7. Security Considerations 1728 Authorization information as described in Section 2.8 is REQUIRED to 1729 create a contact object. This information is used in some query and 1730 transfer operations as an additional means of determining client 1731 authorization to perform the command. Failure to protect 1732 authorization information from inadvertent disclosure can result in 1733 unauthorized transfer operations and unauthorized information 1734 release. Both client and server MUST ensure that authorization 1735 information is stored and exchanged with high-grade encryption 1736 mechanisms to provide privacy services. 1738 The object mapping described in this document does not provide any 1739 other security services or introduce any additional considerations 1740 beyond those described by [I-D.hollenbeck-rfc4930bis] and protocol 1741 layers used by EPP. 1743 8. Acknowledgements 1745 This document was originally written as an individual submission 1746 Internet-Draft. The PROVREG working group later adopted it as a 1747 working group document and provided many invaluable comments and 1748 suggested improvements. The author wishes to acknowledge the efforts 1749 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1750 editorial contributions. 1752 Specific suggestions that have been incorporated into this document 1753 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1754 Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1755 El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael 1756 Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson. 1758 9. References 1760 9.1. Normative References 1762 [I-D.hollenbeck-rfc4930bis] 1763 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1764 draft-hollenbeck-rfc4930bis-00 (work in progress), 1765 April 2009. 1767 [ISO.3166.1997] 1768 International Organization for Standardization, "Codes for 1769 the representation of names of countries and their 1770 subdivisions -- Part 1: Country codes", ISO Standard 3166, 1771 October 1997. 1773 [ITU.E164.2005] 1774 International Telecommunication Union, "The international 1775 public telecommunication numbering plan", ITU- 1776 T Recommendation E.164, February 2005. 1778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1779 Requirement Levels", BCP 14, RFC 2119, March 1997. 1781 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1782 10646", STD 63, RFC 3629, November 2003. 1784 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1785 January 2004. 1787 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1788 October 2008. 1790 [W3C.REC-xml-20040204] 1791 Maler, E., Sperberg-McQueen, C., Paoli, J., Yergeau, F., 1792 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1793 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1794 20040204, February 2004, 1795 . 1797 [W3C.REC-xmlschema-1-20041028] 1798 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 1799 "XML Schema Part 1: Structures Second Edition", World Wide 1800 Web Consortium Recommendation REC-xmlschema-1-20041028, 1801 October 2004, 1802 . 1804 [W3C.REC-xmlschema-2-20041028] 1805 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1806 Second Edition", World Wide Web Consortium 1807 Recommendation REC-xmlschema-2-20041028, October 2004, 1808 . 1810 9.2. Informative References 1812 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1813 10646", RFC 2781, February 2000. 1815 [RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1816 Contact Mapping", RFC 4933, May 2007. 1818 Appendix A. Changes from RFC 4933 1820 1. Changed "This document obsoletes RFC 3733" to "This document is 1821 intended to obsolete RFC 4933". 1822 2. Replaced references to RFC 0822 with references to 5322. 1823 3. Replaced references to RFC 3733 with references to 4933. 1824 4. Replaced references to RFC 4930 with references to 4930bis. 1826 Author's Address 1828 Scott Hollenbeck 1829 VeriSign, Inc. 1830 21345 Ridgetop Circle 1831 Dulles, VA 20166-6503 1832 US 1834 EMail: shollenbeck@verisign.com