idnits 2.17.1 draft-ietf-regext-org-08.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 (July 2, 2018) is 2097 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 G. Zhou 5 Expires: January 3, 2019 X. Lee 6 CNNIC 7 J. Gould 8 Verisign, Inc. 9 July 2, 2018 11 Extensible Provisioning Protocol (EPP) Organization Mapping 12 draft-ietf-regext-org-08 14 Abstract 16 This document describes an Extensible Provisioning Protocol (EPP) 17 mapping for provisioning and management of organization objects 18 stored in a shared central repository. Specified in Extensible 19 Markup Language (XML), this extended mapping is applied to provide 20 additional features required for the provisioning of organizations. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 70 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 72 3.2. Organization Roles . . . . . . . . . . . . . . . . . . . 4 73 3.2.1. Role Type . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2.2. Role Status . . . . . . . . . . . . . . . . . . . . . 4 75 3.2.3. Role Identifier . . . . . . . . . . . . . . . . . . . 4 76 3.3. Contact and Client Identifiers . . . . . . . . . . . . . 5 77 3.4. Organization Status Values . . . . . . . . . . . . . . . 5 78 3.5. Role Status Values . . . . . . . . . . . . . . . . . . . 6 79 3.6. Parent Identifier . . . . . . . . . . . . . . . . . . . . 7 80 3.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.8. Dates and Times . . . . . . . . . . . . . . . . . . . . . 7 82 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 84 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 8 85 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 10 86 4.1.3. EPP Query Command . . . . . . . . . . . . 15 87 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 88 4.2.1. EPP Command . . . . . . . . . . . . . . . . 15 89 4.2.2. EPP Command . . . . . . . . . . . . . . . . 19 90 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 20 91 4.2.4. EPP Command . . . . . . . . . . . . . . . 20 92 4.2.5. EPP Command . . . . . . . . . . . . . . . . 21 93 4.3. Offline Review of Requested Actions . . . . . . . . . . . 25 94 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 95 6. Internationalization Considerations . . . . . . . . . . . . . 36 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 97 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 36 98 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 37 99 7.3. Role Type Values Registry . . . . . . . . . . . . . . . . 37 100 7.3.1. Registration Template . . . . . . . . . . . . . . . . 37 101 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 37 102 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 38 103 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 39 104 8.2. CNNIC Implementation . . . . . . . . . . . . . . . . . . 39 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 106 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 40 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 108 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 109 11.2. Informative References . . . . . . . . . . . . . . . . . 41 110 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 113 1. Introduction 115 There are many entities, such as registrars, resellers, DNS service 116 operators, or privacy proxies involved in the domain registration 117 business. These kind of entities have not been formally defined as 118 an object in EPP which will be specified as "organization" in this 119 document. 121 This document describes an organization object mapping for version 122 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This 123 mapping is specified using the XML 1.0 as described in 124 [W3C.REC-xml-20040204] and XML Schema notation as described in 125 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 127 2. Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 In examples, "C:" represents lines sent by a protocol client and "S:" 134 represents lines returned by a protocol server. Indentation and 135 white space in examples are provided only to illustrate element 136 relationships and are not a REQUIRED feature of this specification. 138 XML is case sensitive. Unless stated otherwise, XML specifications 139 and examples provided in this document MUST be interpreted in the 140 character case presented to develop a conforming implementation. 142 "org-1.0" in is used as an abbreviation for 143 "urn:ietf:params:xml:ns:org-1.0". The XML namespace prefix "org" is 144 used, but implementations MUST NOT depend on it and instead employ a 145 proper namespace-aware XML parser and serializer to interpret and 146 output the XML documents. 148 3. Object Attributes 150 An EPP organization object has attributes and associated values that 151 can be viewed and modified by the sponsoring client or the server. 152 This section describes each attribute type in detail. The formal 153 syntax for the attribute values described here can be found in the 154 "Formal Syntax" section of this document and in the appropriate 155 normative references. 157 3.1. Organization Identifier 159 All EPP organizations are identified by a server-unique identifier. 160 Organization identifiers are character strings with a specified 161 minimum length, a specified maximum length, and a specified format. 162 Organization identifiers use the "clIDType" client identifier syntax 163 described in [RFC5730]. Its corresponding element is . 165 3.2. Organization Roles 167 The organization roles are used to represent the relationship an 168 organization could have. Its corresponding element is . 169 An organization object MUST always have at least one associated role. 170 Roles can be set only by the client that sponsors an organization 171 object. A client can change the role of an organization object using 172 the EPP command. 174 3.2.1. Role Type 176 An organization role MUST have a type which support a list of values. 177 An organization could have multiple roles with a different role type. 178 See Section 7.3 for a list of values. Its corresponding element is 179 . 181 3.2.2. Role Status 183 A role of an organization object MAY have its own statuses. Its 184 corresponding element is . The values of the role status 185 are defined in Section 3.5. 187 3.2.3. Role Identifier 189 A role MAY have a third party assigned identifier such as the IANA ID 190 for registrars. Its corresponding element is . 192 Example of organization role identifier: 194 195 registrar 196 ok 197 linked 198 1362 199 201 3.3. Contact and Client Identifiers 203 All EPP contacts are identified by a server-unique identifier. 204 Contact identifiers are character strings with a specific minimum 205 length, a specified maximum length, and a specified format. Contact 206 identifiers use the "clIDType" client identifier syntax described in 207 [RFC5730]. 209 3.4. Organization Status Values 211 An organization object MUST always have at least one associated 212 status value. The default value is "ok". 214 Status values that can be added or removed by a client are prefixed 215 with "client". Corresponding status values that can be added or 216 removed by a server are prefixed with "server". The "hold" and 217 "terminated" status values are server-managed when the organization 218 has no parent identifier [Section 3.6] and otherwise MAY be client- 219 managed based on server policy. 221 Status Value Descriptions: 223 o ok: This is the normal status value for an object that has no 224 pending operations or prohibitions. This value is set and removed 225 by the server as other status values are added or removed. 227 o hold: Organization transform commands and new links MUST be 228 rejected. 230 o terminated: The organization which has been terminated MUST NOT be 231 linked. Organization transform commands and new links MUST be 232 rejected. 234 o linked: The organization object has at least one active 235 association with another object. The "linked" status is not 236 explicitly set by the client. Servers SHOULD provide services to 237 determine existing object associations. 239 o clientLinkProhibited, serverLinkProhibited: Requests to add new 240 links to the organization MUST be rejected. 242 o clientUpdateProhibited, serverUpdateProhibited: Requests to update 243 the object (other than to remove this status) MUST be rejected. 245 o clientDeleteProhibited, serverDeleteProhibited: Requests to delete 246 the object MUST be rejected. 248 o pendingCreate, pendingUpdate, pendingDelete: A transform command 249 has been processed for the object, but the action has not been 250 completed by the server. Server operators can delay action 251 completion for a variety of reasons, such as to allow for human 252 review or third-party action. A transform command that is 253 processed, but whose requested action is pending, is noted with 254 response code 1001. 256 "pendingCreate", "ok", "hold", and "terminated" are mutually 257 exclusive statuses. Organization MUST have only one of these 258 statuses set. 260 "ok" status MAY only be combined with "linked" status. 262 A client or server MAY combine "linked" with either 263 "clientLinkProhibited" or "serverLinkProhibited" if new links must be 264 prohibited. 266 "pendingDelete" status MUST NOT be combined with either 267 "clientDeleteProhibited" or "serverDeleteProhibited" status. 269 The pendingCreate, pendingDelete, and pendingUpdate status values 270 MUST NOT be combined with each other. 272 3.5. Role Status Values 274 A role SHOULD have at least one associated status value. Valid 275 values include "ok", "linked", "clientLinkProhibited", and 276 "serverLinkProhibited". The default value is "ok". 278 Status Value Descriptions: 280 o ok: This is the normal status value for an role that has no 281 pending operations or prohibitions. This value is set and removed 282 by the server as other status values are added or removed. 284 o linked: The role of an organization object has at least one active 285 association with another object. The "linked" status is not 286 explicitly set by the client. Servers SHOULD provide services to 287 determine existing object associations. 289 o clientLinkProhibited, serverLinkProhibited: Requests to add new 290 links to the role MUST be rejected. 292 3.6. Parent Identifier 294 There can be more than one layer of organizations, such as a 295 reseller. The parent identifier, as defined with the 296 element, represents the parent organization identifier in a child 297 organization. 299 Take a reseller organization for example, the parent identifier is 300 not defined for the top level reseller, namely the registrar of the 301 registry. An N-tier reseller has a parent reseller and at least one 302 child reseller. A reseller customer has a parent reseller and no 303 child resellers. 305 Loops SHOULD be prohibited. If organization A has B as parent 306 identifier, organization B must not have organization A as parent 307 identifier. 309 3.7. URL 311 The URL represents the organization web home page, as defined with 312 the element. 314 3.8. Dates and Times 316 Date and time attribute values MUST be represented in Universal 317 Coordinated Time (UTC) using the Gregorian calendar. The extended 318 date-time form using upper case "T" and "Z" characters defined in 319 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 320 values, as XML Schema does not support truncated date-time forms or 321 lower case "T" and "Z" characters. 323 4. EPP Command Mapping 325 A detailed description of the EPP syntax and semantics can be found 326 in the EPP core protocol specification [RFC5730]. The command 327 mappings described here are specifically for use in provisioning and 328 managing organization information via EPP. 330 4.1. EPP Query Commands 332 EPP provides two commands to retrieve organization information: 333 to determine if an organization object can be provisioned 334 within a repository, and to retrieve detailed information 335 associated with an organization object. This document does not 336 define a mapping for the EPP command to retrieve 337 organization-object transfer status information. 339 4.1.1. EPP Command 341 The EPP command is used to determine if an object can be 342 provisioned within a repository. It provides a hint that allows a 343 client to anticipate the success or failure of provisioning an object 344 using the command, as object-provisioning requirements are 345 ultimately a matter of server policy. 347 In addition to the standard EPP command elements, the command 348 MUST contain a element that identifies the organization 349 namespace. The element contains the following child 350 elements: 352 o One or more elements that contain the server-unique 353 identifier of the organization objects to be queried. 355 Example command: 357 C: 358 C: 359 C: 360 C: 361 C: 363 C: res1523 364 C: re1523 365 C: 1523res 366 C: 367 C: 368 C: ABC-12345 369 C: 370 C: 372 When a command has been processed successfully, the EPP 373 element MUST contain a child element that 374 identifies the organization namespace. The element 375 contains one or more elements that contain the following 376 child elements: 378 o A element that identifies the queried object. This 379 element MUST contain an "avail" attribute whose value indicates 380 object availability (can it be provisioned or not) at the moment 381 the command was completed. A value of "1" or "true" means 382 that the object can be provisioned. A value of "0" or "false" 383 means that the object cannot be provisioned. 385 o An OPTIONAL element that MAY be provided when an 386 object cannot be provisioned. If present, this element contains 387 server-specific text to help explain why the object cannot be 388 provisioned. This text MUST be represented in the response 389 language previously negotiated with the client; an OPTIONAL "lang" 390 attribute MAY be present to identify the language if the 391 negotiated value is something other than the default value of 392 "en"(English). 394 Example response: 396 S: 397 S: 398 S: 399 S: 400 S: Command completed successfully 401 S: 402 S: 403 S: 405 S: 406 S: res1523 407 S: 408 S: 409 S: re1523 410 S: In use 411 S: 412 S: 413 S: 1523res 414 S: 415 S: 416 S: 417 S: 418 S: ABC-12345 419 S: 54322-XYZ 420 S: 421 S: 422 S: 424 An EPP error response MUST be returned if a command cannot be 425 processed for any reason. 427 4.1.2. EPP Command 429 The EPP command is used to retrieve information associated 430 with an organization object. It is up to the server policy to decide 431 what attributes will be returned of an organization object. In 432 addition to the standard EPP command elements, the command 433 MUST contain a element that identifies the organization 434 namespace. The element contains the following child 435 elements: 437 o A element that contains the server-unique identifier of 438 the organization object to be queried. 440 Example command: 442 C: 443 C: 444 C: 445 C: 446 C: 448 C: res1523 449 C: 450 C: 451 C: ABC-12345 452 C: 453 C: 455 When an command has been processed successfully, the EPP 456 element MUST contain a child element that 457 identifies the organization namespace. The element 458 contains the following child elements: 460 o A element that contains the server-unique identifier of 461 the organization object, as defined in Section 3.1. 463 o A element that contains the Repository Object 464 IDentifier assigned to the organization object when the object was 465 created. 467 o One or more elements that contains the role type, role 468 statuses and optional role id of the organization. 470 * A element that contains the type of the 471 organization, as defined in Section 3.2. 473 * One or more elements that contains the role 474 statuses. The values of the role status are defined in 475 Section 3.5. 477 * An OPTIONAL element that contains a third party 478 assigned identifier, such as IANA ID for registrars, as defined 479 in Section 3.2.3. 481 o One or more elements that contains the operational 482 status of the organization, as defined in Section 3.4. 484 o An OPTIONAL element that contains the identifier of 485 the parent object, as defined in Section 3.6. 487 o Zero to two elements that contain postal-address 488 information. Two elements are provided so that address 489 information can be provided in both internationalized and 490 localized forms; a "type" attribute is used to identify the two 491 forms. If an internationalized form (type="int") is provided, 492 element content MUST be represented in a subset of UTF-8 that can 493 be represented in the 7-bit US-ASCII character set. If a 494 localized form (type="loc") is provided, element content MAY be 495 represented in unrestricted UTF-8. The element 496 contains the following child elements: 498 * A element that contains the name of the 499 organization. 501 * An OPTIONAL element that contains address 502 information associated with the organization. A 503 element contains the following child elements: 505 + One, two, or three OPTIONAL elements that 506 contain the organization's street address. 508 + A element that contains the organization's city. 510 + An OPTIONAL element that contains the 511 organization's state or province. 513 + An OPTIONAL element that contains the 514 organization's postal code. 516 + A element that contains the organization's country 517 code. 519 o An OPTIONAL element that contains the organization's 520 voice telephone number. 522 o An OPTIONAL element that contains the organization's 523 facsimile telephone number. 525 o An OPTIONAL element that contains the organization's 526 email address. 528 o An OPTIONAL element that contains the URL to the website 529 of the organization. 531 o Zero or more OPTIONAL elements that contain 532 identifiers for the contact objects to be associated with the 533 organization object. Contact object identifiers MUST be known to 534 the server before the contact object can be associated with the 535 organization object. The required "type" is used to represent 536 contact types. The type values include "admin", "tech", 537 "billing", "abuse", and "custom". The OPTIONAL "typeName" 538 attribute is used to define the name of a "custom" type. 540 o An OPTIONAL element that contains the organization 541 identifier of the sponsoring client. There is no 542 element if the organization is managed by the registry. 544 o A element that contains the identifier of the client 545 that created the organization object. 547 o A element that contains the date and time of 548 organization object creation. 550 o A element that contains the identifier of the client 551 that last updated the organization object. This element MUST NOT 552 be present if the organization has never been modified. 554 o A element that contains the date and time of the most 555 recent organization object modification. This element MUST NOT be 556 present if the organization object has never been modified. 558 Example response for "Example Registrar Inc." organization 559 organization object with identifier "registrar1362": 561 S: 562 S: 563 S: 564 S: 565 S: Command completed successfully 566 S: 567 S: 568 S: 570 S: registrar1362 571 S: registrar1362-REP 572 S: 573 S: registrar 574 S: ok 575 S: linked 576 S: 1362 577 S: 578 S: ok 579 S: 580 S: Example Registrar Inc. 581 S: 582 S: 123 Example Dr. 583 S: Suite 100 584 S: Dulles 585 S: VA 586 S: 20166-6503 587 S: US 588 S: 589 S: 590 S: +1.7035555555 591 S: +1.7035555556 592 S: contact@organization.example 593 S: http://organization.example 594 S: sh8013 595 S: sh8013 596 S: sh8013 598 S: ClientX 599 S: 1999-04-03T22:00:00.0Z 600 S: ClientX 601 S: 1999-12-03T09:00:00.0Z 602 S: 603 S: 604 S: 605 S: ABC-12345 606 S: 54322-XYZ 607 S: 608 S: 609 S: 611 Example response for "Example Reseller Inc." organization 612 object of reseller type managed by identifier "registrar1362": 614 S: 615 S: 616 S: 617 S: 618 S: Command completed successfully 619 S: 620 S: 621 S: 623 S: reseller1523 624 S: reseller1523-REP 625 S: 626 S: reseller 627 S: ok 628 S: linked 629 S: 630 S: ok 631 S: registrar1362 632 S: 633 S: Example Reseller Inc. 634 S: 635 S: 123 Example Dr. 636 S: Suite 100 637 S: Dulles 638 S: VA 639 S: 20166-6503 640 S: US 641 S: 642 S: 643 S: +1.7035555556 644 S: http://organization.example 645 S: sh8013 646 S: 1362 647 S: ClientX 648 S: 1999-04-03T22:00:00.0Z 649 S: ClientX 650 S: 1999-12-03T09:00:00.0Z 651 S: 652 S: 653 S: 654 S: ABC-12345 655 S: 54322-XYZ 656 S: 657 S: 658 S: 660 An EPP error response MUST be returned if an command cannot be 661 processed for any reason. 663 4.1.3. EPP Query Command 665 The transfer semantics does not apply to organization object. No EPP 666 query command is defined in this document. 668 4.2. EPP Transform Commands 670 This document provides three commands to transform organization 671 object information: to create an instance of an organization 672 object, to delete an instance of an organization object, and 673 to change information associated with an organization 674 object. This document does not define a mapping for the EPP 675 and command. 677 Transform commands are typically processed and completed in real 678 time. Server operators MAY receive and process transform commands 679 but defer completing the requested action if human or third-party 680 review is required before the requested action can be completed. In 681 such situations, the server MUST return a 1001 response code to the 682 client to note that the command has been received and processed but 683 that the requested action is pending. The server MUST also manage 684 the status of the object that is the subject of the command to 685 reflect the initiation and completion of the requested action. Once 686 the action has been completed, the client MUST be notified using a 687 service message that the action has been completed and that the 688 status of the object has changed. Other notification methods MAY be 689 used in addition to the required service message. 691 Server operators SHOULD confirm that a client is authorized to 692 perform a transform command on a given object. Any attempt to 693 transform an object by an unauthorized client MUST be rejected, and 694 the server MUST return a 2201 response code to the client to note 695 that the client lacks privileges to execute the requested command. 697 4.2.1. EPP Command 699 The EPP command provides a transform operation that allows a 700 client to create an organization object. In addition to the standard 701 EPP command elements, the command MUST contain a 702 element that identifies the organization namespace. The 703 element contains the following child elements: 705 o A element that contains the desired server-unique 706 identifier for the organization to be created, as defined in 707 Section 3.1. 709 o One or more elements that contains the role type, role 710 statuses and optional role id of the organization. 712 * A element that contains the type of the 713 organization, as defined in Section 3.2. 715 * Zero or more elements that contains the role 716 statuses. The values of the role status are defined in 717 Section 3.5. 719 * An OPTIONAL element that contains a third party 720 assigned identifier, such as IANA ID for registrars, as defined 721 in Section 3.2.3. 723 o Zero of more element that contains the operational 724 status of the organization, as defined in Section 3.4. 726 o An OPTIONAL element that contains the identifier of 727 the parent object, as defined in Section 3.6. 729 o Zero to two elements that contain postal-address 730 information. Two elements are provided so that address 731 information can be provided in both internationalized and 732 localized forms; a "type" attribute is used to identify the two 733 forms. If an internationalized form (type="int") is provided, 734 element content MUST be represented in a subset of UTF-8 that can 735 be represented in the 7-bit US-ASCII character set. If a 736 localized form (type="loc") is provided, element content MAY be 737 represented in unrestricted UTF-8. The element 738 contains the following child elements: 740 * A element that contains the name of the 741 organization. 743 * An OPTIONAL element that contains address 744 information associated with the organization. A 745 element contains the following child elements: 747 + One, two, or three OPTIONAL elements that 748 contain the organization's street address. 750 + A element that contains the organization's city. 752 + An OPTIONAL element that contains the 753 organization's state or province. 755 + An OPTIONAL element that contains the 756 organization's postal code. 758 + A element that contains the organization's country 759 code. 761 o An OPTIONAL element that contains the organization's 762 voice telephone number. 764 o An OPTIONAL element that contains the organization's 765 facsimile telephone number. 767 o An OPTIONAL element that contains the organization's 768 email address. 770 o An OPTIONAL element that contains the URL to the website 771 of the organization. 773 o Zero or more OPTIONAL elements that contain 774 identifiers for the contact objects associated with the 775 organization object. 777 Example command: 779 C: 780 C: 781 C: 782 C: 783 C: 785 C: res1523 786 C: 787 C: reseller 788 C: 789 C: 1523res 790 C: 791 C: Example Organization Inc. 792 C: 793 C: 123 Example Dr. 794 C: Suite 100 795 C: Dulles 796 C: VA 797 C: 20166-6503 798 C: US 799 C: 800 C: 801 C: +1.7035555555 802 C: +1.7035555556 803 C: contact@organization.example 804 C: http://organization.example 805 C: sh8013 806 C: sh8013 807 C: 808 C: 809 C: ABC-12345 810 C: 811 C: 813 When a command has been processed successfully, the EPP 814 element MUST contain a child element that 815 identifies the organization namespace. The element 816 contains the following child elements: 818 o A element that contains the server-unique identifier for 819 the created organization, as defined in Section 3.1. 821 o A element that contains the date and time of 822 organization-object creation. 824 Example response: 826 S: 827 S: 828 S: 829 S: 830 S: Command completed successfully 831 S: 832 S: 833 S: 835 S: res1523 836 S: 1999-04-03T22:00:00.0Z 837 S: 838 S: 839 S: 840 S: ABC-12345 841 S: 54321-XYZ 842 S: 843 S: 844 S: 846 An EPP error response MUST be returned if a command cannot 847 be processed for any reason. 849 4.2.2. EPP Command 851 The EPP command provides a transform operation that allows a 852 client to delete an organization object. In addition to the standard 853 EPP command elements, the command MUST contain a 854 element that identifies the organization namespace. The 855 element MUST contain the following child element: 857 o A element that contains the server-unique identifier of 858 the organization object to be deleted, as defined in Section 3.1. 860 An organization object MUST NOT be deleted if it is associated with 861 other known objects. An associated organization MUST NOT be deleted 862 until associations with other known objects have been broken. A 863 server MUST notify clients that object relationships exist by sending 864 a 2305 error response code when a command is attempted and 865 fails due to existing object relationships. 867 Example command: 869 C: 870 C: 871 C: 872 C: 873 C: 875 C: res1523 876 C: 877 C: 878 C: ABC-12345 879 C: 880 C: 882 When a command has been processed successfully, a server 883 MUST respond with an EPP response with no element. 885 Example response: 887 S: 888 S: 889 S: 890 S: 891 S: Command completed successfully 892 S: 893 S: 894 S: ABC-12345 895 S: 54321-XYZ 896 S: 897 S: 898 S: 900 An EPP error response MUST be returned if a command cannot 901 be processed for any reason. 903 4.2.3. EPP Command 905 Renewal semantics do not apply to organization objects, so there is 906 no mapping defined for the EPP command. 908 4.2.4. EPP Command 910 Transfer semantics do not apply to organization objects, so there is 911 no mapping defined for the EPP command. 913 4.2.5. EPP Command 915 The EPP command provides a transform operation that allows a 916 client to modify the attributes of an organization object. In 917 addition to the standard EPP command elements, the command 918 MUST contain a element that identifies the organization 919 namespace. The element contains the following child 920 elements: 922 o A element that contains the server-unique identifier of 923 the organization object to be updated, as defined in Section 3.1. 925 o An OPTIONAL element that contains attribute values to be 926 added to the object. 928 o An OPTIONAL element that contains attribute values to be 929 removed from the object. 931 o An OPTIONAL element that contains attribute values to be 932 changed. 934 At least one , or element MUST be 935 provided if the command is not being extended. All of these elements 936 MAY be omitted if an extension is present. The OPTIONAL 937 and elements contain the following child element: 939 o Zero or more elements that contain the identifiers 940 for contact objects to be associated with or removed from the 941 organization object. Contact object identifiers MUST be known to 942 the server before the contact object can be associated with the 943 organization object. 945 o Zero or more elements that contains the role type, role 946 statuses and optional role id of the organization. 948 * A element that contains the role type of the 949 organization, as defined in Section 3.2. The role type 950 uniquely identifies the role to update. 952 * Zero or more elements that contains the role 953 statuses. The values of the role status are defined in 954 Section 3.5. 956 * An OPTIONAL element that contains a third party 957 assigned identifier, such as IANA ID for registrars, as defined 958 in Section 3.2.3. 960 o Zero or more element that contains the operational 961 status of the organization. 963 An OPTIONAL element contains the following child elements, 964 where at least one child element MUST be present: 966 o An OPTIONAL element that contains the identifier of 967 the parent object. 969 o Zero to two elements that contain postal-address 970 information. Two elements are provided so that address 971 information can be provided in both internationalized and 972 localized forms; a "type" attribute is used to identify the two 973 forms. If an internationalized form (type="int") is provided, 974 element content MUST be represented in a subset of UTF-8 that can 975 be represented in the 7-bit US-ASCII character set. If a 976 localized form (type="loc") is provided, element content MAY be 977 represented in unrestricted UTF-8. The change of the postal info 978 is defined as a replacement of that postal info element with the 979 contents of the sub-elements included in the update command. An 980 empty element is supported to allow a type of 981 postal info to be removed. The element contains 982 the following child elements: 984 * A element that contains the name of the 985 organization. 987 * An OPTIONAL element that contains address 988 information associated with the organization. A 989 element contains the following child elements: 991 + One, two, or three OPTIONAL elements that 992 contain the organization's street address. 994 + A element that contains the organization's city. 996 + An OPTIONAL element that contains the 997 organization's state or province. 999 + An OPTIONAL element that contains the 1000 organization's postal code. 1002 + A element that contains the organization's country 1003 code. 1005 o An OPTIONAL element that contains the organization's 1006 voice telephone number. 1008 o An OPTIONAL element that contains the organization's 1009 facsimile telephone number. 1011 o An OPTIONAL element that contains the organization's 1012 email address. 1014 o An OPTIONAL element that contains the URL to the website 1015 of the organization. 1017 Example command: 1019 C: 1020 C: 1021 C: 1022 C: 1023 C: 1025 C: res1523 1026 C: 1027 C: sh8013 1028 C: 1029 C: privacyproxy 1030 C: clientLinkProhibited 1031 C: 1032 C: clientLinkProhibited 1033 C: 1034 C: 1035 C: sh8014 1036 C: 1037 C: reseller 1038 C: 1039 C: 1040 C: 1041 C: 1042 C: 1043 C: 124 Example Dr. 1044 C: Suite 200 1045 C: Dulles 1046 C: VA 1047 C: 20166-6503 1048 C: US 1049 C: 1050 C: 1051 C: +1.7034444444 1052 C: 1053 C: 1054 C: 1055 C: 1056 C: ABC-12345 1057 C: 1058 C: 1060 When an command has been processed successfully, a server 1061 MUST respond with an EPP response with no element. 1063 Example response: 1065 S: 1066 S: 1067 S: 1068 S: 1069 S: Command completed successfully 1070 S: 1071 S: 1072 S: ABC-12345 1073 S: 54321-XYZ 1074 S: 1075 S: 1076 S: 1078 An EPP error response MUST be returned if an command cannot 1079 be processed for any reason. 1081 4.3. Offline Review of Requested Actions 1083 Commands are processed by a server in the order they are received 1084 from a client. Though an immediate response confirming receipt and 1085 processing of the command is produced by the server, a server 1086 operator MAY perform an offline review of requested transform 1087 commands before completing the requested action. In such situations, 1088 the response from the server MUST clearly note that the transform 1089 command has been received and processed, but the requested action is 1090 pending. The status of the corresponding object MUST clearly reflect 1091 processing of the pending action. The server MUST notify the client 1092 when offline processing of the action has been completed. 1094 Examples describing a command that requires offline review 1095 are included here. Note the result code and message returned in 1096 response to the command. 1098 S: 1099 S: 1100 S: 1101 S: 1102 S: Command completed successfully; action pending 1103 S: 1104 S: 1105 S: 1107 S: res1523 1108 S: 1999-04-03T22:00:00.0Z 1109 S: 1110 S: 1111 S: 1112 S: ABC-12345 1113 S: 54321-XYZ 1114 S: 1115 S: 1116 S: 1118 The status of the organization object after returning this response 1119 MUST include "pendingCreate". The server operator reviews the 1120 request offline, and informs the client of the outcome of the review 1121 either by queuing a service message for retrieval via the 1122 command or by using an out-of-band mechanism to inform the client of 1123 the request. 1125 The service message MUST contain text that describes the notification 1126 in the child element of the response element. In 1127 addition, the EPP element MUST contain a child 1128 element that identifies the organization namespace. 1129 The element contains the following child elements: 1131 o A element that contains the server-unique identifier of 1132 the organization object. The element contains a REQUIRED 1133 "paResult" attribute. A positive boolean value indicates that the 1134 request has been approved and completed. A negative boolean value 1135 indicates that the request has been denied and the requested 1136 action has not been taken. 1138 o A element that contains the client transaction 1139 identifier and server transaction identifier returned with the 1140 original response to process the command. The client transaction 1141 identifier is OPTIONAL and will only be returned if the client 1142 provided an identifier with the original command. 1144 o A element that contains the date and time describing 1145 when review of the requested action was completed. 1147 Example "review completed" service message: 1149 S: 1150 S: 1151 S: 1152 S: 1153 S: Command completed successfully; ack to dequeue 1154 S: 1155 S: 1156 S: 1999-04-04T22:01:00.0Z 1157 S: Pending action completed successfully. 1158 S: 1159 S: 1160 S: 1162 S: res1523 1163 S: 1164 S: ABC-12345 1165 S: 54321-XYZ 1166 S: 1167 S: 1999-04-04T22:00:00.0Z 1168 S: 1169 S: 1170 S: 1171 S: BCD-23456 1172 S: 65432-WXY 1173 S: 1174 S: 1175 S: 1177 5. Formal Syntax 1179 An EPP object mapping is specified in XML Schema notation. The 1180 formal syntax presented here is a complete schema representation of 1181 the object mapping suitable for automated validation of EPP XML 1182 instances. The BEGIN and END tags are not part of the schema; they 1183 are used to note the beginning and ending of the schema for URI 1184 registration purposes. 1186 BEGIN 1187 1188 1195 1198 1199 1201 1202 1203 Extensible Provisioning Protocol v1.0 1204 organization provisioning schema. 1205 1206 1208 1211 1212 1213 1214 1215 1216 1218 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1237 1238 1240 1241 1242 1243 1244 1245 1246 1247 1249 1250 1251 1252 1254 1255 1256 1258 1259 1260 1262 1264 1265 1268 1270 1271 1272 1273 1275 1276 1277 1278 1280 1281 1282 1283 1284 1285 1286 1287 1288 1290 1291 1292 1293 1294 1295 1296 1298 1299 1300 1301 1302 1303 1305 1306 1307 1308 1309 1310 1312 1313 1314 1315 1316 1318 1319 1320 1321 1322 1324 1325 1326 1327 1328 1330 1331 1332 1334 1335 1337 1339 1340 1341 1343 1344 1345 1346 1347 1348 1350 1353 1354 1355 1356 1357 1359 1362 1363 1364 1366 1367 1369 1372 1373 1374 1375 1376 1377 1378 1380 1381 1382 1383 1385 1386 1387 1389 1392 1393 1394 1396 1397 1399 1402 1403 1404 1406 1408 1410 1412 1414 1416 1418 1420 1422 1425 1426 1428 1431 1432 1433 1435 1437 1439 1441 1442 1444 1447 1448 1449 1451 1453 1455 1456 1458 1461 1462 1463 1465 1468 1470 1472 1474 1476 1478 1480 1481 1482 1484 1486 1487 1489 1491 1494 1495 1496 1498 1501 1502 1503 1505 1506 1508 1509 1510 1511 1513 1514 1516 1517 1518 1519 1521 1522 1523 1525 1528 1529 1530 1532 1534 1536 1538 1540 1542 1544 1546 1548 1550 1552 1554 1556 1558 1560 1562 1563 1564 1567 1568 1569 1570 1571 1572 1574 1577 1578 END 1580 6. Internationalization Considerations 1582 EPP is represented in XML, which provides native support for encoding 1583 information using the Unicode character set and its more compact 1584 representations including UTF-8. Conformant XML processors recognize 1585 both UTF-8 and UTF-16. Though XML includes provisions to identify 1586 and use other character encodings through use of an "encoding" 1587 attribute in an declaration, use of UTF-8 is RECOMMENDED. 1589 As an extension of the EPP organization object mapping, the elements 1590 and element content described in this document MUST inherit the 1591 internationalization conventions used to represent higher-layer 1592 domain and core protocol structures present in an XML instance that 1593 includes this extension. 1595 7. IANA Considerations 1597 7.1. XML Namespace 1599 This document uses URNs to describe XML namespaces and XML schemas 1600 conforming to a registry mechanism described in [RFC3688]. IANA is 1601 requested to assignment the following URI. 1603 Registration request for the organization namespace: 1605 URI: urn:ietf:params:xml:ns:org-1.0 1607 Registrant Contact: IESG 1609 XML: None. Namespace URIs do not represent an XML specification. 1611 Registration request for the organization XML schema: 1613 URI: urn:ietf:params:xml:ns:org-1.0 1615 Registrant Contact: IESG 1617 XML: See the "Formal Syntax" section of this document. 1619 7.2. EPP Extension Registry 1621 The EPP extension described in this document should be registered by 1622 the IANA in the EPP Extension Registry described in [RFC7451]. The 1623 details of the registration are as follows: 1625 Name of Extension: Extensible Provisioning Protocol (EPP) 1626 Organization Mapping 1628 Registrant Name and Email Address: IESG, iesg@ietf.org 1630 TLDs: Any 1632 IPR Disclosure: None 1634 Status: Active 1636 Notes: None 1638 7.3. Role Type Values Registry 1640 The following values should be registered by the IANA in the "EPP 1641 Organization Role Values" registry. The registration policy for this 1642 registry is "Expert Review" [RFC8126]. 1644 7.3.1. Registration Template 1646 Value: the string value being registered. 1648 Description: Brief description of the organization role values. 1650 Registrant Name: For Standards Track RFCs, state "IESG". For others, 1651 give the name of the responsible party. 1653 Registrant Contact Information: an email address, postal address, or 1654 some other information to be used to contact the registrant. 1656 7.3.2. Initial Registry Contents 1658 Followings are the initial registry contents: 1660 Value: registrar 1662 Description: The entity object instance represents the authority 1663 responsible for the registration in the registry. 1665 Registrant Name: IESG 1666 Registrant Contact Information: iesg@ietf.org 1668 Value: reseller 1670 Description: The entity object instance represents a third party 1671 through which the registration was conducted (i.e., not the 1672 registry or registrar). 1674 Registrant Name: IESG 1676 Registrant Contact Information: iesg@ietf.org 1678 Value: privacyproxy 1680 Description: The entity object instance represents a third-party 1681 who could help to register a domain without exposing the 1682 registrants' private information. 1684 Registrant Name: IESG 1686 Registrant Contact Information: iesg@ietf.org 1688 Value: dns-operator 1690 Description: The entity object instance represents a third-party 1691 DNS operator that maintains the name servers and zone data on 1692 behalf of a registrant. 1694 Registrant Name: IESG 1696 Registrant Contact Information: iesg@ietf.org 1698 8. Implementation Status 1700 Note to RFC Editor: Please remove this section and the reference to 1701 [RFC7942] before publication. This section records the status of 1702 known implementations of the protocol defined by this specification 1703 at the time of posting of this Internet-Draft, and is based on a 1704 proposal described in [RFC7942]. The description of implementations 1705 in this section is intended to assist the IETF in its decision 1706 processes in progressing drafts to RFCs. Please note that the 1707 listing of any individual implementation here does not imply 1708 endorsement by the IETF. Furthermore, no effort has been spent to 1709 verify the information presented here that was supplied by IETF 1710 contributors. This is not intended as, and must not be construed to 1711 be, a catalog of available implementations or their features. 1712 Readers are advised to note that other implementations may exist. 1714 According to [RFC7942], "this will allow reviewers and working groups 1715 to assign due consideration to documents that have the benefit of 1716 running code, which may serve as evidence of valuable experimentation 1717 and feedback that have made the implemented protocols more mature. 1718 It is up to the individual working groups to use this information as 1719 they see fit". 1721 8.1. Verisign EPP SDK 1723 Organization: Verisign Inc. 1725 Name: Verisign EPP SDK 1727 Description: The Verisign EPP SDK includes both a full client 1728 implementation and a full server stub implementation of draft-ietf- 1729 regext-org. 1731 Level of maturity: Development 1733 Coverage: All aspects of the protocol are implemented. 1735 Licensing: GNU Lesser General Public License 1737 Contact: jgould@verisign.com 1739 URL: https://www.verisign.com/en_US/channel-resources/domain- 1740 registry-products/epp-sdks 1742 8.2. CNNIC Implementation 1744 Organization: CNNIC 1746 Name: EPP Organization Mapping 1748 Description: CNNIC is trying to update EPP organization mapping from 1749 previous reseller mapping according to this document. 1751 Level of maturity: Development 1753 Coverage: EPP organization mapping 1755 Contact: zhouguiqing@cnnic.cn 1757 9. Security Considerations 1759 The object mapping extension described in this document does not 1760 provide any other security services or introduce any additional 1761 considerations beyond those described by [RFC5730] or those caused by 1762 the protocol layers used by EPP. The security considerations 1763 described in these other specifications apply to this specification 1764 as well. 1766 10. Acknowledgment 1768 The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick 1769 Mevzek, Antoin Verschuren and Scott Hollenbeck for their careful 1770 review and valuable comments. 1772 11. References 1774 11.1. Normative References 1776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1777 Requirement Levels", BCP 14, RFC 2119, 1778 DOI 10.17487/RFC2119, March 1997, 1779 . 1781 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1782 DOI 10.17487/RFC3688, January 2004, 1783 . 1785 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1786 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1787 . 1789 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1790 Code: The Implementation Status Section", BCP 205, 1791 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1792 . 1794 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1795 Writing an IANA Considerations Section in RFCs", BCP 26, 1796 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1797 . 1799 [W3C.REC-xml-20040204] 1800 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1801 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1802 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1803 20040204", February 2004, 1804 . 1806 [W3C.REC-xmlschema-1-20041028] 1807 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1808 ""XML Schema Part 1: Structures Second Edition", World 1809 Wide Web Consortium Recommendation REC-xmlschema- 1810 1-20041028", October 2004, 1811 . 1813 [W3C.REC-xmlschema-2-20041028] 1814 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1815 Second Edition", World Wide Web Consortium Recommendation 1816 REC-xmlschema-2-20041028", October 2004, 1817 . 1819 11.2. Informative References 1821 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1822 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1823 February 2015, . 1825 Appendix A. Change Log 1827 Initial -00: Individual document submitted. 1829 -01: 1831 * Updated abstract text. 1833 * Added sentences to avoid loop of parent identifiers in section 1834 3.4. 1836 * Revised typos in section 3.6. 1838 * Added explanation of contact type attribute in section 4.1.2. 1840 * Updated responses. 1842 * Deleted description of command in section 4.1 and 1843 4.2. 1845 * Deleted whoisInfo disclose type in XML schema. 1847 * Deleted maxOccurs of addRemType. 1849 * Deleted extra "OPTIONAL" in section 4.2.5. 1851 * Updated typos in response. 1853 -02: 1855 * Changed author information. 1857 * Updated url definition. 1859 * Updated XML schema. 1861 -03: 1863 * Changed author information. 1865 * Updated section 3.1. 1867 * Refactoried the XSD file. Added element. 1869 * Added acknowledgment. 1871 WG document-00: WG document submitted 1873 WG document-01: Keep document alive for further discussion. 1874 Reseller object or entity object with multiple roles? 1876 Organization WG document-00: Change to a generic organization object 1877 mapping. 1879 Organization WG document-01: Added "Implementation Status" section. 1881 Organization WG document-02: Accepted some of the feedbacks on the 1882 mailing list. 1884 Organization WG document-03: 1886 * Updated section 3.2, changed the structure of organization 1887 role. 1889 * Updated section 4.2.5 for the "add", "rem" and "chg" example. 1891 * Updated section 5 of formal syntax. 1893 * Updated section 7.2 for the registration template and initial 1894 values. 1896 * Updated section 8 of implementation status. 1898 Organization WG document-04: 1900 * Updated section 3.2, changed the structure of organization 1901 role. 1903 * Updated references. 1905 * Updated section 8 of implementation status. 1907 Organization WG document-05: 1909 * Updated the description of of a role. 1911 * Removed the third paragraph of "Implementation Status". 1913 * Remove the Informative Reference to draft-ietf-regext-reseller 1914 from the draft. 1916 Organization WG document-06: 1918 * Updated typos. 1920 * Added "Query" for " Query Command". 1922 * Change "Registrant Contact" to IESG in section 7.1. 1924 * Modified section 7.2. 1926 Organization WG document-07: 1928 * Updated typos. 1930 * Added dns-operator in section 7.1. 1932 * Added "OPTIONAL" for 1934 Organization WG document-08: 1936 * Updated "Offline Review of Requested Actions". 1938 Authors' Addresses 1940 Linlin Zhou 1941 CNNIC 1942 4 South 4th Street, Zhongguancun, Haidian District 1943 Beijing, Beijing 100190 1944 China 1946 Phone: +86 10 5881 2677 1947 Email: zhoulinlin@cnnic.cn 1948 Ning Kong 1949 CNNIC 1950 4 South 4th Street, Zhongguancun, Haidian District 1951 Beijing, Beijing 100190 1952 China 1954 Phone: +86 10 5881 3147 1955 Email: nkong@cnnic.cn 1957 Guiqing Zhou 1958 CNNIC 1959 4 South 4th Street, Zhongguancun, Haidian District 1960 Beijing, Beijing 100190 1961 China 1963 Phone: +86 10 5881 2692 1964 Email: zhouguiqing@cnnic.cn 1966 Xiaodong Lee 1967 CNNIC 1968 4 South 4th Street, Zhongguancun, Haidian District 1969 Beijing, Beijing 100190 1970 China 1972 Email: xl@cnnic.cn 1974 James Gould 1975 Verisign, Inc. 1976 12061 Bluemont Way 1977 Reston, VA 20190 1978 US 1980 Email: jgould@verisign.com