Internet-Draft Tomek Zygmuntowicz Expires: April 2005 Patrycja Wegrzynowicz Kuba Laszkiewicz Juliusz Brzostek Witold Zarowski Andrzej Bartosiewicz Krzysztof Olesik NASK October 2004 EPP parameters for .pl ccTLD draft-zygmuntowicz-epp-pltld-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been disclosed, and any of which he or she becomes aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document is a proposed description of the cooperation protocol between NASK and its Partners. The proposal can be replaced with the new document or can be invalidated. The content of this proposal relates to the documents: , , , , RFC 3375 published by Internet Engineering Task Force. NASK [Page 1] Internet-Draft EPP parameters for .pl ccTLD October 2004 Table of Contents 1. Introduction ................................................ 2 2. EPP modifications ........................................... 2 2.1 element ....................................... 2 2.2 element ............................... 3 2.3 element - optional .................................. 3 2.4 element ............................................... 3 2.5 and commands ............ 4 2.6 command ........................................ 4 2.7 command ........................................ 4 2.8 command ........................................ 4 2.9 command .......................................... 4 2.10 command ....................................... 5 2.11 command ...................................... 5 3. The future extension .......................................... 5 3.1 command ....................................... 6 3.2 command ...................................... 8 3.3 command ........................................ 10 3.4 command ...................................... 13 3.5 command .................................... 14 3.6 command ....................................... 17 3.7 command ...................................... 17 4. Examples ...................................................... 17 5. Formal syntax ................................................. 26 6. EPP and IDN Registration ...................................... 28 7. Security Considerations ....................................... 29 8. References .................................................... 29 9. Authors Addresses ............................................. 30 10. Full Copyright Statement ..................................... 31 1. Introduction The Extensible Provisioning Protocol (EPP, [2]) describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. The intent of this document is to specify the protocol elements in EPP extensions in order to accomodate additional information required for a registrar to interconnect with the .pl ccTLD registry via an EPP-compatible interface. 2. EPP modifications 2.1 element The element has been added to commands: , and . It specifies whether the contact represents a private person. NASK [Page 2] Internet-Draft EPP parameters for .pl ccTLD October 2004 2.2 element The element has been added to commands: , , and . It specifies, for a contact representing a private person, whether this person gave its assent for publishing personal details in WHOIS database. The element has no meaning for a contact which does not represent a private person. 2.3 - optional The element has been added to command. It includes a justification of registrant's rights to a domain. 2.4 element The element has been added to the command. Successfully processed command with provided element causes a reservation of a domain in the system. Successfully processed command with not provided element causes a registration of a domain in the system. The only operation which can be performed on the reserved domain is registration by the client which had reserved the domain. If the client which reserved a domain does not register the domain before expiration of reservation period (the reservation period is determined by parameters of the system) then a possibility of a reservation and a registration of the domain is blocked for a random period (this period is determined by parameters of the system). The domain will be available for reservation and registration after expiration of blockade period. Note that reservation of a domain prior to reservation of this domain is not obligatory. The following rules of providing domain's data for command are an necessary condition of a successful domain registration: - registrant's ID contained in element and the domain name rights justification contained in element must be provided only once: either during a domain reservation or registration. - a domain validity period contained in element must be provided only once: either during a domain reservation or registration. When the domain validity period is not provided, the system sets a default value which is determined by system's parameters. - domain authorization data contained in element must be provided during a domain reservation and registration. Both values must be identical. NASK [Page 3] Internet-Draft EPP parameters for .pl ccTLD October 2004 - name servers contained in elements can be provided only once, with the first command. The number of provided name servers must meet the rules specified by parameters of the system. - identifiers of contacts associated with a domain contained in elements can be given only once: either during a domain reservation or registration. Given list of contacts must meet the rules specified by parameters of the system. Providing no elements neither during a registration nor reservation is possible only when the parameters of the system allow for the zero number of contacts to be associated with a domain. 2.5 and commands A transfer of a domain or a contact does not require confirmation of sponsoring client of that object. A result of a transfer command is returned directly in response to or command with option op=request (status serverApproved is set in case of successful processing of transfer command). Options of the and commands other than request are not supported. 2.6 command It is possible to delete a host using the command, even if there are domains delegated to that host, on the condition that the host is not configured for any domain which is delegated to this host. A side effect of a removal of a host is removal of all delegations to that host. 2.7 command Using the command it is possible to create a host which belongs to a zone maintained by Registry (NASK) and for which no superordinate domain exists. Such created host has the pendingCreate status. It will be removed from the system if the superordinate domain is not reserved or registered before expiration of a period determined by the system parameters. 2.8 command A change of a host's name is forbidden. A providing of the element in the element causes failure of the command. 2.9 command The command returns full set of information only for sponsoring client, for other clients operation fails. NASK [Page 4] Internet-Draft EPP parameters for .pl ccTLD October 2004 2.10 command The command returns full set of information only for sponsoring client of a domain and client which provided a correct authorization information in the element. In other cases command fails. 2.11 command The command returns full set of information only to sponsoring client of a domain and to client who provided a correct authorization information of domain in the element. Furthermore, if contact represents a private person (individual=1) who consents to publish his/her personal details (consentForPublishing=1) then information is returned to the others clients. In other cases command fails. 3. The future extension NASK EPP extends EPP by introducing a new type of object named future. The future object represents a priority of certain entity (represented by registrant of the future) to register certain domain (which name is the name of the future) in case when the domain name becomes available for registration. The future objects can be maintained by clients using the same set of commands that is supported for domains, hosts and contacts. This draft contains detailed description of these commands and their formal syntax is defined in accessible XML schema definition documents. To create a future logged in client issues command and provides the following data: - name of the future (i.e. name of the domain future will be created for), - contact ID of future.s registrant, - authorization information of the future, - maintenance period of the future. The command can succeed only if: - domain with given name exists in the system (note, that this doesn't imply that domain is registered), - all provided data - including domain name - conforms to the system policy. Whenever a lifecycle of a domain ends (i.e. domain is to be removed) system checks if there exists a future for domain's name. NASK [Page 5] Internet-Draft EPP parameters for .pl ccTLD October 2004 If the future does not exist, then domain is removed and its name is available for registration or reservation (unless for some reason it is prohibited by current system policy). Registration or reservation of this domain name starts the new lifecycle of the domain. In case when a future does exist for the domain name, then domain is removed as in previous case, but at the same time (i.e. in the same transaction) the system takes the following actions: - new domain reservation is created (instantiating new domain object lifecycle); registrant ID, client ID and authInfo for new domain are inherited from the future object, - future object is removed. After this, reserved domain can be registered with command (without element) just like domain reserved with command with element, with a few minor differences, described below. Note, that domain reserved as a result of "future transformation" has no name servers, name server names must be provided while registering domain using command, as well as other missing and required for avery registered domain data: - period - reason - contacts Also note, that reservation period of domain initiated by future object is defined by system policy and may be different than reservation period for domain reserved using command with element. 3.1 command 3.1.1 Arguments - one or more elements containing the future names. 3.1.2 Description The purpose of the command is to anticipate (give a hint) if command issued by logged in client for given future names will succeed. For every future name provided in element the system checks if: - the future does not exist, NASK [Page 6] Internet-Draft EPP parameters for .pl ccTLD October 2004 - creating futures in given zone is allowed, - domain name is not forbidden for registration, - domain exists. 3.1.3 Response For every element provided in request the response contains corresponding element containing the following elements: - element containing the future name having avail attribute informing, whether or not it is possible for logged in client to create the future using command; value 1 or true indicates that it is possible to create the future, value 0 or false indicates that it is no possible to create the future, - optional element present only when value of avail attribute is 0 or false containing code of reason that describes why creation of the future is not possible. 3.1.4 Example Request: ala.pl ela.com.pl ola.org ABC-12345 Response: NASK [Page 7] Internet-Draft EPP parameters for .pl ccTLD October 2004 Command completed successfully ala.pl ela.com.pl 4005 ola.org 4012 ABC-12345 54322-XYZ 3.2 command 3.2.1 Arguments - element containing the future name, - element containing period of time to create future for, that contains unit attribute with value of y or m describing units (year or month respectively) period is expressed in, - element containing the future registrant identifier, - element containing the future authorization information. NASK [Page 8] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.2.2 Description The purpose of the command is to create the future for domain . The purpose of the future object itself is to automatically trigger reservation of the domain for the registrant of the future, when the domain name will became available for registration. Detailed description of this subject can be found in chapter "Domain and Future Object States". The command will fail unless: - all conditions checked during command are satisfied, - element contains identifier of existing contact, - value of element conforms to the system policy, - length of element.s value conforms to the system policy. 3.2.3 Response The response contains element containing the following elements: - element containing the future name, - element containing the date of the future creation, - element containing the date of the future expiration. 3.2.4 Example Request: example.pl 3 jd1234 NASK [Page 9] Internet-Draft EPP parameters for .pl ccTLD October 2004 2fooBAR ABC-12345 Response: Command completed successfully example.pl 1999-04-03T22:00:00.0Z 2002-04-03T22:00:00.0Z ABC-12345 54321-XYZ 3.3 command 3.3.1 Arguments - element containing the future name, - optional element containing the future authorization information. 3.3.2 Description The purpose of the command is to retrieve information about the future. NASK [Page 10] Internet-Draft EPP parameters for .pl ccTLD October 2004 The command will fail unless: - the future exists, - if element is present in request, then it contains valid authorization information, - if element is not present in request, then logged in client is sponsoring client of the future. 3.3.3 Response The response contains element containing the following elements: - element containing the future name, - element containing future system identifier, - element containing the future registrant identifier, - element containing identifier of the future sponsoring client, - element containing identifier of client who created the future, - element containing the date of the future creation, - element containing the date of the future expiration, - element containing identifier of client who made last update to the future (element is not present if the future has never been updated), - element containing the date of last update to the future (element is not present if the future has never been updated), - element containing the date of last transfer of the future (element is not present if the future has never been transferred), - element containing the future authorization information, - element containing length of current maintenance period of the future. NASK [Page 11] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.3.4 Example Request: example.pl 2fooBAR ABC-12345 Response: Command completed successfully example.pl EXAMPLE1-REP jd1234 ClientX ClientY 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2005-04-03T22:00:00.0Z 2000-04-08T09:00:00.0Z NASK [Page 12] Internet-Draft EPP parameters for .pl ccTLD October 2004 2fooBAR ABC-12345 54322-XYZ 3.4 3.4.1 Arguments - element containing the future name, - element containing the following elements: o optional element containing the future registrant identifier, o optional element containing the future authorization information. 3.4.2 Description The purpose of the command is to update some of the following data of the future: - registrant of the future, - authorization information of the future. The command will fail unless: - element contains at least one child element, - the future exists in the system, - logged in client is sponsoring client for the future, - if element is present in request, then it contains existing contact identifier, - if element is present in request, then length of its value conforms to the system policy. 3.4.3 Response No specific information. NASK [Page 13] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.4.4 Example Request: example7.pl mak21 2BARfoo ABC-12345 Response: Command completed successfully ABC-12345 54321-XYZ 3.5 command 3.5.1 Arguments - element containing the future name, NASK [Page 14] Internet-Draft EPP parameters for .pl ccTLD October 2004 - element containing the future authorization information. 3.5.2 Description The purpose of the command is to change the future sponsoring client to the logged in client. The system informs the future registrant about transfer via email and the previous sponsoring client of future using poll mechanism. The command will fail unless: - the future exists, - logged in client is not sponsoring client of the future, - element contains valid authorization information. Note: NASK-EPP does not support authorization of transfer operation with authorization information of object other than object to be transferred. This implies, that roid attribute of element should not be provided with transfer command. 3.5.3 Response Response contains element containing the following elements: - element containing the future name, - element containing value serverApproved, - element containing identifier of client who requested transfer, - element containing the date of issuing transfer command, - element containing constant string defined by the system policy, - element containing the date of approval of transfer by the system, - element containing the date of the future expiration. 3.5.4 Example Request: NASK [Page 15] Internet-Draft EPP parameters for .pl ccTLD October 2004 example.pl 2fooBAR ABC-12345 Response: Command completed successfully example.pl serverApproved ClientX 2000-06-08T22:00:00.0Z ClientY 2000-06-13T22:00:00.0Z 2002-09-08T22:00:00.0Z ABC-12345 54322-XYZ NASK [Page 16] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.6 command Command not implemented. 3.7 command Command not implemented. 4. Examples Example 1: Processing of the command with provided book element przyklad44.pl ns.przyklad2.pl ns5.przyklad.pl authinfo_of_d97 nice name ABC-12345 Example 2: System answer to the command with provided book element NASK [Page 17] Internet-Draft EPP parameters for .pl ccTLD October 2004 Command completed successfully przyklad44.pl 1999-04-03T22:00:00.0Z 1999-18-03T22:00:00.0Z ABC-12345 54321-XYZ Example 3: Processing of the command ns1.example.tld 192.1.2.3 198.1.2.3 1080:0:0:0:8:800:200417A ABC-12345 Example 4: System answer to the command NASK [Page 18] Internet-Draft EPP parameters for .pl ccTLD October 2004 Command completed successfully ns1.example.tld 1999-04-03T22:00:00.0Z ABC-12345 54322-XYZ Example 5: Processing of the command ns1.example.tld ABC-12345 Example 6: System answer to the command Command completed successfully NASK [Page 19] Internet-Draft EPP parameters for .pl ccTLD October 2004 ns1.example.tld NS1_EXAMPLE1-REP 192.1.2.3 198.1.2.3 1080:0:0:0:8:800:200417A ClientY ClientX 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2000-04-08T09:00:00.0Z ABC-12345 54322-XYZ Example 7: Processing of the command ns1.example.tld 192.3.2.1 1080:0:0:0:8:800:200417A ns2.example.tld NASK [Page 20] Internet-Draft EPP parameters for .pl ccTLD October 2004 ABC-12345 Example 8: System answer to the command Command completed successfully ABC-12345 54321-XYZ Example 9: Processing of the command sh8013 11John Doe Example Inc. 123 Example Dr. Suite 100 Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 jdoe@example.tld NASK [Page 21] Internet-Draft EPP parameters for .pl ccTLD October 2004 2fooBAR 1 1 ABC-12345 Example 10: System answer to the command Command completed successfully sh8013 1999-04-03T22:00:00.0Z ABC-12345 54321-XYZ NASK [Page 22] Internet-Draft EPP parameters for .pl ccTLD October 2004 Example 11: Processing of the command 666666 2fooBAR ABC-12345 Example 12: System answer to the command Command completed successfully sh8013 SH8013-REP NASK [Page 23] Internet-Draft EPP parameters for .pl ccTLD October 2004 John Doe Example Inc. 123 Example Dr. Suite 100 Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 jdoe@example.tld ClientY ClientX 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2000-04-08T09:00:00.0Z 2fooBAR ABC-12345 54322-XYZ Example 13: Processing of the command sh8013 NASK [Page 24] Internet-Draft EPP parameters for .pl ccTLD October 2004 124 Example Dr. Suite 200 Dulles VA 20166-6503 US +1.7034444444 1 ABC-12345 Example 14: System answer to the command Command completed successfully ABC-12345 54321-XYZ NASK [Page 25] Internet-Draft EPP parameters for .pl ccTLD October 2004 5. Formal syntax Extdom-1.0.xsd: NASK Extensible Provisioning Protocol v1.0 domain extension. NASK [Page 26] Internet-Draft EPP parameters for .pl ccTLD October 2004 Extcon-1.0.xsd: NASK Extensible Provisioning Protocol v1.0 contact extension. NASK [Page 27] Internet-Draft EPP parameters for .pl ccTLD October 2004 6. EPP and IDN registration IDN registration in NASK has no impact on EPP implementation and function. The same is true of the other registry activities like whois and invoicing. The following excerpt from NASK's IDN registration policy will make it clear. The Policy of the IDN-registration under .PL is liberal and is based on the following concepts: - NASK accepts only the proper ACE labels (according to [9], [12] and [13]) which begin with the "xn--" prefix and contain only ASCII characters, - the received string after the ToUnicode operation (according to Section 4.2 of [10] and Section 6.2 of [9]) applied to the ACE label MUST only include code points [11] from one of the defined character sets. Each character set include characters (code points) derived from Unicode repertoire and representing the same script i.e. latin, cyrillic etc. (Code points are chosen by Registry.) Therefore, there are the following sets: arabic set, cyrillic set, greek set, hebrew set and latin set. - A combination of characters from different sets is not allowed. The following pictogram presents the processing of an IDN into an ACE form acceptable by NASK for registration. <------------- ToUnicode ---------------------- --------------- | internationalized | | ACE label + | | domain name | --NAMEPREP--> ---PUNYCODE--> | FULL STOP + | | IDN | +"xn--" | zone | ---------------------- --------------- -------------> ToASCII NASK [Page 28] Internet-Draft EPP parameters for .pl ccTLD October 2004 To have more actual and up-to-date information on IDNs in NASK refer to http://www.idn.pl. 7. Security Considerations This document does not require any special security considerations except those mentioned in documents [1], [2], [3], [4], [5], [6], [7]. 8. References [1] S. Hollenbeck "Generic Registry-Registrar Protocol Requirements", September 2002, RFC 3375. [2] S. Hollenbeck "Extensible Provisioning Protocol", August 2002, Internet-Draft. [3] S. Hollenbeck "Extensible Provisioning Protocol Contact Mapping", August 2002, Internet-Draft. [4] S. Hollenbeck "Extensible Provisioning Protocol Domain Name Mapping", August 2002, Internet-Draft. [5] S. Hollenbeck "Extensible Provisioning Protocol Host Mapping", August 2002, Internet-Draft. [6] S. Hollenbeck "Extensible Provisioning Protocol Transport Over TCP", August 2002, Internet-Draft. [7] S. Hollenbeck "Guidelines for Extending the Extensible Provisioning Protocol", October 2002, Internet-Draft. [8] P. Hoffman, and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [9] A. Costello, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [10] P. Faltstrom, P. Hoffman, and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [11] The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/unicode/standard/standard.html [12] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [13] P. Mockapetris, "Domain Names - Implementation and Specification," RFC-1035, November 1987. NASK [Page 29] Internet-Draft EPP parameters for .pl ccTLD October 2004 9. Authors' Addresses Patrycja Wegrzynowicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: patrycjaw@nask.pl Kuba Laszkiewicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: jakubl@nask.pl Juliusz Brzostek NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: juliuszb@nask.pl Tomek Zygmuntowicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: tomekz@nask.pl Witold Zarowski NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: witzar@nask.pl Andrzej Bartosiewicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: andrzejb@nask.pl Krzysztof Olesik NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: kolesik@nask.pl NASK [Page 30] Internet-Draft EPP parameters for .pl ccTLD October 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. NASK [Page 31] Internet-Draft Tomek Zygmuntowicz Expires: April 2005 Patrycja Wegrzynowicz Kuba Laszkiewicz Juliusz Brzostek Witold Zarowski Andrzej Bartosiewicz Krzysztof Olesik NASK October 2004 EPP parameters for .pl ccTLD draft-zygmuntowicz-epp-pltld-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been disclosed, and any of which he or she becomes aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document is a proposed description of the cooperation protocol between NASK and its Partners. The proposal can be replaced with the new document or can be invalidated. The content of this proposal relates to the documents: , , , , RFC 3375 published by Internet Engineering Task Force. NASK [Page 1] Internet-Draft EPP parameters for .pl ccTLD October 2004 Table of Contents 1. Introduction ................................................ 2 2. EPP modifications ........................................... 2 2.1 element ....................................... 2 2.2 element ............................... 3 2.3 element - optional .................................. 3 2.4 element ............................................... 3 2.5 and commands ............ 4 2.6 command ........................................ 4 2.7 command ........................................ 4 2.8 command ........................................ 4 2.9 command .......................................... 4 2.10 command ....................................... 5 2.11 command ...................................... 5 3. The future extension .......................................... 5 3.1 command ....................................... 6 3.2 command ...................................... 8 3.3 command ........................................ 10 3.4 command ...................................... 13 3.5 command .................................... 14 3.6 command ....................................... 17 3.7 command ...................................... 17 4. Examples ...................................................... 17 5. Formal syntax ................................................. 26 6. EPP and IDN Registration ...................................... 28 7. Security Considerations ....................................... 29 8. References .................................................... 29 9. Authors Addresses ............................................. 30 10. Full Copyright Statement ..................................... 31 1. Introduction The Extensible Provisioning Protocol (EPP, [2]) describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. The intent of this document is to specify the protocol elements in EPP extensions in order to accomodate additional information required for a registrar to interconnect with the .pl ccTLD registry via an EPP-compatible interface. 2. EPP modifications 2.1 element The element has been added to commands: , and . It specifies whether the contact represents a private person. NASK [Page 2] Internet-Draft EPP parameters for .pl ccTLD October 2004 2.2 element The element has been added to commands: , , and . It specifies, for a contact representing a private person, whether this person gave its assent for publishing personal details in WHOIS database. The element has no meaning for a contact which does not represent a private person. 2.3 - optional The element has been added to command. It includes a justification of registrant's rights to a domain. 2.4 element The element has been added to the command. Successfully processed command with provided element causes a reservation of a domain in the system. Successfully processed command with not provided element causes a registration of a domain in the system. The only operation which can be performed on the reserved domain is registration by the client which had reserved the domain. If the client which reserved a domain does not register the domain before expiration of reservation period (the reservation period is determined by parameters of the system) then a possibility of a reservation and a registration of the domain is blocked for a random period (this period is determined by parameters of the system). The domain will be available for reservation and registration after expiration of blockade period. Note that reservation of a domain prior to reservation of this domain is not obligatory. The following rules of providing domain's data for command are an necessary condition of a successful domain registration: - registrant's ID contained in element and the domain name rights justification contained in element must be provided only once: either during a domain reservation or registration. - a domain validity period contained in element must be provided only once: either during a domain reservation or registration. When the domain validity period is not provided, the system sets a default value which is determined by system's parameters. - domain authorization data contained in element must be provided during a domain reservation and registration. Both values must be identical. NASK [Page 3] Internet-Draft EPP parameters for .pl ccTLD October 2004 - name servers contained in elements can be provided only once, with the first command. The number of provided name servers must meet the rules specified by parameters of the system. - identifiers of contacts associated with a domain contained in elements can be given only once: either during a domain reservation or registration. Given list of contacts must meet the rules specified by parameters of the system. Providing no elements neither during a registration nor reservation is possible only when the parameters of the system allow for the zero number of contacts to be associated with a domain. 2.5 and commands A transfer of a domain or a contact does not require confirmation of sponsoring client of that object. A result of a transfer command is returned directly in response to or command with option op=request (status serverApproved is set in case of successful processing of transfer command). Options of the and commands other than request are not supported. 2.6 command It is possible to delete a host using the command, even if there are domains delegated to that host, on the condition that the host is not configured for any domain which is delegated to this host. A side effect of a removal of a host is removal of all delegations to that host. 2.7 command Using the command it is possible to create a host which belongs to a zone maintained by Registry (NASK) and for which no superordinate domain exists. Such created host has the pendingCreate status. It will be removed from the system if the superordinate domain is not reserved or registered before expiration of a period determined by the system parameters. 2.8 command A change of a host's name is forbidden. A providing of the element in the element causes failure of the command. 2.9 command The command returns full set of information only for sponsoring client, for other clients operation fails. NASK [Page 4] Internet-Draft EPP parameters for .pl ccTLD October 2004 2.10 command The command returns full set of information only for sponsoring client of a domain and client which provided a correct authorization information in the element. In other cases command fails. 2.11 command The command returns full set of information only to sponsoring client of a domain and to client who provided a correct authorization information of domain in the element. Furthermore, if contact represents a private person (individual=1) who consents to publish his/her personal details (consentForPublishing=1) then information is returned to the others clients. In other cases command fails. 3. The future extension NASK EPP extends EPP by introducing a new type of object named future. The future object represents a priority of certain entity (represented by registrant of the future) to register certain domain (which name is the name of the future) in case when the domain name becomes available for registration. The future objects can be maintained by clients using the same set of commands that is supported for domains, hosts and contacts. This draft contains detailed description of these commands and their formal syntax is defined in accessible XML schema definition documents. To create a future logged in client issues command and provides the following data: - name of the future (i.e. name of the domain future will be created for), - contact ID of future.s registrant, - authorization information of the future, - maintenance period of the future. The command can succeed only if: - domain with given name exists in the system (note, that this doesn't imply that domain is registered), - all provided data - including domain name - conforms to the system policy. Whenever a lifecycle of a domain ends (i.e. domain is to be removed) system checks if there exists a future for domain's name. NASK [Page 5] Internet-Draft EPP parameters for .pl ccTLD October 2004 If the future does not exist, then domain is removed and its name is available for registration or reservation (unless for some reason it is prohibited by current system policy). Registration or reservation of this domain name starts the new lifecycle of the domain. In case when a future does exist for the domain name, then domain is removed as in previous case, but at the same time (i.e. in the same transaction) the system takes the following actions: - new domain reservation is created (instantiating new domain object lifecycle); registrant ID, client ID and authInfo for new domain are inherited from the future object, - future object is removed. After this, reserved domain can be registered with command (without element) just like domain reserved with command with element, with a few minor differences, described below. Note, that domain reserved as a result of "future transformation" has no name servers, name server names must be provided while registering domain using command, as well as other missing and required for avery registered domain data: - period - reason - contacts Also note, that reservation period of domain initiated by future object is defined by system policy and may be different than reservation period for domain reserved using command with element. 3.1 command 3.1.1 Arguments - one or more elements containing the future names. 3.1.2 Description The purpose of the command is to anticipate (give a hint) if command issued by logged in client for given future names will succeed. For every future name provided in element the system checks if: - the future does not exist, NASK [Page 6] Internet-Draft EPP parameters for .pl ccTLD October 2004 - creating futures in given zone is allowed, - domain name is not forbidden for registration, - domain exists. 3.1.3 Response For every element provided in request the response contains corresponding element containing the following elements: - element containing the future name having avail attribute informing, whether or not it is possible for logged in client to create the future using command; value 1 or true indicates that it is possible to create the future, value 0 or false indicates that it is no possible to create the future, - optional element present only when value of avail attribute is 0 or false containing code of reason that describes why creation of the future is not possible. 3.1.4 Example Request: ala.pl ela.com.pl ola.org ABC-12345 Response: NASK [Page 7] Internet-Draft EPP parameters for .pl ccTLD October 2004 Command completed successfully ala.pl ela.com.pl 4005 ola.org 4012 ABC-12345 54322-XYZ 3.2 command 3.2.1 Arguments - element containing the future name, - element containing period of time to create future for, that contains unit attribute with value of y or m describing units (year or month respectively) period is expressed in, - element containing the future registrant identifier, - element containing the future authorization information. NASK [Page 8] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.2.2 Description The purpose of the command is to create the future for domain . The purpose of the future object itself is to automatically trigger reservation of the domain for the registrant of the future, when the domain name will became available for registration. Detailed description of this subject can be found in chapter "Domain and Future Object States". The command will fail unless: - all conditions checked during command are satisfied, - element contains identifier of existing contact, - value of element conforms to the system policy, - length of element.s value conforms to the system policy. 3.2.3 Response The response contains element containing the following elements: - element containing the future name, - element containing the date of the future creation, - element containing the date of the future expiration. 3.2.4 Example Request: example.pl 3 jd1234 NASK [Page 9] Internet-Draft EPP parameters for .pl ccTLD October 2004 2fooBAR ABC-12345 Response: Command completed successfully example.pl 1999-04-03T22:00:00.0Z 2002-04-03T22:00:00.0Z ABC-12345 54321-XYZ 3.3 command 3.3.1 Arguments - element containing the future name, - optional element containing the future authorization information. 3.3.2 Description The purpose of the command is to retrieve information about the future. NASK [Page 10] Internet-Draft EPP parameters for .pl ccTLD October 2004 The command will fail unless: - the future exists, - if element is present in request, then it contains valid authorization information, - if element is not present in request, then logged in client is sponsoring client of the future. 3.3.3 Response The response contains element containing the following elements: - element containing the future name, - element containing future system identifier, - element containing the future registrant identifier, - element containing identifier of the future sponsoring client, - element containing identifier of client who created the future, - element containing the date of the future creation, - element containing the date of the future expiration, - element containing identifier of client who made last update to the future (element is not present if the future has never been updated), - element containing the date of last update to the future (element is not present if the future has never been updated), - element containing the date of last transfer of the future (element is not present if the future has never been transferred), - element containing the future authorization information, - element containing length of current maintenance period of the future. NASK [Page 11] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.3.4 Example Request: example.pl 2fooBAR ABC-12345 Response: Command completed successfully example.pl EXAMPLE1-REP jd1234 ClientX ClientY 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2005-04-03T22:00:00.0Z 2000-04-08T09:00:00.0Z NASK [Page 12] Internet-Draft EPP parameters for .pl ccTLD October 2004 2fooBAR ABC-12345 54322-XYZ 3.4 3.4.1 Arguments - element containing the future name, - element containing the following elements: o optional element containing the future registrant identifier, o optional element containing the future authorization information. 3.4.2 Description The purpose of the command is to update some of the following data of the future: - registrant of the future, - authorization information of the future. The command will fail unless: - element contains at least one child element, - the future exists in the system, - logged in client is sponsoring client for the future, - if element is present in request, then it contains existing contact identifier, - if element is present in request, then length of its value conforms to the system policy. 3.4.3 Response No specific information. NASK [Page 13] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.4.4 Example Request: example7.pl mak21 2BARfoo ABC-12345 Response: Command completed successfully ABC-12345 54321-XYZ 3.5 command 3.5.1 Arguments - element containing the future name, NASK [Page 14] Internet-Draft EPP parameters for .pl ccTLD October 2004 - element containing the future authorization information. 3.5.2 Description The purpose of the command is to change the future sponsoring client to the logged in client. The system informs the future registrant about transfer via email and the previous sponsoring client of future using poll mechanism. The command will fail unless: - the future exists, - logged in client is not sponsoring client of the future, - element contains valid authorization information. Note: NASK-EPP does not support authorization of transfer operation with authorization information of object other than object to be transferred. This implies, that roid attribute of element should not be provided with transfer command. 3.5.3 Response Response contains element containing the following elements: - element containing the future name, - element containing value serverApproved, - element containing identifier of client who requested transfer, - element containing the date of issuing transfer command, - element containing constant string defined by the system policy, - element containing the date of approval of transfer by the system, - element containing the date of the future expiration. 3.5.4 Example Request: NASK [Page 15] Internet-Draft EPP parameters for .pl ccTLD October 2004 example.pl 2fooBAR ABC-12345 Response: Command completed successfully example.pl serverApproved ClientX 2000-06-08T22:00:00.0Z ClientY 2000-06-13T22:00:00.0Z 2002-09-08T22:00:00.0Z ABC-12345 54322-XYZ NASK [Page 16] Internet-Draft EPP parameters for .pl ccTLD October 2004 3.6 command Command not implemented. 3.7 command Command not implemented. 4. Examples Example 1: Processing of the command with provided book element przyklad44.pl ns.przyklad2.pl ns5.przyklad.pl authinfo_of_d97 nice name ABC-12345 Example 2: System answer to the command with provided book element NASK [Page 17] Internet-Draft EPP parameters for .pl ccTLD October 2004 Command completed successfully przyklad44.pl 1999-04-03T22:00:00.0Z 1999-18-03T22:00:00.0Z ABC-12345 54321-XYZ Example 3: Processing of the command ns1.example.tld 192.1.2.3 198.1.2.3 1080:0:0:0:8:800:200417A ABC-12345 Example 4: System answer to the command NASK [Page 18] Internet-Draft EPP parameters for .pl ccTLD October 2004 Command completed successfully ns1.example.tld 1999-04-03T22:00:00.0Z ABC-12345 54322-XYZ Example 5: Processing of the command ns1.example.tld ABC-12345 Example 6: System answer to the command Command completed successfully NASK [Page 19] Internet-Draft EPP parameters for .pl ccTLD October 2004 ns1.example.tld NS1_EXAMPLE1-REP 192.1.2.3 198.1.2.3 1080:0:0:0:8:800:200417A ClientY ClientX 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2000-04-08T09:00:00.0Z ABC-12345 54322-XYZ Example 7: Processing of the command ns1.example.tld 192.3.2.1 1080:0:0:0:8:800:200417A ns2.example.tld NASK [Page 20] Internet-Draft EPP parameters for .pl ccTLD October 2004 ABC-12345 Example 8: System answer to the command Command completed successfully ABC-12345 54321-XYZ Example 9: Processing of the command sh8013 11John Doe Example Inc. 123 Example Dr. Suite 100 Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 jdoe@example.tld NASK [Page 21] Internet-Draft EPP parameters for .pl ccTLD October 2004 2fooBAR 1 1 ABC-12345 Example 10: System answer to the command Command completed successfully sh8013 1999-04-03T22:00:00.0Z ABC-12345 54321-XYZ NASK [Page 22] Internet-Draft EPP parameters for .pl ccTLD October 2004 Example 11: Processing of the command 666666 2fooBAR ABC-12345 Example 12: System answer to the command Command completed successfully sh8013 SH8013-REP NASK [Page 23] Internet-Draft EPP parameters for .pl ccTLD October 2004 John Doe Example Inc. 123 Example Dr. Suite 100 Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 jdoe@example.tld ClientY ClientX 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2000-04-08T09:00:00.0Z 2fooBAR ABC-12345 54322-XYZ Example 13: Processing of the command sh8013 NASK [Page 24] Internet-Draft EPP parameters for .pl ccTLD October 2004 124 Example Dr. Suite 200 Dulles VA 20166-6503 US +1.7034444444 1 ABC-12345 Example 14: System answer to the command Command completed successfully ABC-12345 54321-XYZ NASK [Page 25] Internet-Draft EPP parameters for .pl ccTLD October 2004 5. Formal syntax Extdom-1.0.xsd: NASK Extensible Provisioning Protocol v1.0 domain extension. NASK [Page 26] Internet-Draft EPP parameters for .pl ccTLD October 2004 Extcon-1.0.xsd: NASK Extensible Provisioning Protocol v1.0 contact extension. NASK [Page 27] Internet-Draft EPP parameters for .pl ccTLD October 2004 6. EPP and IDN registration IDN registration in NASK has no impact on EPP implementation and function. The same is true of the other registry activities like whois and invoicing. The following excerpt from NASK's IDN registration policy will make it clear. The Policy of the IDN-registration under .PL is liberal and is based on the following concepts: - NASK accepts only the proper ACE labels (according to [9], [12] and [13]) which begin with the "xn--" prefix and contain only ASCII characters, - the received string after the ToUnicode operation (according to Section 4.2 of [10] and Section 6.2 of [9]) applied to the ACE label MUST only include code points [11] from one of the defined character sets. Each character set include characters (code points) derived from Unicode repertoire and representing the same script i.e. latin, cyrillic etc. (Code points are chosen by Registry.) Therefore, there are the following sets: arabic set, cyrillic set, greek set, hebrew set and latin set. - A combination of characters from different sets is not allowed. The following pictogram presents the processing of an IDN into an ACE form acceptable by NASK for registration. <------------- ToUnicode ---------------------- --------------- | internationalized | | ACE label + | | domain name | --NAMEPREP--> ---PUNYCODE--> | FULL STOP + | | IDN | +"xn--" | zone | ---------------------- --------------- -------------> ToASCII NASK [Page 28] Internet-Draft EPP parameters for .pl ccTLD October 2004 To have more actual and up-to-date information on IDNs in NASK refer to http://www.idn.pl. 7. Security Considerations This document does not require any special security considerations except those mentioned in documents [1], [2], [3], [4], [5], [6], [7]. 8. References [1] S. Hollenbeck "Generic Registry-Registrar Protocol Requirements", September 2002, RFC 3375. [2] S. Hollenbeck "Extensible Provisioning Protocol", August 2002, Internet-Draft. [3] S. Hollenbeck "Extensible Provisioning Protocol Contact Mapping", August 2002, Internet-Draft. [4] S. Hollenbeck "Extensible Provisioning Protocol Domain Name Mapping", August 2002, Internet-Draft. [5] S. Hollenbeck "Extensible Provisioning Protocol Host Mapping", August 2002, Internet-Draft. [6] S. Hollenbeck "Extensible Provisioning Protocol Transport Over TCP", August 2002, Internet-Draft. [7] S. Hollenbeck "Guidelines for Extending the Extensible Provisioning Protocol", October 2002, Internet-Draft. [8] P. Hoffman, and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [9] A. Costello, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [10] P. Faltstrom, P. Hoffman, and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [11] The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/unicode/standard/standard.html [12] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [13] P. Mockapetris, "Domain Names - Implementation and Specification," RFC-1035, November 1987. NASK [Page 29] Internet-Draft EPP parameters for .pl ccTLD October 2004 9. Authors' Addresses Patrycja Wegrzynowicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: patrycjaw@nask.pl Kuba Laszkiewicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: jakubl@nask.pl Juliusz Brzostek NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: juliuszb@nask.pl Tomek Zygmuntowicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: tomekz@nask.pl Witold Zarowski NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: witzar@nask.pl Andrzej Bartosiewicz NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: andrzejb@nask.pl Krzysztof Olesik NASK ul. Wawozowa 18 02-796 Warszawa Poland Email: kolesik@nask.pl NASK [Page 30] Internet-Draft EPP parameters for .pl ccTLD October 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. NASK [Page 31]