idnits 2.17.1 draft-ietf-regext-org-ext-07.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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 15, 2018) is 2142 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 N. Kong 4 Intended status: Standards Track J. Wei 5 Expires: December 17, 2018 X. Lee 6 CNNIC 7 J. Gould 8 Verisign, Inc. 9 June 15, 2018 11 Organization Extension for the Extensible Provisioning Protocol (EPP) 12 draft-ietf-regext-org-ext-07 14 Abstract 16 This document describes an extension to EPP object mappings, which is 17 designed to support assigning an organization to any existing object 18 (domain, host, contact) as well as any future objects. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 17, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 68 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 70 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 72 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 73 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 4 74 4.1.3. EPP Query Command . . . . . . . . . . . . 7 75 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 76 4.2.1. EPP Command . . . . . . . . . . . . . . . . 8 77 4.2.2. EPP Command . . . . . . . . . . . . . . . . 10 78 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 10 79 4.2.4. EPP Command . . . . . . . . . . . . . . . 11 80 4.2.5. EPP Command . . . . . . . . . . . . . . . . 11 81 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6. Internationalization Considerations . . . . . . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 17 85 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 18 86 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 87 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 19 88 8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 19 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 20 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 11.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 In the business model of domain registration, we usually have 3 roles 100 of entities, a registrant, a registrar and a registry. There may be 101 other roles of entities involved in the domain registration process 102 which are not formally defined, such as resellers, DNS service 103 operators, privacy proxy, etc. 105 A domain reseller is an individual or a company that acts as a agent 106 for accredited registrars. A third-party DNS service operator is 107 responsible for a zone where the operator is neither the registrant 108 nor the registrar of record for the delegation. A privacy proxy is 109 an entity used for domain registrations to protect the private 110 information of the individuals and organizations. These kind of 111 entities are defined as "organizations" with different role types in 112 this document. 114 In order to facilitate provisioning and management of organization 115 information in a shared central repository, this document proposes an 116 organization extension mapping for any EPP object like domain names 117 in [RFC5731], hosts in [RFC5732] and contacts in [RFC5733]. The 118 examples provided in this document are used for the domain object for 119 illustration purpose. The host and contact object could be extended 120 in the same way with the domain object. 122 An organization mapping object defined in [ID.draft-ietf-regext-org] 123 SHOULD be created first. The organization information specified in 124 this document MUST reference the existing organization identifier. 126 This document is specified using the XML 1.0 as described in 127 [W3C.REC-xml-20040204] and XML Schema notation as described in 128 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 130 2. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 In examples, "C:" represents lines sent by a protocol client and "S:" 137 represents lines returned by a protocol server. Indentation and 138 white space in examples are provided only to illustrate element 139 relationships and are not a REQUIRED feature of this specification. 141 XML is case sensitive. Unless stated otherwise, XML specifications 142 and examples provided in this document MUST be interpreted in the 143 character case presented to develop a conforming implementation. 145 orgext-1.0 in this document is used as an abbreviation for 146 urn:ietf:params:xml:ns:orgext-1.0. The XML namespace prefix "orgext" 147 is used, but implementations MUST NOT depend on it and instead employ 148 a proper namespace-aware XML parser and serializer to interpret and 149 output the XML documents. 151 3. Object Attributes 153 This extension adds additional elements to EPP object mappings like 154 the EPP domain name mapping [RFC5731]. Only the new elements are 155 described here. 157 3.1. Organization Identifier 159 Organization identifier provides the ID of an organization. Its 160 corresponding element is which refers to the 161 element defined in [ID.draft-ietf-regext-org]. All organization 162 objects are identified by a server-unique identifier. 164 4. EPP Command Mapping 166 A detailed description of the EPP syntax and semantics can be found 167 in the EPP core protocol specification [RFC5730]. The command 168 mappings described here are specifically for assigning organizations 169 to EPP objects. 171 4.1. EPP Query Commands 173 EPP provides three commands to retrieve EPP object information: 174 to determine if an object can be provisioned within a 175 repository, to retrieve detailed information associated with 176 an object, and to retrieve object transfer status 177 information. 179 4.1.1. EPP Command 181 This extension does not add any elements to the EPP command 182 or response described in the EPP object mapping. 184 4.1.2. EPP Command 186 This extension does not add any element to the EPP command 187 described in the EPP object mapping. However, additional elements 188 are defined for the response in the EPP object mapping. 190 When an command has been processed successfully, the EPP 191 element MUST contain child elements as described in the EPP 192 object extensions. In addition, the EPP element SHOULD 193 contain a child element that identifies the 194 extension namespace if the object has data associated with this 195 extension and based on server policy. The element 196 contains the following child elements: 198 o Zero or more elements are allowed that contains the 199 identifier of the organization. The "role" attribute is used to 200 represent the relationship that the organization has to the 201 object. See Section 7.3 in [ID.draft-ietf-regext-org] for a list 202 of values. 204 Example response for an authorized client with multiple 205 organizations: 207 S: 208 S: 209 S: 210 S: 211 S: Command completed successfully 212 S: 213 S: 214 S: 216 S: example.com 217 S: EXAMPLE1-REP 218 S: 219 S: jd1234 220 S: sh8013 221 S: sh8013 222 S: sh8013 223 S: 224 S: ns1.example.com 225 S: 226 S: ClientX 227 S: ClientY 228 S: 2015-02-06T04:01:21.0Z 229 S: 2018-02-06T04:01:21.0Z 230 S: 231 S: 2fooBAR 232 S: 233 S: 234 S: 235 S: 236 S: 238 S: myreseller 239 S: myproxy 240 S: 241 S: 242 S: 243 S: ngcl-IvJjzMZc 244 S: test142AWQONJZ 245 S: 246 S: 247 S: 249 Example response for an authorized client with no 250 organization: 252 S: 253 S: 254 S: 255 S: 256 S: Command completed successfully 257 S: 258 S: 259 S: 261 S: example.com 262 S: EXAMPLE1-REP 263 S: 264 S: jd1234 265 S: sh8013 266 S: sh8013 267 S: sh8013 268 S: 269 S: ns1.example.com 270 S: 271 S: ClientX 272 S: ClientY 273 S: 2015-02-06T04:01:21.0Z 274 S: 2018-02-06T04:01:21.0Z 275 S: 276 S: 2fooBAR 277 S: 278 S: 279 S: 280 S: 281 S: 283 S: 284 S: 285 S: ngcl-IvJjzMZc 286 S: test142AWQONJZ 287 S: 288 S: 289 S: 291 An EPP error response MUST be returned if an command cannot be 292 processed for any reason. 294 4.1.3. EPP Query Command 296 This extension does not add any elements to the EPP query 297 command or query response described in the EPP object 298 mapping. 300 4.2. EPP Transform Commands 302 EPP provides five commands to transform EPP objects: to 303 create an instance of an object, to delete an instance of an 304 object, to extend the validity period of an object, 305 to manage the object sponsorship changes, and to 306 change information associated with an object. 308 4.2.1. EPP Command 310 This extension defines additional elements for the EPP 311 command described in the EPP object extensions. No additional 312 elements are defined for the EPP response. 314 The EPP command provides a transform operation that allows a 315 client to create an object. In addition to the EPP command elements 316 described in the EPP object extensions, the command MUST contain an 317 element, and the element MUST contain a child 318 element that identifies the extension namespace if 319 the client wants to associate data defined in this extension to the 320 object. The element contains the following child 321 elements: 323 o One or more elements that contains the identifier of 324 the organization. The "role" attribute is used to represent the 325 relationship that the organization has to the object. See 326 Section 7.3 in [ID.draft-ietf-regext-org] for a list of values. 328 Example Command with only one organization: 330 C: 331 C: 332 C: 333 C: 334 C: 336 C: example.com 337 C: 3 338 C: 339 C: ns1.example.com 340 C: 341 C: jd1234 342 C: sh8013 343 C: sh8013 344 C: sh8013 345 C: 346 C: fooBAR 347 C: 348 C: 349 C: 350 C: 351 C: 353 C: myreseller 354 C: 355 C: 356 C: ABC-12345 357 C: 358 C: 360 Example Command with multiple organizations: 362 C: 363 C: 364 C: 365 C: 366 C: 368 C: example.com 369 C: 3 370 C: 371 C: ns1.example.com 372 C: 373 C: jd1234 374 C: sh8013 375 C: sh8013 376 C: sh8013 377 C: 378 C: fooBAR 379 C: 380 C: 381 C: 382 C: 383 C: 385 C: myreseller 386 C: myproxy 387 C: 388 C: 389 C: ABC-12345 390 C: 391 C: 393 When a command has been processed successfully, the EPP 394 response is as described in the EPP object extension. 396 An EPP error response MUST be returned if a command cannot 397 be processed for any reason. 399 4.2.2. EPP Command 401 This extension does not add any elements to the EPP command 402 or response described in the EPP object mapping. 404 4.2.3. EPP Command 406 This extension does not add any elements to the EPP command 407 or response described in the EPP object mapping. 409 4.2.4. EPP Command 411 This extension does not add any elements to the EPP 412 command or response described in the EPP object mapping, 413 but after a successful transfer of an object with an assigned 414 organization, the handling of the assigned organization is dependent 415 on the organization roles and server policy. 417 4.2.5. EPP Command 419 This extension defines additional elements for the EPP 420 command described in the EPP domain mapping [RFC5731], host mapping 421 [RFC5732] and contact mapping [RFC5733]. No additional elements are 422 defined for the EPP response. 424 The EPP command provides a transform operation that allows a 425 client to modify the attributes of an object. In addition to the EPP 426 command elements, the command MUST contain an 427 element, and the element MUST contain a child 428 element that identifies the extension namespace if 429 the client wants to update the object with data defined in this 430 extension. The element contains the following child 431 elements: 433 o An OPTIONAL element that contains attribute values to 434 be added to the object. 436 o An OPTIONAL element that contains attribute values to 437 be removed from the object. 439 o An OPTIONAL element that contains attribute values to 440 be changed. 442 At least one and only one , or 443 element MUST be provided. The , and 444 elements contain the following child element: 446 o One or more elements that contains the identifier of 447 the organization. The "role" attribute is used to represent the 448 relationship that the organization has to the object. See 449 Section 7.3 in [ID.draft-ietf-regext-org] for a list of values. 451 Example command, adding a reseller: 453 C: 454 C: 455 C: 456 C: 457 C: 459 C: example.com 460 C: 461 C: 462 C: 463 C: 465 C: 466 C: myreseller 467 C: 468 C: 469 C: 470 C: ABC-12345 471 C: 472 C: 474 Example command, adding multiple organizations: 476 C: 477 C: 478 C: 479 C: 480 C: 482 C: example.com 483 C: 484 C: 485 C: 486 C: 488 C: 489 C: myreseller 490 C: myproxy 491 C: 492 C: 493 C: 494 C: ABC-12345 495 C: 496 C: 498 Example command, removing a reseller: 500 C: 501 C: 502 C: 503 C: 504 C: 506 C: example.com 507 C: 508 C: 509 C: 510 C: 512 C: 513 C: 514 C: 515 C: 516 C: 517 C: ABC-12345 518 C: 519 C: 521 Example command, removing multiple organizations: 523 C: 524 C: 525 C: 526 C: 527 C: 529 C: example.com 530 C: 531 C: 532 C: 533 C: 535 C: 536 C: 537 C: 538 C: 539 C: 540 C: 541 C: ABC-12345 542 C: 543 C: 545 Example command, updating reseller identifier: 547 C: 548 C: 549 C: 550 C: 551 C: 553 C: example.com 554 C: 555 C: 556 C: 557 C: 559 C: 560 C: myreseller 561 C: 562 C: 563 C: 564 C: ABC-12345 565 C: 566 C: 568 Example command, updating multiple organization identifiers: 570 C: 571 C: 572 C: 573 C: 574 C: 576 C: example.com 577 C: 578 C: 579 C: 580 C: 582 C: 583 C: myreseller 584 C: myproxy 585 C: 586 C: 587 C: 588 C: ABC-12345 589 C: 590 C: 592 When an extended command has been processed successfully, 593 the EPP response is as described in the EPP object extension. 595 5. Formal Syntax 597 An EPP object mapping is specified in XML Schema notation. The 598 formal syntax presented here is a complete schema representation of 599 the object mapping suitable for automated validation of EPP XML 600 instances. The BEGIN and END tags are not part of the schema; they 601 are used to note the beginning and ending of the schema for URI 602 registration purposes. 604 BEGIN 605 607 614 615 616 Extensible Provisioning Protocol v1.0 617 Organization Extension Schema v1.0 618 619 621 622 625 629 632 633 634 635 639 640 641 642 646 647 648 650 654 655 657 660 661 662 667 672 677 678 680 681 682 684 688 689 690 691 695 696 697 698 700 705 706 708 709 710 END 712 6. Internationalization Considerations 714 EPP is represented in XML, which provides native support for encoding 715 information using the Unicode character set and its more compact 716 representations including UTF-8. Conformant XML processors recognize 717 both UTF-8 and UTF-16. Though XML includes provisions to identify 718 and use other character encodings through use of an "encoding" 719 attribute in an declaration, use of UTF-8 is RECOMMENDED. 721 As an extension of the EPP object mapping, the elements, element 722 content described in this document MUST inherit the 723 internationalization conventions used to represent higher-layer 724 domain and core protocol structures present in an XML instance that 725 includes this extension. 727 7. IANA Considerations 729 7.1. XML Namespace 731 This document uses URNs to describe XML namespaces and XML schemas 732 conforming to a registry mechanism described in [RFC3688]. IANA is 733 requested to assignment the following URI. 735 Registration request for the organization namespace: 737 URI: urn:ietf:params:xml:ns:orgext-1.0 738 Registrant Contact: IESG 740 XML: See the "Formal Syntax" section of this document. 742 7.2. EPP Extension Registry 744 The EPP extension described in this document should be registered by 745 the IANA in the EPP Extension Registry described in [RFC7451]. The 746 details of the registration are as follows: 748 Name of Extension: Organization Extension for the Extensible 749 Provisioning Protocol (EPP) 751 Registrant Name and Email Address: IESG, iesg@ietf.org 753 TLDs: Any 755 IPR Disclosure: None 757 Status: Active 759 Notes: None 761 8. Implementation Status 763 Note to RFC Editor: Please remove this section and the reference to 764 [RFC7942] before publication. This section records the status of 765 known implementations of the protocol defined by this specification 766 at the time of posting of this Internet-Draft, and is based on a 767 proposal described in [RFC7942]. The description of implementations 768 in this section is intended to assist the IETF in its decision 769 processes in progressing drafts to RFCs. Please note that the 770 listing of any individual implementation here does not imply 771 endorsement by the IETF. Furthermore, no effort has been spent to 772 verify the information presented here that was supplied by IETF 773 contributors. This is not intended as, and must not be construed to 774 be, a catalog of available implementations or their features. 775 Readers are advised to note that other implementations may exist. 777 According to [RFC7942], "this will allow reviewers and working groups 778 to assign due consideration to documents that have the benefit of 779 running code, which may serve as evidence of valuable experimentation 780 and feedback that have made the implemented protocols more mature. 781 It is up to the individual working groups to use this information as 782 they see fit". 784 8.1. Verisign EPP SDK 786 Organization: Verisign Inc. 788 Name: Verisign EPP SDK 790 Description: The Verisign EPP SDK includes both a full client 791 implementation and a full server stub implementation of draft-ietf- 792 regext-org-ext. 794 Level of maturity: Development 796 Coverage: All aspects of the protocol are implemented. 798 Licensing: GNU Lesser General Public License 800 Contact: jgould@verisign.com 802 URL: https://www.verisign.com/en_US/channel-resources/domain- 803 registry-products/epp-sdks 805 8.2. CNNIC Implementation 807 Organization: CNNIC 809 Name: Organization Extension for EPP 811 Description: CNNIC is trying to update organization extension from 812 previous reseller extension according to this document. 814 Level of maturity: Development 816 Coverage: Organization extension for EPP 818 Contact: zhouguiqing@cnnic.cn 820 9. Security Considerations 822 The object mapping extension described in this document does not 823 provide any other security services or introduce any additional 824 considerations beyond those described by [RFC5730], [RFC5731], 825 [RFC5732] and [RFC5733] or those caused by the protocol layers used 826 by EPP. 828 10. Acknowledgment 830 The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick 831 Mevzek, Antoin Verschuren and Scott Hollenbeck for their careful 832 review and valuable comments. 834 11. References 836 11.1. Normative References 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, 840 DOI 10.17487/RFC2119, March 1997, 841 . 843 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 844 DOI 10.17487/RFC3688, January 2004, 845 . 847 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 848 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 849 . 851 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 852 Domain Name Mapping", STD 69, RFC 5731, 853 DOI 10.17487/RFC5731, August 2009, 854 . 856 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 857 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 858 August 2009, . 860 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 861 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 862 August 2009, . 864 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 865 Code: The Implementation Status Section", BCP 205, 866 RFC 7942, DOI 10.17487/RFC7942, July 2016, 867 . 869 [W3C.REC-xml-20040204] 870 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 871 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 872 Edition)", World Wide Web Consortium FirstEdition REC-xml- 873 20040204", February 2004, 874 . 876 [W3C.REC-xmlschema-1-20041028] 877 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 878 ""XML Schema Part 1: Structures Second Edition", World 879 Wide Web Consortium Recommendation REC-xmlschema- 880 1-20041028", October 2004, 881 . 883 [W3C.REC-xmlschema-2-20041028] 884 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 885 Second Edition", World Wide Web Consortium Recommendation 886 REC-xmlschema-2-20041028", October 2004, 887 . 889 11.2. Informative References 891 [ID.draft-ietf-regext-org] 892 Zhou, L., Kong, N., Zhou, G., Lee, X., and J. Gould, 893 "Extensible Provisioning Protocol (EPP) Reseller Mapping", 894 Apr 2018, 895 . 897 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 898 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 899 February 2015, . 901 Appendix A. Change Log 903 Initial -00: Individual document submitted. 905 -01: 907 * Updated abstract and introduction. 909 * Revised typos in info response. 911 * Added explanations on how to process reseller extension after 912 successful transfer operation. 914 * Modified explanation. 916 * Deleted reseller name element in and 917 commands. 919 * Removed some inaccurate comments from xml schema. 921 * Modified the element name of reseller id and reseller name. 923 -02: 925 * Changed author information. 927 * Updated xml typos to 928 in response. 930 -03: 932 * Changed author information. 934 * Updated section 3.1. 936 * Removed reseller name element in response. 938 * Added acknowledgment. 940 * Revised the typo "resellerr" to "resellerext". 942 WG document-00: WG document submitted 944 WG document-01: Keep document alive for further discussion. The 945 requirement of reseller information is clear for both registrar 946 and registry. What we should reach a consensus is whether the 947 extension should support only a name or ID and name. 949 Organization WG document-00: Change to a generic organization object 950 extension. 952 Organization WG document-01: Added "Implementation Status" section. 954 Organization WG document-02: Accepted some of the feedbacks on the 955 mailing list. Modified the examples in the document. 957 Organization WG document-03: 959 * Updated typos. 961 * Changed some descriptions about and role attribute. 963 * Modified the example of "domain with no organization". 965 * Updated section 8, adding implementation status of Verisign. 967 Organization WG document-04: 969 * Updated typos. 971 * Removed the example of command, domain with no 972 organization. 974 * Updated references. 976 * Updated section 8 of implementation status. 978 Organization WG document-05: 980 * Removed the minOccurs="0" from the addRemChgType type of the 981 XML schema 983 * Removed the third paragraph of "Implementation Status". 985 * Remove the Informative Reference to draft-ietf-regext-reseller- 986 ext from the draft. 988 Organization WG document-06: 990 * Updated "Abstraction". 992 * Added "Query" for " Query Command". 994 * Change "Registrant Contact" to IESG in section 7.1. 996 * Modified section 7.2. 998 Organization WG document-07: 1000 * Updated "Abstraction". 1002 Authors' Addresses 1004 Linlin Zhou 1005 CNNIC 1006 4 South 4th Street, Zhongguancun, Haidian District 1007 Beijing, Beijing 100190 1008 China 1010 Phone: +86 10 5881 2677 1011 Email: zhoulinlin@cnnic.cn 1013 Ning Kong 1014 CNNIC 1015 4 South 4th Street, Zhongguancun, Haidian District 1016 Beijing, Beijing 100190 1017 China 1019 Phone: +86 10 5881 3147 1020 Email: nkong@cnnic.cn 1021 Junkai Wei 1022 CNNIC 1023 4 South 4th Street, Zhongguancun, Haidian District 1024 Beijing, Beijing 100190 1025 China 1027 Phone: +86 10 5881 3494 1028 Email: weijunkai@cnnic.cn 1030 Xiaodong Lee 1031 CNNIC 1032 4 South 4th Street, Zhongguancun, Haidian District 1033 Beijing, Beijing 100190 1034 China 1036 Email: xl@cnnic.cn 1038 James Gould 1039 Verisign, Inc. 1040 12061 Bluemont Way 1041 Reston, VA 20190 1042 US 1044 Email: jgould@verisign.com