idnits 2.17.1 draft-ietf-regext-org-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 10, 2018) is 2025 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Zhou 3 Internet-Draft CNNIC 4 Intended status: Standards Track N. Kong 5 Expires: April 13, 2019 Consultant 6 G. Zhou 7 J. Yao 8 CNNIC 9 J. Gould 10 Verisign, Inc. 11 October 10, 2018 13 Extensible Provisioning Protocol (EPP) Organization Mapping 14 draft-ietf-regext-org-11 16 Abstract 18 This document describes an Extensible Provisioning Protocol (EPP) 19 mapping for provisioning and management of organization objects 20 stored in a shared central repository. Specified in Extensible 21 Markup Language (XML), this extended mapping is applied to provide 22 additional features required for the provisioning of organizations. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 13, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 62 3.2. Organization Roles . . . . . . . . . . . . . . . . . . . 4 63 3.2.1. Role Type . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2.2. Role Status . . . . . . . . . . . . . . . . . . . . . 4 65 3.2.3. Role Identifier . . . . . . . . . . . . . . . . . . . 4 66 3.3. Contact and Client Identifiers . . . . . . . . . . . . . 5 67 3.4. Organization Status Values . . . . . . . . . . . . . . . 5 68 3.5. Role Status Values . . . . . . . . . . . . . . . . . . . 6 69 3.6. Parent Identifier . . . . . . . . . . . . . . . . . . . . 7 70 3.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.8. Dates and Times . . . . . . . . . . . . . . . . . . . . . 7 72 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 74 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 8 75 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 9 76 4.1.3. EPP Query Command . . . . . . . . . . . . 15 77 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 78 4.2.1. EPP Command . . . . . . . . . . . . . . . . 15 79 4.2.2. EPP Command . . . . . . . . . . . . . . . . 19 80 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 20 81 4.2.4. EPP Command . . . . . . . . . . . . . . . 20 82 4.2.5. EPP Command . . . . . . . . . . . . . . . . 21 83 4.3. Offline Review of Requested Actions . . . . . . . . . . . 25 84 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 85 6. Internationalization Considerations . . . . . . . . . . . . . 36 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 87 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 36 88 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 37 89 7.3. Role Type Values Registry . . . . . . . . . . . . . . . . 37 90 7.3.1. Registration Template . . . . . . . . . . . . . . . . 37 91 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 37 92 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 38 93 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 39 94 8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 39 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 96 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 40 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 99 11.2. Informative References . . . . . . . . . . . . . . . . . 41 100 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 103 1. Introduction 105 There are many entities, such as registrars, resellers, DNS service 106 operators, or privacy proxies involved in the domain registration 107 business. These kind of entities have not been formally defined as 108 an object in EPP which will be specified as "organization" in this 109 document. 111 This document describes an organization object mapping for version 112 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This 113 mapping is specified using the XML 1.0 as described in 114 [W3C.REC-xml-20040204] and XML Schema notation as described in 115 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 117 2. Conventions Used in This Document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in BCP 14 122 [RFC2119][RFC8174] when, and only when, they appear in all capitals, 123 as shown here. 125 In examples, "C:" represents lines sent by a protocol client and "S:" 126 represents lines returned by a protocol server. Indentation and 127 white space in examples are provided only to illustrate element 128 relationships and are not a required feature of this specification. 130 XML is case sensitive. Unless stated otherwise, XML specifications 131 and examples provided in this document MUST be interpreted in the 132 character case presented to develop a conforming implementation. 134 The XML namespace prefix "org" is used, but implementations MUST NOT 135 depend on it and instead employ a proper namespace-aware XML parser 136 and serializer to interpret and output the XML documents. 138 3. Object Attributes 140 An EPP organization object has attributes and associated values that 141 can be viewed and modified by the sponsoring client or the server. 142 This section describes each attribute type in detail. The formal 143 syntax for the attribute values described here can be found in the 144 "Formal Syntax" section of this document and in the appropriate 145 normative references. 147 3.1. Organization Identifier 149 All EPP organizations are identified by a server-unique identifier. 150 Organization identifiers are character strings with a specified 151 minimum length, a specified maximum length, and a specified format. 152 Organization identifiers use the "clIDType" client identifier syntax 153 described in [RFC5730]. Its corresponding element is . 155 3.2. Organization Roles 157 The organization roles are used to represent the relationship an 158 organization could have. Its corresponding element is . 159 An organization object MUST always have at least one associated role. 160 Roles can be set only by the client that sponsors an organization 161 object. A client can change the role of an organization object using 162 the EPP command. 164 3.2.1. Role Type 166 An organization role MUST have a type which supports a list of 167 values. An organization could have multiple roles with a different 168 role type. See Section 7.3 for a list of values. Its corresponding 169 element is . 171 3.2.2. Role Status 173 A role of an organization object MAY have its own statuses. Its 174 corresponding element is . The values of the role status 175 are defined in Section 3.5. 177 3.2.3. Role Identifier 179 A role MAY have a third-party-assigned identifier such as the IANA ID 180 for registrars. Its corresponding element is . 182 Example of organization role identifier: 184 185 registrar 186 ok 187 linked 188 1362 189 191 3.3. Contact and Client Identifiers 193 All EPP contacts are identified by a server-unique identifier. 194 Contact identifiers are character strings with a specified minimum 195 length, a specified maximum length, and a specified format. Contact 196 identifiers use the "clIDType" client identifier syntax described in 197 [RFC5730]. 199 3.4. Organization Status Values 201 An organization object MUST always have at least one associated 202 status value. 204 Status values that can be added or removed by a client are prefixed 205 with "client". Corresponding status values that can be added or 206 removed by a server are prefixed with "server". The "hold" and 207 "terminated" status values are server-managed when the organization 208 has no parent identifier [Section 3.6] and otherwise MAY be client- 209 managed based on server policy. 211 Status Value Descriptions: 213 o ok: This is the normal status value for an object that has no 214 pending operations or prohibitions. This value is set and removed 215 by the server as other status values are added or removed. 217 o hold: Organization transform commands and new links MUST be 218 rejected. 220 o terminated: The organization which has been terminated MUST NOT be 221 linked. Organization transform commands and new links MUST be 222 rejected. 224 o linked: The organization object has at least one active 225 association with another object. The "linked" status is not 226 explicitly set by the client. Servers should provide services to 227 determine existing object associations. 229 o clientLinkProhibited, serverLinkProhibited: Requests to add new 230 links to the organization MUST be rejected. 232 o clientUpdateProhibited, serverUpdateProhibited: Requests to update 233 the object (other than to remove this status) MUST be rejected. 235 o clientDeleteProhibited, serverDeleteProhibited: Requests to delete 236 the object MUST be rejected. 238 o pendingCreate, pendingUpdate, pendingDelete: A transform command 239 has been processed for the object, but the action has not been 240 completed by the server. Server operators can delay action 241 completion for a variety of reasons, such as to allow for human 242 review or third-party action. A transform command that is 243 processed, but whose requested action is pending, is noted with 244 response code 1001. 246 "pendingCreate", "ok", "hold", and "terminated" are mutually 247 exclusive statuses. Organization MUST have only one of these 248 statuses set. 250 "ok" status MAY only be combined with "linked" status. 252 A client or server MAY combine "linked" with either 253 "clientLinkProhibited" or "serverLinkProhibited" if new links must be 254 prohibited. 256 "pendingDelete" status MUST NOT be combined with either 257 "clientDeleteProhibited" or "serverDeleteProhibited" status. 259 The pendingCreate, pendingDelete, and pendingUpdate status values 260 MUST NOT be combined with each other. 262 3.5. Role Status Values 264 A role SHOULD have at least one associated status value. Valid 265 values include "ok", "linked", "clientLinkProhibited", and 266 "serverLinkProhibited". 268 Status Value Descriptions: 270 o ok: This is the normal status value for an role that has no 271 pending operations or prohibitions. This value is set and removed 272 by the server as other status values are added or removed. 274 o linked: The role of an organization object has at least one active 275 association with another object. The "linked" status is not 276 explicitly set by the client. Servers SHOULD provide services to 277 determine existing object associations. 279 o clientLinkProhibited, serverLinkProhibited: Requests to add new 280 links to the role MUST be rejected. 282 3.6. Parent Identifier 284 There can be more than one layer of organizations, such as a 285 reseller. The parent identifier, as defined with the 286 element, represents the parent organization identifier in a child 287 organization. 289 Take a reseller organization, for example, the parent identifier is 290 not defined for the top level reseller, namely the registrar of the 291 registry. An N-tier reseller has a parent reseller and at least one 292 child reseller. A reseller customer has a parent reseller and no 293 child resellers. 295 Loops MUST be prohibited. For example: if organization A has B as 296 its parent identifier, organization B should not have organization A 297 as its parent identifier. The same is true for larger loops 298 involving three or more organizations. 300 3.7. URL 302 The URL represents the organization web home page, as defined with 303 the element. 305 3.8. Dates and Times 307 Date and time attribute values MUST be represented in Universal 308 Coordinated Time (UTC) using the Gregorian calendar. The extended 309 date-time form using upper case "T" and "Z" characters defined in 310 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 311 values, as XML Schema does not support truncated date-time forms or 312 lower case "T" and "Z" characters. 314 4. EPP Command Mapping 316 A detailed description of the EPP syntax and semantics can be found 317 in the EPP core protocol specification [RFC5730]. The command 318 mappings described here are specifically for use in provisioning and 319 managing organization information via EPP. 321 4.1. EPP Query Commands 323 EPP provides two commands to retrieve organization information: 324 to determine if an organization object can be provisioned 325 within a repository, and to retrieve detailed information 326 associated with an organization object. This document does not 327 define a mapping for the EPP command to retrieve 328 organization-object transfer status information. 330 4.1.1. EPP Command 332 The EPP command is used to determine if an object can be 333 provisioned within a repository. It provides a hint that allows a 334 client to anticipate the success or failure of provisioning an object 335 using the command, as object-provisioning requirements are 336 ultimately a matter of server policy. 338 In addition to the standard EPP command elements, the command 339 MUST contain an element. This element or its ancestor 340 element MUST identify the organization namespace. The 341 ement contains the following child elements: 343 o One or more elements that contain the server-unique 344 identifier of the organization objects to be queried. 346 Example command: 348 C: 349 C: 350 C: 351 C: 352 C: 354 C: res1523 355 C: re1523 356 C: 1523res 357 C: 358 C: 359 C: ABC-12345 360 C: 361 C: 363 When a command has been processed successfully, the EPP 364 element MUST contain a child element. This 365 element or its ancestor element MUST identify the organization 366 namespace. The element contains one or more 367 elements that contain the following child elements: 369 o An element that identifies the queried object. This 370 element MUST contain an "avail" attribute whose value indicates 371 object availability (can it be provisioned or not) at the moment 372 the command was completed. A value of "1" or "true" means 373 that the object can be provisioned. A value of "0" or "false" 374 means that the object cannot be provisioned. 376 o An OPTIONAL element that may be provided when an 377 object cannot be provisioned. If present, this element contains 378 server-specific text to help explain why the object cannot be 379 provisioned. This text MUST be represented in the response 380 language previously negotiated with the client; an OPTIONAL "lang" 381 attribute MAY be present to identify the language if the 382 negotiated value is something other than the default value of 383 "en"(English). 385 Example response: 387 S: 388 S: 389 S: 390 S: 391 S: Command completed successfully 392 S: 393 S: 394 S: 396 S: 397 S: res1523 398 S: 399 S: 400 S: re1523 401 S: In use 402 S: 403 S: 404 S: 1523res 405 S: 406 S: 407 S: 408 S: 409 S: ABC-12345 410 S: 54322-XYZ 411 S: 412 S: 413 S: 415 An EPP error response MUST be returned if a command cannot be 416 processed for any reason. 418 4.1.2. EPP Command 420 The EPP command is used to retrieve information associated 421 with an organization object. It is up to the server policy to decide 422 what attributes will be returned of an organization object. In 423 addition to the standard EPP command elements, the command 424 MUST contain a element. This element or its ancestor 425 element MUST identify the organization namespace. The 426 element contains the following child elements: 428 o An element that contains the server-unique identifier of 429 the organization object to be queried. 431 Example command: 433 C: 434 C: 435 C: 436 C: 437 C: 439 C: res1523 440 C: 441 C: 442 C: ABC-12345 443 C: 444 C: 446 When an command has been processed successfully, the EPP 447 element MUST contain a child element. This 448 element or its ancestor element MUST identify the organization 449 namespace. The element contains the following child 450 elements: 452 o An element that contains the server-unique identifier of 453 the organization object, as defined in Section 3.1. 455 o An element that contains the Repository Object 456 IDentifier assigned to the organization object when the object was 457 created. 459 o One or more elements that contain the role type, role 460 statuses and optional role id of the organization. 462 * An element that contains the type of the 463 organization, as defined in Section 3.2. 465 * One or more elements that contain the role 466 statuses. The values of the role status are defined in 467 Section 3.5. 469 * An OPTIONAL element that contains a third-party- 470 assigned identifier, such as IANA ID for registrars, as defined 471 in Section 3.2.3. 473 o One or more elements that contain the operational 474 status of the organization, as defined in Section 3.4. 476 o An OPTIONAL element that contains the identifier of 477 the parent object, as defined in Section 3.6. 479 o Zero to two elements that contain postal-address 480 information. Two elements are provided so that address 481 information can be provided in both internationalized and 482 localized forms; a "type" attribute is used to identify the two 483 forms. If an internationalized form (type="int") is provided, 484 element content MUST be represented in a subset of Unicode in the 485 range U+0020 - U+007E. If a localized form (type="loc") is 486 provided, element content MAY be represented in unrestricted UTF- 487 8. The element contains the following child 488 elements: 490 * An element that contains the name of the 491 organization. 493 * An OPTIONAL element that contains address 494 information associated with the organization. A 495 element contains the following child elements: 497 + One, two, or three OPTIONAL elements that 498 contain the organization's street address. 500 + An element that contains the organization's city. 502 + An OPTIONAL element that contains the 503 organization's state or province. 505 + An OPTIONAL element that contains the 506 organization's postal code. 508 + An element that contains the organization's country 509 code. 511 o An OPTIONAL element that contains the organization's 512 voice telephone number. The detailed format of this element is 513 described in Section 2.5 of [RFC5733]. 515 o An OPTIONAL element that contains the organization's 516 facsimile telephone number. 518 o An OPTIONAL element that contains the organization's 519 email address. 521 o An OPTIONAL element that contains the URL to the website 522 of the organization. 524 o Zero or more OPTIONAL elements that contain 525 identifiers for the contact objects to be associated with the 526 organization object. Contact object identifiers MUST be known to 527 the server before the contact object can be associated with the 528 organization object. The required "type" is used to represent 529 contact types. The type values include "admin", "tech", 530 "billing", "abuse", and "custom". The OPTIONAL "typeName" 531 attribute is used to define the name of a "custom" type. 533 o An OPTIONAL element that contains the organization 534 identifier of the sponsoring client. There is no 535 element if the organization is managed by the registry. 537 o An element that contains the identifier of the client 538 that created the organization object. 540 o An element that contains the date and time of 541 organization object creation. 543 o An element that contains the identifier of the client 544 that last updated the organization object. This element MUST NOT 545 be present if the organization has never been modified. 547 o An element that contains the date and time of the 548 most recent organization object modification. This element MUST 549 NOT be present if the organization object has never been modified. 551 Example response for "Example Registrar Inc." organization 552 organization object with identifier "registrar1362": 554 S: 555 S: 556 S: 557 S: 558 S: Command completed successfully 559 S: 560 S: 561 S: 563 S: registrar1362 564 S: registrar1362-REP 565 S: 566 S: registrar 567 S: ok 568 S: linked 569 S: 1362 570 S: 571 S: ok 572 S: 573 S: Example Registrar Inc. 574 S: 575 S: 123 Example Dr. 576 S: Suite 100 577 S: Dulles 578 S: VA 579 S: 20166-6503 580 S: US 581 S: 582 S: 583 S: +1.7035555555 584 S: +1.7035555556 585 S: contact@organization.example 586 S: https://organization.example 587 S: sh8013 588 S: sh8013 589 S: sh8013 591 S: ClientX 592 S: 1999-04-03T22:00:00.0Z 593 S: ClientX 594 S: 1999-12-03T09:00:00.0Z 595 S: 596 S: 597 S: 598 S: ABC-12345 599 S: 54322-XYZ 600 S: 601 S: 602 S: 604 Example response for "Example Reseller Inc." organization 605 object of reseller type managed by identifier "registrar1362": 607 S: 608 S: 609 S: 610 S: 611 S: Command completed successfully 612 S: 613 S: 614 S: 616 S: reseller1523 617 S: reseller1523-REP 618 S: 619 S: reseller 620 S: ok 621 S: linked 622 S: 623 S: ok 624 S: registrar1362 625 S: 626 S: Example Reseller Inc. 627 S: 628 S: 123 Example Dr. 629 S: Suite 100 630 S: Dulles 631 S: VA 632 S: 20166-6503 633 S: US 634 S: 635 S: 636 S: +1.7035555556 637 S: https://organization.example 638 S: sh8013 639 S: 1362 640 S: ClientX 641 S: 1999-04-03T22:00:00.0Z 642 S: ClientX 643 S: 1999-12-03T09:00:00.0Z 644 S: 645 S: 646 S: 647 S: ABC-12345 648 S: 54322-XYZ 649 S: 650 S: 651 S: 653 An EPP error response MUST be returned if an command cannot be 654 processed for any reason. 656 4.1.3. EPP Query Command 658 The transfer semantics does not apply to organization object. No EPP 659 query command is defined in this document. 661 4.2. EPP Transform Commands 663 This document provides three commands to transform organization 664 object information: to create an instance of an organization 665 object, to delete an instance of an organization object, and 666 to change information associated with an organization 667 object. This document does not define a mapping for the EPP 668 and command. 670 Transform commands are typically processed and completed in real 671 time. Server operators MAY receive and process transform commands 672 but defer completing the requested action if human or third-party 673 review is required before the requested action can be completed. In 674 such situations, the server MUST return a 1001 response code to the 675 client to note that the command has been received and processed but 676 that the requested action is pending. The server MUST also manage 677 the status of the object that is the subject of the command to 678 reflect the initiation and completion of the requested action. Once 679 the action has been completed, the client MUST be notified using a 680 service message that the action has been completed and that the 681 status of the object has changed. Other notification methods MAY be 682 used in addition to the required service message. 684 4.2.1. EPP Command 686 The EPP command provides a transform operation that allows a 687 client to create an organization object. In addition to the standard 688 EPP command elements, the command MUST contain a 689 element. This element or its ancestor element MUST 690 identify the organization namespace. The element 691 contains the following child elements: 693 o An element that contains the desired server-unique 694 identifier for the organization to be created, as defined in 695 Section 3.1. 697 o One or more elements that contain the role type, role 698 statuses and optional role id of the organization. 700 * An element that contains the type of the 701 organization, as defined in Section 3.2. 703 * Zero or more elements that contain the role 704 statuses. The values of the role status are defined in 705 Section 3.5. 707 * An OPTIONAL element that contains a third-party- 708 assigned identifier, such as IANA ID for registrars, as defined 709 in Section 3.2.3. 711 o Zero of more element that contain the operational 712 status of the organization, as defined in Section 3.4. 714 o An OPTIONAL element that contains the identifier of 715 the parent object, as defined in Section 3.6. 717 o Zero to two elements that contain postal-address 718 information. Two elements are provided so that address 719 information can be provided in both internationalized and 720 localized forms; a "type" attribute is used to identify the two 721 forms. If an internationalized form (type="int") is provided, 722 element content MUST be represented in a subset of Unicode in the 723 range U+0020 - U+007E. If a localized form (type="loc") is 724 provided, element content MAY be represented in unrestricted UTF- 725 8. The element contains the following child 726 elements: 728 * An element that contains the name of the 729 organization. 731 * An OPTIONAL element that contains address 732 information associated with the organization. A 733 element contains the following child elements: 735 + One, two, or three OPTIONAL elements that 736 contain the organization's street address. 738 + An element that contains the organization's city. 740 + An OPTIONAL element that contains the 741 organization's state or province. 743 + An OPTIONAL element that contains the 744 organization's postal code. 746 + An element that contains the organization's country 747 code. 749 o An OPTIONAL element that contains the organization's 750 voice telephone number. 752 o An OPTIONAL element that contains the organization's 753 facsimile telephone number. 755 o An OPTIONAL element that contains the organization's 756 email address. 758 o An OPTIONAL element that contains the URL to the website 759 of the organization. 761 o Zero or more OPTIONAL elements that contain 762 identifiers for the contact objects associated with the 763 organization object. 765 Example command: 767 C: 768 C: 769 C: 770 C: 771 C: 773 C: res1523 774 C: 775 C: reseller 776 C: 777 C: 1523res 778 C: 779 C: Example Organization Inc. 780 C: 781 C: 123 Example Dr. 782 C: Suite 100 783 C: Dulles 784 C: VA 785 C: 20166-6503 786 C: US 787 C: 788 C: 789 C: +1.7035555555 790 C: +1.7035555556 791 C: contact@organization.example 792 C: https://organization.example 793 C: sh8013 794 C: sh8013 795 C: 796 C: 797 C: ABC-12345 798 C: 799 C: 801 When a command has been processed successfully, the EPP 802 element MUST contain a child element. This 803 element or its ancestor element MUST identify the organization 804 namespace. The element contains the following child 805 elements: 807 o An element that contains the server-unique identifier for 808 the created organization, as defined in Section 3.1. 810 o An element that contains the date and time of 811 organization-object creation. 813 Example response: 815 S: 816 S: 817 S: 818 S: 819 S: Command completed successfully 820 S: 821 S: 822 S: 824 S: res1523 825 S: 1999-04-03T22:00:00.0Z 826 S: 827 S: 828 S: 829 S: ABC-12345 830 S: 54321-XYZ 831 S: 832 S: 833 S: 835 An EPP error response MUST be returned if a command cannot 836 be processed for any reason. 838 4.2.2. EPP Command 840 The EPP command provides a transform operation that allows a 841 client to delete an organization object. In addition to the standard 842 EPP command elements, the command MUST contain an 843 element. This element or its ancestor element MUST 844 identify the organization namespace. The element MUST 845 contain the following child element: 847 o An element that contains the server-unique identifier of 848 the organization object to be deleted, as defined in Section 3.1. 850 An organization object MUST NOT be deleted if it is associated with 851 other known objects. An associated organization MUST NOT be deleted 852 until associations with other known objects have been broken. A 853 server MUST notify clients that object relationships exist by sending 854 a 2305 error response code when a command is attempted and 855 fails due to existing object relationships. 857 Example command: 859 C: 860 C: 861 C: 862 C: 863 C: 865 C: res1523 866 C: 867 C: 868 C: ABC-12345 869 C: 870 C: 872 When a command has been processed successfully, a server 873 MUST respond with an EPP response with no element. 875 Example response: 877 S: 878 S: 879 S: 880 S: 881 S: Command completed successfully 882 S: 883 S: 884 S: ABC-12345 885 S: 54321-XYZ 886 S: 887 S: 888 S: 890 An EPP error response MUST be returned if a command cannot 891 be processed for any reason. 893 4.2.3. EPP Command 895 Renewal semantics do not apply to organization objects, so there is 896 no mapping defined for the EPP command. 898 4.2.4. EPP Command 900 Transfer semantics do not apply to organization objects, so there is 901 no mapping defined for the EPP command. 903 4.2.5. EPP Command 905 The EPP command provides a transform operation that allows a 906 client to modify the attributes of an organization object. In 907 addition to the standard EPP command elements, the command 908 MUST contain a element. This element or its ancestor 909 element MUST identify the organization namespace. The 910 element contains the following child elements: 912 o An element that contains the server-unique identifier of 913 the organization object to be updated, as defined in Section 3.1. 915 o An OPTIONAL element that contains attribute values to be 916 added to the object. 918 o An OPTIONAL element that contains attribute values to be 919 removed from the object. 921 o An OPTIONAL element that contains attribute values to be 922 changed. 924 At least one , or element MUST be 925 provided if the command is not being extended. All of these elements 926 MAY be omitted if an extension is present. The OPTIONAL 927 and elements contain the following child 928 elements: 930 o Zero or more elements that contain the identifiers 931 for contact objects to be associated with or removed from the 932 organization object. Contact object identifiers MUST be known to 933 the server before the contact object can be associated with the 934 organization object. 936 o Zero or more elements that contain the role type, role 937 statuses and optional role id of the organization. 939 * An element that contains the role type of the 940 organization, as defined in Section 3.2. The role type 941 uniquely identifies the role to update. 943 * Zero or more elements that contain the role 944 statuses. The values of the role status are defined in 945 Section 3.5. 947 * An OPTIONAL element that contains a third-party- 948 assigned identifier, such as IANA ID for registrars, as defined 949 in Section 3.2.3. 951 o Zero or more element that contain the operational 952 status of the organization. 954 An OPTIONAL element contains the following child elements, 955 where at least one child element MUST be present: 957 o An OPTIONAL element that contains the identifier of 958 the parent object. 960 o Zero to two elements that contain postal-address 961 information. Two elements are provided so that address 962 information can be provided in both internationalized and 963 localized forms; a "type" attribute is used to identify the two 964 forms. If an internationalized form (type="int") is provided, 965 element content MUST be represented in a subset of Unicode in the 966 range U+0020 - U+007E. If a localized form (type="loc") is 967 provided, element content MAY be represented in unrestricted UTF- 968 8. The change of the postal info is defined as a replacement of 969 that postal info element with the contents of the sub-elements 970 included in the update command. An empty element 971 is supported to allow a type of postal info to be removed. The 972 element contains the following child elements: 974 * An element that contains the name of the 975 organization. 977 * An OPTIONAL element that contains address 978 information associated with the organization. A 979 element contains the following child elements: 981 + One, two, or three OPTIONAL elements that 982 contain the organization's street address. 984 + An element that contains the organization's city. 986 + An OPTIONAL element that contains the 987 organization's state or province. 989 + An OPTIONAL element that contains the 990 organization's postal code. 992 + An element that contains the organization's country 993 code. 995 o An OPTIONAL element that contains the organization's 996 voice telephone number. 998 o An OPTIONAL element that contains the organization's 999 facsimile telephone number. 1001 o An OPTIONAL element that contains the organization's 1002 email address. 1004 o An OPTIONAL element that contains the URL to the website 1005 of the organization. 1007 Example command: 1009 C: 1010 C: 1011 C: 1012 C: 1013 C: 1015 C: res1523 1016 C: 1017 C: sh8013 1018 C: 1019 C: privacyproxy 1020 C: clientLinkProhibited 1021 C: 1022 C: clientLinkProhibited 1023 C: 1024 C: 1025 C: sh8014 1026 C: 1027 C: reseller 1028 C: 1029 C: 1030 C: 1031 C: 1032 C: 1033 C: 124 Example Dr. 1034 C: Suite 200 1035 C: Dulles 1036 C: VA 1037 C: 20166-6503 1038 C: US 1039 C: 1040 C: 1041 C: +1.7034444444 1042 C: 1043 C: 1044 C: 1045 C: 1046 C: ABC-12345 1047 C: 1048 C: 1050 When an command has been processed successfully, a server 1051 MUST respond with an EPP response with no element. 1053 Example response: 1055 S: 1056 S: 1057 S: 1058 S: 1059 S: Command completed successfully 1060 S: 1061 S: 1062 S: ABC-12345 1063 S: 54321-XYZ 1064 S: 1065 S: 1066 S: 1068 An EPP error response MUST be returned if an command cannot 1069 be processed for any reason. 1071 4.3. Offline Review of Requested Actions 1073 Commands are processed by a server in the order they are received 1074 from a client. Though an immediate response confirming receipt and 1075 processing of the command is produced by the server, a server 1076 operator MAY perform an offline review of requested transform 1077 commands before completing the requested action. In such situations, 1078 the response from the server MUST clearly note that the transform 1079 command has been received and processed, but the requested action is 1080 pending. The status of the corresponding object MUST clearly reflect 1081 processing of the pending action. The server MUST notify the client 1082 when offline processing of the action has been completed. 1084 Examples describing a command that requires offline review 1085 are included here. Note the result code and message returned in 1086 response to the command. 1088 S: 1089 S: 1090 S: 1091 S: 1092 S: Command completed successfully; 1093 S: action pending 1094 S: 1095 S: 1096 S: 1098 S: res1523 1099 S: 1999-04-03T22:00:00.0Z 1100 S: 1101 S: 1102 S: 1103 S: ABC-12345 1104 S: 54321-XYZ 1105 S: 1106 S: 1107 S: 1109 The status of the organization object after returning this response 1110 MUST include "pendingCreate". The server operator reviews the 1111 request offline, and informs the client of the outcome of the review 1112 either by queuing a service message for retrieval via the 1113 command or by using an out-of-band mechanism to inform the client of 1114 the request. 1116 The service message MUST contain text that describes the notification 1117 in the child element of the response element. In 1118 addition, the EPP element MUST contain a child 1119 element. This element or its ancestor element MUST 1120 identify the organization namespace. The element 1121 contains the following child elements: 1123 o An element that contains the server-unique identifier of 1124 the organization object. The element contains a REQUIRED 1125 "paResult" attribute. A positive boolean value indicates that the 1126 request has been approved and completed. A negative boolean value 1127 indicates that the request has been denied and the requested 1128 action has not been taken. 1130 o An element that contains the client transaction 1131 identifier and server transaction identifier returned with the 1132 original response to process the command. The client transaction 1133 identifier is OPTIONAL and will only be returned if the client 1134 provided an identifier with the original command. 1136 o An element that contains the date and time describing 1137 when review of the requested action was completed. 1139 Example "review completed" service message: 1141 S: 1142 S: 1143 S: 1144 S: 1145 S: Command completed successfully; 1146 S: ack to dequeue 1147 S: 1148 S: 1149 S: 1999-04-04T22:01:00.0Z 1150 S: Pending action completed successfully. 1151 S: 1152 S: 1153 S: 1155 S: res1523 1156 S: 1157 S: ABC-12345 1158 S: 54321-XYZ 1159 S: 1160 S: 1999-04-04T22:00:00.0Z 1161 S: 1162 S: 1163 S: 1164 S: BCD-23456 1165 S: 65432-WXY 1166 S: 1167 S: 1168 S: 1170 5. Formal Syntax 1172 An EPP object mapping is specified in XML Schema notation. The 1173 formal syntax presented here is a complete schema representation of 1174 the object mapping suitable for automated validation of EPP XML 1175 instances. The BEGIN and END tags are not part of the schema; they 1176 are used to note the beginning and ending of the schema for URI 1177 registration purposes. 1179 BEGIN 1180 1181 1188 1191 1192 1194 1195 1196 Extensible Provisioning Protocol v1.0 1197 organization provisioning schema. 1198 1199 1201 1204 1205 1206 1207 1208 1209 1211 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1230 1231 1233 1234 1235 1236 1237 1238 1239 1240 1242 1243 1244 1245 1247 1248 1249 1251 1252 1253 1255 1257 1258 1261 1263 1264 1265 1266 1268 1269 1270 1271 1273 1274 1275 1276 1277 1278 1279 1280 1281 1283 1284 1285 1286 1287 1288 1289 1291 1292 1293 1294 1295 1296 1298 1299 1300 1301 1302 1303 1305 1306 1307 1308 1309 1311 1312 1313 1314 1315 1317 1318 1319 1320 1321 1323 1324 1325 1327 1328 1330 1332 1333 1334 1336 1337 1338 1339 1340 1341 1343 1346 1347 1348 1349 1350 1352 1355 1356 1357 1359 1360 1362 1365 1366 1367 1368 1369 1370 1371 1373 1374 1375 1376 1378 1379 1380 1382 1385 1386 1387 1389 1390 1392 1395 1396 1397 1399 1401 1403 1405 1407 1409 1411 1413 1415 1418 1419 1421 1424 1425 1426 1428 1430 1432 1434 1435 1437 1440 1441 1442 1444 1446 1448 1449 1451 1454 1455 1456 1458 1461 1463 1465 1467 1469 1471 1473 1474 1475 1477 1479 1480 1482 1484 1487 1488 1489 1491 1494 1495 1496 1498 1499 1501 1502 1503 1504 1506 1507 1509 1510 1511 1512 1514 1515 1516 1518 1521 1522 1523 1525 1527 1529 1531 1533 1535 1537 1539 1541 1543 1545 1547 1549 1551 1553 1555 1556 1557 1560 1561 1562 1563 1564 1565 1567 1570 1571 END 1573 6. Internationalization Considerations 1575 EPP is represented in XML, which provides native support for encoding 1576 information using the Unicode character set and its more compact 1577 representations including UTF-8. Conformant XML processors recognize 1578 both UTF-8 [RFC3629] and UTF-16 [RFC2781]. Though XML includes 1579 provisions to identify and use other character encodings through use 1580 of an "encoding" attribute in an declaration, use of UTF-8 is 1581 RECOMMENDED. 1583 As an extension of the EPP organization object mapping, the elements 1584 and element content described in this document MUST inherit the 1585 internationalization conventions used to represent higher-layer 1586 domain and core protocol structures present in an XML instance that 1587 includes this extension. 1589 7. IANA Considerations 1591 7.1. XML Namespace 1593 This document uses URNs to describe XML namespaces and XML schemas 1594 conforming to a registry mechanism described in [RFC3688]. IANA is 1595 requested to assignment the following URI. 1597 Registration request for the organization namespace: 1599 URI: urn:ietf:params:xml:ns:epp:org-1.0 1601 Registrant Contact: IESG 1603 XML: None. Namespace URIs do not represent an XML specification. 1605 Registration request for the organization XML schema: 1607 URI: urn:ietf:params:xml:schema:epp:org-1.0 1609 Registrant Contact: IESG 1611 XML: See the "Formal Syntax" section of this document. 1613 7.2. EPP Extension Registry 1615 The EPP extension described in this document should be registered by 1616 the IANA in the EPP Extension Registry described in [RFC7451]. The 1617 details of the registration are as follows: 1619 Name of Extension: Extensible Provisioning Protocol (EPP) 1620 Organization Mapping 1622 Registrant Name and Email Address: IESG, iesg@ietf.org 1624 TLDs: Any 1626 IPR Disclosure: None 1628 Status: Active 1630 Notes: None 1632 7.3. Role Type Values Registry 1634 IANA has created a new category of protocol registry for values of 1635 the organization roles. The name of this registry is "EPP 1636 Organization Role Values". The registration policy for this registry 1637 is "Expert Review" [RFC8126]. 1639 7.3.1. Registration Template 1641 Value: the string value being registered. 1643 Description: Brief description of the organization role values. 1645 Registrant Name: For Standards Track RFCs, state "IESG". For others, 1646 give the name of the responsible party. 1648 Registrant Contact Information: an email address, postal address, or 1649 some other information to be used to contact the registrant. 1651 7.3.2. Initial Registry Contents 1653 Followings are the initial registry contents: 1655 Value: registrar 1657 Description: The entity object instance represents the authority 1658 responsible for the registration in the registry. 1660 Registrant Name: IESG 1661 Registrant Contact Information: iesg@ietf.org 1663 Value: reseller 1665 Description: The entity object instance represents a third party 1666 through which the registration was conducted (i.e., not the 1667 registry or registrar). 1669 Registrant Name: IESG 1671 Registrant Contact Information: iesg@ietf.org 1673 Value: privacyproxy 1675 Description: The entity object instance represents a third-party 1676 who could help to register a domain without exposing the 1677 registrants' private information. 1679 Registrant Name: IESG 1681 Registrant Contact Information: iesg@ietf.org 1683 Value: dns-operator 1685 Description: The entity object instance represents a third-party 1686 DNS operator that maintains the name servers and zone data on 1687 behalf of a registrant. 1689 Registrant Name: IESG 1691 Registrant Contact Information: iesg@ietf.org 1693 8. Implementation Status 1695 Note to RFC Editor: Please remove this section and the reference to 1696 [RFC7942] before publication. This section records the status of 1697 known implementations of the protocol defined by this specification 1698 at the time of posting of this Internet-Draft, and is based on a 1699 proposal described in [RFC7942]. The description of implementations 1700 in this section is intended to assist the IETF in its decision 1701 processes in progressing drafts to RFCs. Please note that the 1702 listing of any individual implementation here does not imply 1703 endorsement by the IETF. Furthermore, no effort has been spent to 1704 verify the information presented here that was supplied by IETF 1705 contributors. This is not intended as, and must not be construed to 1706 be, a catalog of available implementations or their features. 1707 Readers are advised to note that other implementations may exist. 1709 According to [RFC7942], "this will allow reviewers and working groups 1710 to assign due consideration to documents that have the benefit of 1711 running code, which may serve as evidence of valuable experimentation 1712 and feedback that have made the implemented protocols more mature. 1713 It is up to the individual working groups to use this information as 1714 they see fit". 1716 8.1. Verisign EPP SDK 1718 Organization: Verisign Inc. 1720 Name: Verisign EPP SDK 1722 Description: The Verisign EPP SDK includes both a full client 1723 implementation and a full server stub implementation of draft-ietf- 1724 regext-org. 1726 Level of maturity: Development 1728 Coverage: All aspects of the protocol are implemented. 1730 Licensing: GNU Lesser General Public License 1732 Contact: jgould@verisign.com 1734 URL: https://www.verisign.com/en_US/channel-resources/domain- 1735 registry-products/epp-sdks 1737 8.2. CNNIC Implementation 1739 Organization: CNNIC 1741 Name: EPP Organization Mapping 1743 Description: CNNIC is trying to update EPP organization mapping from 1744 previous reseller mapping according to this document. 1746 Level of maturity: Development 1748 Coverage: EPP organization mapping 1750 Contact: zhouguiqing@cnnic.cn 1752 9. Security Considerations 1754 The object mapping extension described in this document does not 1755 provide any other security services or introduce any additional 1756 considerations beyond those described by [RFC5730] or those caused by 1757 the protocol layers used by EPP. The security considerations 1758 described in these other specifications apply to this specification 1759 as well. 1761 10. Acknowledgment 1763 The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick 1764 Mevzek, Antoin Verschuren and Scott Hollenbeck for their careful 1765 review and valuable comments. 1767 11. References 1769 11.1. Normative References 1771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1772 Requirement Levels", BCP 14, RFC 2119, 1773 DOI 10.17487/RFC2119, March 1997, 1774 . 1776 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1777 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1778 2003, . 1780 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1781 DOI 10.17487/RFC3688, January 2004, 1782 . 1784 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1785 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1786 . 1788 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1789 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 1790 August 2009, . 1792 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1793 Code: The Implementation Status Section", BCP 205, 1794 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1795 . 1797 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1798 Writing an IANA Considerations Section in RFCs", BCP 26, 1799 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1800 . 1802 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1803 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1804 May 2017, . 1806 [W3C.REC-xml-20040204] 1807 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1808 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1809 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1810 20040204", February 2004, 1811 . 1813 [W3C.REC-xmlschema-1-20041028] 1814 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1815 ""XML Schema Part 1: Structures Second Edition", World 1816 Wide Web Consortium Recommendation REC-xmlschema- 1817 1-20041028", October 2004, 1818 . 1820 [W3C.REC-xmlschema-2-20041028] 1821 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1822 Second Edition", World Wide Web Consortium Recommendation 1823 REC-xmlschema-2-20041028", October 2004, 1824 . 1826 11.2. Informative References 1828 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1829 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, 1830 . 1832 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1833 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1834 February 2015, . 1836 Appendix A. Change Log 1838 Initial -00: Individual document submitted. 1840 -01: 1842 * Updated abstract text. 1844 * Added sentences to avoid loop of parent identifiers in section 1845 3.4. 1847 * Revised typos in section 3.6. 1849 * Added explanation of contact type attribute in section 4.1.2. 1851 * Updated responses. 1853 * Deleted description of command in section 4.1 and 1854 4.2. 1856 * Deleted whoisInfo disclose type in XML schema. 1858 * Deleted maxOccurs of addRemType. 1860 * Deleted extra "OPTIONAL" in section 4.2.5. 1862 * Updated typos in response. 1864 -02: 1866 * Changed author information. 1868 * Updated url definition. 1870 * Updated XML schema. 1872 -03: 1874 * Changed author information. 1876 * Updated section 3.1. 1878 * Refactoried the XSD file. Added element. 1880 * Added acknowledgment. 1882 WG document-00: WG document submitted 1884 WG document-01: Keep document alive for further discussion. 1885 Reseller object or entity object with multiple roles? 1887 Organization WG document-00: Change to a generic organization object 1888 mapping. 1890 Organization WG document-01: Added "Implementation Status" section. 1892 Organization WG document-02: Accepted some of the feedbacks on the 1893 mailing list. 1895 Organization WG document-03: 1897 * Updated section 3.2, changed the structure of organization 1898 role. 1900 * Updated section 4.2.5 for the "add", "rem" and "chg" example. 1902 * Updated section 5 of formal syntax. 1904 * Updated section 7.2 for the registration template and initial 1905 values. 1907 * Updated section 8 of implementation status. 1909 Organization WG document-04: 1911 * Updated section 3.2, changed the structure of organization 1912 role. 1914 * Updated references. 1916 * Updated section 8 of implementation status. 1918 Organization WG document-05: 1920 * Updated the description of of a role. 1922 * Removed the third paragraph of "Implementation Status". 1924 * Remove the Informative Reference to draft-ietf-regext-reseller 1925 from the draft. 1927 Organization WG document-06: 1929 * Updated typos. 1931 * Added "Query" for " Query Command". 1933 * Change "Registrant Contact" to IESG in section 7.1. 1935 * Modified section 7.2. 1937 Organization WG document-07: 1939 * Updated typos. 1941 * Added dns-operator in section 7.1. 1943 * Added "OPTIONAL" for 1945 Organization WG document-08: 1947 * Updated "Offline Review of Requested Actions". 1949 Organization WG document-09: 1951 * Updated "This element or its ancestor element MUST identify the 1952 organization namespace." in section 4.1.1 and other parts of 1953 this document. 1955 * Updated text in section 2 match RFC 8174. 1957 * Modified "roleid" to "roleID". 1959 * Updated text about loops in section 3.6. 1961 * Referred section 2.5 of RFC5733 for voice format. 1963 * Updated XML schema for the maxOccurs value of "reason" element. 1965 * Updated section 7.3. 1967 * Replaced "http" with "https" in the examples. 1969 * Updated writing typos. 1971 * Modified XML namespace and schema. 1973 Organization WG document-10: 1975 * Modified XML namespace and schema. 1977 * Removed the maxOccurs value of "reason" element. 1979 Organization WG document-11: 1981 * Typo of RFC2781 and moved this reference in "Informative 1982 References". 1984 * "Loops MUST be prohibited." in section 3.6. 1986 Authors' Addresses 1988 Linlin Zhou 1989 CNNIC 1990 4 South 4th Street, Zhongguancun, Haidian District 1991 Beijing, Beijing 100190 1992 China 1994 Email: zhoulinlin@cnnic.cn 1995 Ning Kong 1996 Consultant 1998 Email: ietfing@gmail.com 2000 Guiqing Zhou 2001 CNNIC 2002 4 South 4th Street, Zhongguancun, Haidian District 2003 Beijing, Beijing 100190 2004 China 2006 Email: zhouguiqing@cnnic.cn 2008 Jiankang Yao 2009 CNNIC 2010 4 South 4th Street, Zhongguancun, Haidian District 2011 Beijing, Beijing 100190 2012 China 2014 Email: yaojk@cnnic.cn 2016 James Gould 2017 Verisign, Inc. 2018 12061 Bluemont Way 2019 Reston, VA 20190 2020 US 2022 Email: jgould@verisign.com