Provisioning Registry Protocol Working Group Hong Liu Internet Draft Ning Zhang Document: <draft-liu-epp-ustld-00.txt> Tom McGarry Category: Informational Joseph Amsden Ayesha Damaraju NeuStar, Inc. Expires in six months February 2002 New EPP Parameters for the usTLD <draft-liu-epp-ustld-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). <draft-liu-epp-usTLD-00> Expires August 2002 1 New EPP Parameters for the usTLD February 2002 Abstract This document defines two new EPP parameters to enable the exchange of additional information between the registry and the registrars for the United States ccTLD (usTLD). These two new parameters only apply to contact objects served as registrants for usTLD domains. This is accomplished according to the EPP extension framework in the command- response <extension> field. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[2]. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples is provided only to show element relationships and is not a REQUIRED feature of the protocol. Table of Contents 1. Introduction ................................................ 2 2. EPP Extensions for usTLD .................................... 3 3. Server Defined Extensions ................................... 3 3.1. AppPurpose Parameter....................................... 4 3.2. Nexus Parameter............................................ 4 4. EPP Commands ................................................ 5 5. Information Checking ........................................ 6 6. Examples .................................................... 7 7. Internationalization Considerations ......................... 9 8. IANA Considerations ......................................... 9 9. Security Considerations ..................................... 9 10. Acknowledgements ........................................... 9 11. References ................................................. 9 12. AuthorÆs Address .......................................... 10 Revisions From Previous Versions .............................. 11 Full Copyright Statements ..................................... 11 1. Introduction EPP (i.e., Extensible Provisioning Protocol) defines an extensible registry-registrar protocol for domain name registrations. It consists of a suite of documents: the generic protocol framework [3], and the object mappings for domain, host and contact [4-6], and the transport mapping to TCP [7]. The EPP extension framework allows registry specific features to be added at three levels: protocol, object and command-response [3]. The extensions made to EPP for the usTLD is at the command- response level. Specifically, two new information elements are added to the <extension> field in the contact object. The intent of this document is to specify the protocol elements in EPP extensions in order to accommodate additional information required for a registrar to interconnect with the usTLD registry via an EPP-compatible interface. Specifically, the document <draft-liu-epp-usTLD-00> Expires August 2002 2 New EPP Parameters for the usTLD February 2002 defines two new EPP parameters for contact objects to be used as registrants for usTLD domains. The first parameter describes the intended purpose of the domain name, while the second specifies the Nexus category to which the registering organization belongs. Both are defined as parameters within the command-response <extension> field for the contact object [6], according to the EPP extension framework outlined in [3]. For more information about usTLD and Nexus requirements, please refer to [8] and [9]. 2. EPP Extensions for the usTLD The EPP extensions for the usTLD are in the contact object mapping [5] at the command-response level. The extension template for the contact object is outlined below. C: <EPPCommandName> C: <contact:command xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:contact contact-1.0.xsd"> C: <!-- One or more contact-specific command elements. --> C: </contact:command> C: <extension> C: <!-- One or more server-defined elements. --> C: </extension> C: <trID> C: <clTRID>ABC-12345</clTRID> C: </trID> C: </EPPCommandName> S:<response> S: <result code="1000"> S: <msg lang="en">Command completed successfully</msg> S: </result> S: <extension> S: <!-- One or more server-defined elements. --> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S:</response> The extensions for the usTLD are accomplished by defining two new elements within the <extension> field. Three EPP commands are affected by the extensions for the contact object. 3. Server-Defined Elements Two parameters are defined for conveying information in the <extension> field; AppPurpose and NexusCategory. They are specified as name-value pairs within <extension> as follows: <draft-liu-epp-usTLD-00> Expires August 2002 3 New EPP Parameters for the usTLD February 2002 <extension> AppPurpose=value NexusCategory=value </extension> Here ôvalueö is a character string to be defined in Sections 3.1 and 3.2, respectively. When both parameters are present in the <extension> field, they are separated by at least one white space character. 3.1 AppPurpose Parameter The AppPurpose (i.e., Application Purpose) parameter specifies the intended usage for the domain name. The set of defined values for this parameter is: - ôP1ö: Business use for profit; - ôP2ö: Non-profit business, club, association, religious organization, etc.; - ôP3ö: Personal use; - ôP4ö: Educational purposes; - ôP5ö: Government purposes. 3.2 Nexus Parameter Qualifying registrants for the usTLD fall into one of the three categories: - Nexus Category 1 A natural person (i) who is a US citizen, (ii) a permanent resident of the US or any of its possessions or territories, or (iii) whose primary place of domicile is in the US or any of its possessions. - Nexus Category 2 An entity or organization that is (i) incorporated within one of the fifty US states, the District of Columbia, or any of the US possessions or territories, or (ii) organized or otherwise constituted under the laws of a state of the US, the District of Columbia or any of its possessions and territories (including federal, state, or local government of the US, or a political subdivision thereof, and non-commercial organizations based in the US.) - Nexus Category 3 A foreign entity or organization that has a bona fide presence in the US or any of its possessions or territories, and that has substantial lawful contacts with, or lawful activities in, the US. <draft-liu-epp-usTLD-00> Expires August 2002 4 New EPP Parameters for the usTLD February 2002 Nexus information is required for the registrants to ensure that only those individuals or organizations that have a substantive lawful connection to the US are permitted to register for usTLD domain names. The NexusCategory parameter specifies the Nexus category or sub- category to which the registrant belongs. The set of defined values for this parameter is: - ôC11ö: A natural person who is a US Citizen; - ôC12ö: A natural person who is a Permanent Resident; - ôC21ö: An entity or organization that is (i) incorporated within one of the fifty US states, the District of Columbia, or any of the US possessions or territories, or (ii) organized or otherwise constituted under the laws of a state of the US, the District of Columbia or any of its possessions and territories (including federal, state, or local government of the US, or a political subdivision thereof, and non-commercial organizations based in the US.) - ôC31/CCö: a foreign organization that regularly engages in lawful activities (sales of goods or services or other business, commercial, or non-commercial, including not for profit relations) in the United States. The CC equals to the country code of the organization, as defined in ISO 3166 [10]. - ôC32/CCö organization has an office or other facility in the U.S., where CC equals to the county code of the organization, as defined in ISO 3166 [10]. C11 and C12 are sub-categories of Nexus Category 1. C21 is Nexus Category 2. C31 and C32 are sub-categories of Nexus Category 3. Note that the third sub-category of Nexus Category 1, i.e., ôA natural person whose primary place of domicile is in the US or any of its possessions,ö is not qualified to register domain names under usTLD. 4. EPP Commands Three EPP commands are involved in the exchange of usTLD parameters between the registry and the registrars. They all apply only to those contact objects that are to be used as registrants for the usTLD domains. - <contact:create> command. At the time of creating a contact object for a registrant, usTLD parameters MUST be provided. - <contact:update> command. It can be used to modify usTLD parameters in a contact object that has already been created for a usTLD registrant. - <contact:info> command. It can be use to retrieve usTLD parameters associated with a contact object for a usTLD registrant. <draft-liu-epp-usTLD-00> Expires August 2002 5 New EPP Parameters for the usTLD February 2002 Regarding updating the usTLD parameters on a contact object using <contact:update>, the following behaviors are assumed by the registry: - If no <extension> field, or only an empty <extension> field such as <extension/> or <extension></extension> is present in the command, no action is taken by the registry. That is, the current value of either usTLD parameters, if exists, remain unchanged. - If either parameter is present in the <extension> field of the command as a ôparameter=valueö pair and the value is not null, e.g., <extension>AppPurpose=P1</extension> the registry will replace the value of the corresponding parameter in the contact object with the value supplied in the command. - If either parameter is present in the <extension> field in the command as a ôparameter=valueö pair and the value is null, e.g., <extension>AppPurpose=</extension> the registry will remove the corresponding parameter from the contact object. - If either parameter does not appear in the <extension> field of the command, the current value of the parameter, if exists, remain unchanged. Please refer to Section 5 for restrictions on update and removal of usTLD parameters for a contact object as registrant of a usTLD domain. When a contact object is associated with a usTLD domain, three other EPP commands corresponding to the domain object are also involved: <domain:create>, <domain:update> and <domain:info>. Please see Section 5 below. 5. Information Checking The two new usTLD parameters defined in Section 3 only apply to contact objects as registrants. Other contact objects, such as administrative and billing contacts, do not REQUIRE the provision of such information. The intended usage of a contact object is identified when it is associated with a domain object. The two usTLD parameters will be checked by the registry server at the time when a contact object is associated with a usTLD domain object as the registrant. Sepcifically, when the contact object is associated with a domain object as registrant in a <domain:create> or <domain:update> command, if AppPurpose or NexusCategory does not exist for the contact object, an EPP result code 2304 "Object status prohibits operation" SHOULD be returned. Moreover, if the value of <draft-liu-epp-usTLD-00> Expires August 2002 6 New EPP Parameters for the usTLD February 2002 AppPurpose or NexusCategory is not valid, an EPP result code 2306 "Parameter value policy error" SHOULD be returned [3]. Note that usTLD information checking for a contact object is done only when it is associated with a domain name as registrant, not at the time the contact object is created. It is the role of registrant that stipulates the provision of the two usTLD parameters for the contact object. Once a contact object is associated with a registered usTLD domain as registrant, both usTLD parameters MUST be present at all time. A registrar MUST NOT use <contact:update> to remove either parameters, otherwise an EPP result code 2304 "Object status prohibits operation" SHOULD be returned. If the <contact:update> command results in an invalid value for AppPurpose or NexusCategory, an EPP result code 2306 "Parameter value policy error" SHOULD be returned [3]. 6. Examples The following are examples of the EPP extensions for the usTLD. They are for illustrative purpose only. Example 1: Creating a contact object: C: <?xml version="1.0" encoding="UTF-8"?> C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> C: <command> C: <create> C: <contact:create xmlns="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd"> C: <contact:id>abcde</contact:id> C: <contact:ascii> C: <contact:name>abc</contact:name> C: <contact:org>abc.org</contact:org> C: <contact:addr> C: <contact:street>123 d street</contact:street> C: <contact:city>reston</contact:city> C: <contact:pc>20194</contact:pc> C: <contact:sp>VA</contact:sp> C: <contact:cc>US</contact:cc> C: </contact:addr> C: </contact:ascii> C: <contact:fax x="1234">+1.2345678901</contact:fax> C: <contact:email>xxx@yyy.com</contact:email> C: <contact:authInfo type="pw">123456</contact:authInfo> C: </contact:create> C: </create> C: <extension>AppPurpose=P1 NexusCategory=C31/DE</extention> C: <clTRID>coricopat-9978-1002</clTRID> C: </command> C: </epp> <draft-liu-epp-usTLD-00> Expires August 2002 7 New EPP Parameters for the usTLD February 2002 Here the usTLD extensions convey that the registrant intends to use the domain name for business purposes and the company is a German company that has an office or other facility in the U.S. Example 2: Updating information: C: <?xml version="1.0" encoding="UTF-8"?> C: <epp xmlns="urn:iana:xml:ns:epp-1.0" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd"> C: <command> C: <update> C: <contact:update xmlns="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd"> C: <contact:id>abc</contact:id> C: <contact:chg> C: <contact:voice>+1.2345678910</contact:voice> C: </contact:chg> C: </contact:update> C: </update> C: <extension>AppPurpose=P3 NexusCategory=C11</extension> C: <clTRID>coricopat-28444-1005</clTRID> C: </command> C: </epp> This command will update the contact object with modifications as follows: itÆs intended for personal use and the registrant is a US citizen. Example 3: usTLD information in the response of <contact:info>. S: <?xml version="1.0" encoding="UTF-8" standalone="no"?> S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd"> S: <contact:id>abcde</contact:id> S: <contact:roid>ABCDE-US</contact:roid> S: <contact:status s="linked"/> S: <contact:status s="clientDeleteProhibited"/> S: <contact:postalInfo> S: <contact:name>abc</contact:name> S: <contact:org>abc.org</contact:org> S: <contact:addr> S: <contact:street>123 d street</contact:street> S: <contact:city>reston</contact:city> S: <contact:pc>20194</contact:pc> S: <contact:sp>VA</contact:sp> S: <contact:cc>US</contact:cc> <draft-liu-epp-usTLD-00> Expires August 2002 8 New EPP Parameters for the usTLD February 2002 S: </contact:addr> S: </contact:postalInfo> S: <contact:fax x="1234">+1.2345678901</contact:fax> S: <contact:email>xxx@yyy.com</contact:email> S: <contact:clID>ClientY</contact:clID> S: <contact:crID>ClientX</contact:crID> S: <contact:crDate>2002-04-03T22:00:00.0Z</contact:crDate> S: <contact:upID>ClientX</contact:upID> S: <contact:upDate>2002-12-03T09:00:00.0Z</contact:upDate> S: <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate> S: <contact:authInfo type="pw">123456</contact:authInfo> S: </contact:infData> S: </resData> S: <extension>AppPurpose=P1 NexusCategory=C11</extension> S: <trID> S: <clTRID>coricopat-9978-1003</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S: </epp> Here the Nexus information returned indicates that the registrant registered the domain in .usTLD for business for profit and he/she is an US citizen. The <authInfo> element may not be returned if the querying registrar is not the sponsoring registrar. 7. Internationalization Considerations The new parameters defined in this document are for usTLD only. They do not introduce any additional international considerations other than those specified for EPP contact object mapping [5]. 8. IANA Considerations The new parameters defined in this document do not require IANA registrations. 9. Security Considerations The new parameters defined in this document do not provide any other security services or introduce any additional considerations beyond those described in EPP contact object mapping [5] 10. Acknowledgements [TBD] 11. REFERENCES [1] S. Bradner, "The Internet Standards Process -- Revision 3, BCP9," RFC 2026, October 1996. [2] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels," RFC 2119, BCP 14, March 1997. <draft-liu-epp-usTLD-00> Expires August 2002 9 New EPP Parameters for the usTLD February 2002 [3] S. Hollenbeck, "Extensible Provisioning Protocol," Internet- Draft draft-ietf-provreg-epp-06.txt, January 2002, Work in Progress. [4] S. Hollenbeck, "Extensible Provisioning Protocol Domain Name Mapping," Internet-Draft draft-ietf-provreg-epp-domain- 04.txt, January 2002, Work in Progress. [5] S. Hollenbeck, "Extensible Provisioning Protocol Contact Mapping," Internet-Draft draft-ietf-provreg-epp-contact- 04.txt, January 2002, Work in Progress. [6] S. Hollenbeck, "Extensible Provisioning Protocol Host Mapping," Internet-Draft draft-ietf-provreg-epp-host-03.txt, October 2001, Work in Progress. [7] S. Hollenbeck, "Extensible Provisioning Protocol Transport Over TCP," Internet-Draft draft-ietf-provreg-epp-tcp-04.txt, January 2002, Work in Progress. [8] A.Cooper and J. Postel, "The US Domain," RFC 1480, June 1993. [9] NeuStar Inc, "The usTLD Nexus Requirements," http://www.neustar.us/policies/docs/ustld_nexus_requirements. pdf [10] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", October 1997. http://www.din.de/gremien/nas/nabd/iso3166ma/ 12. Authors' Addresses Hong Liu NeuStar, Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C., 20005 U.S.A. Email: hong.liu@neustar.biz Ning Zhang NeuStar, Inc Loudoun Tech Center 45980 Center Oak Plaza Sterling, VA 20166 U.S.A. Phone: +1-571-434-5583 Email: ning.zhang@neustar.biz Tom McGarry NeuStar, Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C., 20005 U.S.A. Phone: +1-202-533-2810 Email: tom.mcgarry@neustar.biz Joseph Amsden NeuStar, Inc Loudoun Tech Center 45980 Center Oak Plaza Sterling, VA 20166 U.S.A. Phone: +1-571-434-5737 Email: joe.amsden@neustar.biz <draft-liu-epp-usTLD-00> Expires August 2002 10 New EPP Parameters for the usTLD February 2002 Ayesha Damaraju NeuStar, Inc Loudoun Tech Center 45980 Center Oak Plaza Sterling, VA 20166 U.S.A. Phone: +1-571-434-5581 Email: ayesha.damaraju@neustar.biz Revisions From Previous Versions Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. <draft-liu-epp-usTLD-00> Expires August 2002 11