Technical Integration Guide
Transcription
Technical Integration Guide
TECHNICAL INTEGRATION GUIDE – February 25th, 2013 1 Technical Integration Guide - Version 2.7 February 25th, 2013 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -1- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 2 Ta b l e o f c o n t e n t 1. Preface ............................................................................................... 5 1.1. About this document .....................................................................................5 1.2. Target audience .............................................................................................5 1.3. Typographical rules .......................................................................................5 1.4. Revisions history ...........................................................................................5 2. IDN ...................................................................................................... 6 2.1. Reference documents ...................................................................................6 2.2. Brief backgrounder on IDN technology .......................................................6 2.3. Warning ..........................................................................................................7 2.4. Terms and definitions....................................................................................7 2.5. Table of accepted characters .......................................................................8 2.6. Use of Unicode versions vs LDH versions ................................................ 10 3. EPP ................................................................................................... 10 3.1. Configuration and parameters.................................................................... 10 3.2. Major integration principles ........................................................................ 10 3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.2.5. No implementation of "host" objects (RFC 5732) ...................................................................... 10 Cases of operations with a 1000 return code and server behavior in case of problem ................ 10 Auth_info management ............................................................................................................... 11 Implementation choice of the notifications list ........................................................................... 11 DNSSEC support......................................................................................................................... 11 3.3. Implemented commands ............................................................................. 13 3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5. The <greeting> ............................................................................................................................ 13 The <hello> command ................................................................................................................ 14 Session management commands ................................................................................................. 14 Interrogation commands .............................................................................................................. 17 Object Update commands ........................................................................................................... 18 3.4. Managing a domain name ........................................................................... 19 3.4.1. 3.4.2. 3.4.3. 3.4.4. 3.4.5. 3.4.6. 3.4.7. 3.4.8. Create – create a domain name.................................................................................................... 19 Update – modify a domain name attributes ................................................................................. 24 Delete – Delete a domain name ................................................................................................... 32 Restore – Domain name restore .................................................................................................. 33 Transfer – Registrar change ........................................................................................................ 34 Trade – Holder change (Transmission) ....................................................................................... 44 Recover – Forced domain name transmission ............................................................................. 51 Checking a domain availability ................................................................................................... 54 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -2- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 3 3.4.9. Retrieve domain data ................................................................................................................... 57 3.5. Managing a contact ..................................................................................... 63 3.5.1. 3.5.2. 3.5.3. 3.5.4. 3.5.5. Contact Creation .......................................................................................................................... 63 Modifying a contact .................................................................................................................... 70 Deleting a contact ........................................................................................................................ 71 Identification of a contact holder................................................................................................. 71 Retrieve data of a contact ............................................................................................................ 72 3.6. Notifications ................................................................................................. 74 3.6.1. Managing the notification queue ................................................................................................. 74 3.6.2. Asynchronous notifications ......................................................................................................... 75 3.6.3. Exogenous notifications .............................................................................................................. 80 3.7. Return codes and error messsages ........................................................... 97 3.7.1. Return codes ................................................................................................................................ 97 3.7.2. Error messages .......................................................................................................................... 100 3.8. RFCs ........................................................................................................... 101 4. Web interface : the ticket system ..................................................102 4.1. General principles on tickets .................................................................... 102 4.2. Ticket format .............................................................................................. 102 4.3. Description of all the tickets ..................................................................... 102 5. Operations that can only be handled by email/fax .......................112 5.1. Authorization code generation ................................................................. 112 5.2. Trade validation ......................................................................................... 113 5.3. Notification of Monitoring of the Qualification Procedure ..................... 113 5.4. Notification of Suspension, Blocking and Deletion of Domain Name Portfolio ......................................................................................................... 114 5.5. Substantiation email .................................................................................. 115 6. DAS (Domain Availability Service) ................................................116 6.1. Parameters to interrogate the service...................................................... 116 6.2. The information available.......................................................................... 116 6.2.1. 6.2.2. 6.2.3. 6.2.4. 6.2.5. Validity of the domain tested .................................................................................................... 116 domain name ............................................................................................................................. 116 State of DNS publication .......................................................................................................... 117 Information on restrictions relating to this domain name .......................................................... 117 Key dates on existing domain names ........................................................................................ 117 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -3- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 4 6.3. DAS and IDN ............................................................................................... 117 6.4. Examples .................................................................................................... 118 6.4.1. 6.4.2. 6.4.3. 6.4.4. 6.4.5. 6.4.6. 6.4.7. 6.4.8. 6.4.9. Domain name that does not exist and is not subject to any restrictions .................................... 118 Domain name subject to prior review ....................................................................................... 119 Fanciful domain name ............................................................................................................... 119 Domain name that exists and is not subject to any restrictions ................................................. 120 Deleted domain name in redemption period.............................................................................. 120 Existing domain name and subject to prior review ................................................................... 121 Query on different domains with different ................................................................................ 122 IDN query in its Unicode form .................................................................................................. 123 IDN query in its ACE form ....................................................................................................... 123 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -4- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 5 Technical Integration Guide 1. Preface 1.1. About this document This integration guide contains all of the information required to implement the AFNIC domain management application interface. This interface offers two different ways accesses: • Web interface, • EPP (Extensible Provisioning Protocol): standard exchange protocol between a registry and its registrars. In regards to EPP, AFNIC has respected the standard described in the RFCs (see § 3.8 RFCs.). This document only describes the specific points of AFNIC's implementation of the protocol. 1.2. Target audience This document is a technical document for developers that wish to have a detailed description of the interface and examples to help them with the integration. It does not go over the procedures again (See Procedure Manual www.afnic.fr/en/ressources/reference/technical-guidebooks/proceduresmanual-for-registrars.html) nor The Naming Charter (www.afnic.fr/en/ressources/reference/charters/). Both documents are considered as already known. 1.3. Typographical rules Throughout the document we write: Between < > the xml markups describing the epp requests In a blue frame, examples of EPP requests. 1.4. Revisions history 24/11/2009 - V1.0 08/04/2010 - V1.1 08/06/2010 - V1.2 - Addition of missing EPP notifications 31/08/2010 - V1.3 – Addition of EPP notification Portfolio deletion Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -5- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 6 19/11/2010 - V1.35 – “Optional” instead “Mandatory” in the 5b and 5c lines in the § 4.3.1. 2.5.0 form semantics 07/02/2011 – V1.5 - Adding DNSSEC support in EPP in the server version 1.1 03/03/2011 – V1.55 – Correction of the greeting example § 3.3.1 06/12/2011 – V2.0 - Remove the mail interface, changes in the EPP interface following the opening to Europe and the ultra-marine country-code Top Level Domains - stop of the identification - opening of the qualification. 03/07/2012 – V2.5 - Addition of the § concerning the IDN and the DAS. 17/12/2012 – v2.6 – Remove of ZoneCheck 25/02/2013 – v2.7 – Remove of serverRestoreProhibited 2. IDN 2.1. Reference documents The implementation of IDNs at AFNIC is based on the IDNA2008 standard, and the following reference documents. • Definitions and protocol: • RFC 5890 (08/2010 23 pages): Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework • RFC 5891 (08/2010 17 pages): Internationalized Domain Names in Applications (IDNA): Protocol • RFC 5892 (08/2010 70 pages): The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) • RFC 5894 (08/2010 43 pages): Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale • Punycode encoding algorithm: • RFC 3492 (03/2003 35 pages) : Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) 2.2. Brief backgrounder on IDN technology The DNS protocol was not originally defined to be restricted to a set of characters. It is its use and other limitations of "the age" (the protocol is 30 years old) that have resulted in the definition of the syntactic rules we know today. The purpose of the IDNA2008 standard is to reconcile human needs and technical constraints by allowing the use of all forms of writing in domain names. All these forms of writing and the characters they use are defined and grouped together under a standard called Unicode. Since the syntactic rules for domain names require the use of single letters of the Latin alphabet ("a" to "z"), as well as numbers, hyphens, and periods to separate labels, a mechanism for the canonical formation of Unicode domain names and for encoding them has been developed to create names consistent with these rules. While in applications such as web browsers, Unicode names will be displayed, their DNS resolution will be performed using their encoded form (this is normally transparent to the user who should not have to handle this type of domain name). Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -6- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 7 2.3. Warning Although its impact may seem small, it is important to note that AFNIC implements the IDNA2008 standard, which slightly differs from the IDNA2003 standard. With respect to the processing of the characters included, the German Eszett (ß) is encoded, not transformed into "ss" as in the previous version of the IDN standard. In addition, the canonicalization step (nameprep) has disappeared, which will have some impact on the use of our interfaces. Each AFNIC application is now free to apply its own rules in this respect. Besides the fact that Unicode domain names must be in Normal Form C, we have chosen to allow the entry of capitals (to ensure backward compatibility with current uses) but their lower-case equivalents will actually be taken into account by the system (note that the Eszett is only accepted in its lower-case form). For example, the domain name "Thé-ou-Café.fr" is not legal in accordance with the IDNA2008 standard. We shall accept it, however once it has been standardized as "thé-ou-café.fr". With more "exotic" alphabets than the Latin, the problem will no doubt be more complex, but as long as AFNIC continues to use the characters indicated in the list below in this document, their canonical form will continue to apply. 2.4. Terms and definitions • • • • • • • • • • • • Unicode: Standard enabling any character in any form of writing to be encoded in a unique fashion (Unicode on Wikipedia). UTF-8: One of the encoding formats used to encode Unicode characters. ISO-8859-15: One of the ISO 8-bit encoding standards of the Latin alphabet. Also known as latin9. LatinX: Other names of certain ISO standards. Unlike Latin1, Latin9 includes the ligation "e in o". LDH: "LETTER-DIGIT-HYPHEN" the only ASCII characters authorized for the composition of a label in a domain name. ASCII: "American Standard Code for Information Interchange", the oldest computer standard for encoding characters. Strictly speaking 7-bit, it can only encode 128 characters. ACE: "ASCII Compatible Encoding" is the encoded version of a domain name in its LDH form (xn-caf-dma in Punycode, i.e. its "A-label form"). IDN: "Internationalized Domain Name", containing characters other than ASCII characters alone. Canonicalization: The canonical formation of a string of characters. For example, in Latin, putting a string of characters in their lower-case form is one of the operations that can be involved in a canonicalization process. Normal Form C: Normal form requiring that the characters be (pre)composed. A character corresponds to a unique code point. This exclude characters obtained by using diacritical marks combined with base characters. Code point: Single index associated with a character. Glyph: Graphical representation of a character Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -7- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • 8 NAMEPREP: Defines the version in canonical form of a Unicode domain name (was part of IDNA2003, no longer exists in IDNA2008). Punycode: Reversible and unique algorithm, used to transform a canonicalized IDN into its ACE form. 2.5. Table of accepted characters The following table represents the set of characters may be used to compose the label of a domain name. Historically, only the first 37 characters in this table were allowed, but as of May 3, 2012, it will be possible to use 30 new characters in the composition of the labels of domain names. The "ASCII equivalent" column is special in that it will only be meaningful during the sunrise period (note that sometimes the ASCII equivalent of a Unicode character is a group of two characters). This will be detailed a little later in this document. # Code point 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 U+002D U+0030 U+0031 U+0032 U+0033 U+0034 U+0035 U+0036 U+0037 U+0038 U+0039 U+0061 U+0062 U+0063 U+0064 U+0065 U+0066 U+0067 U+0068 U+0069 U+006A U+006B U+006C U+006D U+006E U+006F U+0070 ASCII equivalent Glyph Name 0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j k l m n o p HYPHEN-MINUS SIGN DIGIT ZERO DIGIT ONE DIGIT TWO DIGIT THREE DIGIT FOUR DIGIT FIVE DIGIT SIX DIGIT SEVEN DIGIT EIGHT DIGIT NINE LATIN SMALL LETTER A LATIN SMALL LETTER B LATIN SMALL LETTER C LATIN SMALL LETTER D LATIN SMALL LETTER E LATIN SMALL LETTER F LATIN SMALL LETTER G LATIN SMALL LETTER H LATIN SMALL LETTER I LATIN SMALL LETTER J LATIN SMALL LETTER K LATIN SMALL LETTER L LATIN SMALL LETTER M LATIN SMALL LETTER N LATIN SMALL LETTER O LATIN SMALL LETTER P 0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j k l m n o p Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -8- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 U+0071 U+0072 U+0073 U+0074 U+0075 U+0076 U+0077 U+0078 U+0079 U+007A U+00DF U+00E0 U+00E1 U+00E2 U+00E3 U+00E4 U+00E5 U+00E6 U+00E7 U+00E8 U+00E9 U+00EA U+00EB U+00EC U+00ED U+00EE U+00EF U+00F1 U+00F2 U+00F3 U+00F4 U+00F5 U+00F6 U+00F9 U+00FA U+00FB U+00FC U+00FD U+00FF U+0153 q r s t u v w x y z ß à á â ã ä å æ ç è é ê ë ì í î ï ñ ò ó ô õ ö ù ú û ü ý ÿ œ LATIN SMALL LETTER Q LATIN SMALL LETTER R LATIN SMALL LETTER S LATIN SMALL LETTER T LATIN SMALL LETTER U LATIN SMALL LETTER V LATIN SMALL LETTER W LATIN SMALL LETTER X LATIN SMALL LETTER Y LATIN SMALL LETTER Z LATIN SMALL LETTER SHARP S LATIN SMALL LETTER A WITH GRAVE LATIN SMALL LETTER A WITH ACUTE LATIN SMALL LETTER A WITH CIRCUMFLEX LATIN SMALL LETTER A WITH TILDE LATIN SMALL LETTER A WITH DIAERESIS LATIN SMALL LETTER A WITH RING ABOVE LATIN SMALL LETTER AE LATIN SMALL LETTER C WITH CEDILLA LATIN SMALL LETTER E WITH GRAVE LATIN SMALL LETTER E WITH ACUTE LATIN SMALL LETTER E WITH CIRCUMFLEX LATIN SMALL LETTER E WITH DIAERESIS LATIN SMALL LETTER I WITH GRAVE LATIN SMALL LETTER I WITH ACUTE LATIN SMALL LETTER I WITH CIRCUMFLEX LATIN SMALL LETTER I WITH DIAERESIS LATIN SMALL LETTER N WITH TILDE LATIN SMALL LETTER O WITH GRAVE LATIN SMALL LETTER O WITH ACUTE LATIN SMALL LETTER O WITH CIRCUMFLEX LATIN SMALL LETTER O WITH TILDE LATIN SMALL LETTER O WITH DIAERESIS LATIN SMALL LETTER U WITH GRAVE LATIN SMALL LETTER U WITH ACUTE LATIN SMALL LETTER U WITH CIRCUMFLEX LATIN SMALL LETTER U WITH DIAERESIS LATIN SMALL LETTER Y WITH ACUTE LATIN SMALL LETTER Y WITH DIAERESIS LATIN SMALL LIGATURE OE 9 q r s t u v w x y z ss a a a a a a ae c e e e e i i i i n o o o o o u u u u y y oe Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr -9- Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 10 2.6. Use of Unicode versions vs LDH versions Domain names are present in the server names, in the URL, and in the email addresses: here are the forms accepted by AFNIC interfaces. Detailed error messages will be returned in cases of non-compliance with these rules. • Domain name: • EPP interface: the only acceptable form for domain names is the LDH form, i.e. the ACE version for IDNs. Web interface: Unicode version and LDH version are accepted. Server name: ONLY the LDH version is acceptable. URL: ONLY the LDH version is acceptable. E-Mail: ONLY the LDH version is acceptable. • • • • 3. EPP 3.1. Configuration and parameters EPP production bed : • epp.nic.fr • port : 700 • access authentified by a certificate • number of connexions available : 2 • IP adresses that can access the server : 2 • available accounts : 1 EPP test bed : • epp.sandbox.nic.fr • port : 700 • access authentified by a certificate • number of connexions available : 4 • IP adresses that can access the server : unlimited • available accounts : 2 3.2. Major integration principles Besides the EPP standard as described in the RFCs, AFNIC has added several integration principles that are good to be aware of before developing an EPP client. 3.2.1. No implementation of "host" objects (RFC 5732) As this concept is rather remote from the way AFNIC manages name servers, we have chosen that the name servers should be domain name attributes. 3.2.2. Cases of operations with a 1000 return code and server behavior in case of problem Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 10 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 11 A precaution is necessary during the development of clients that connect to our EPP server. Indeed, we indicate several times in the following pages that some operations will answer with a 1000 return code. This behavior is expected in normal working conditions of the domain registration chain. We differenciate between minor, major and blocking problems. A minor problem represents a problem on the chain that does not affect the good reception of the requests. The chain is then asynchronous until the problem is solved. Any operation affected by the problem will exceptionally answer with a 1001 return code during that time and notifications will be issued. For a minor problem, operations on « contact » objects, notification queues consultations and EPP operations like « querry » will not be affected. In case of a blocking problem, the server reacts in a more radical way and no operations like « transform » on domain names can be taken into account. An error message « command failed » (code 2400) is then returned for any new command. 3.2.3. Auth_info management The EPP protocol allows the use of an auth_info for domain names that are used for transfer operations (registrar change). The operations described hereafter allow the registrars to use our EPP server to retrieve the auth_info codes of their complete domain portfolio and modify them if necessary. In addition, as the use of this auth_info code is mandatory for any registrar change, a rule forces the registrar in charge of the domain name to give it to the domain holder. Each registrar is free to choose the best way to issue this information to the holder. 3.2.4. Implementation choice of the notifications list We have chosen to indicate during any server answer the number of messages in the queue (unless there is none, in which case this information does not appear). RFC 5730 obliges to communicate this information only in the cases of answers to the <poll> commands and makes it optional for any other type of commands. In concrete terms, this implies that as soon as a message is notified to a registrar, the registrar is informed by the presence of the <msgQ> element in any answer to commands sent to the server. It is strongly advised to read these messages as they arrive, they may contain operation follow-ups, technical modifications or transfer request you might find interesting to answer. 3.2.5. DNSSEC support The EPP server manages the secDNS-1.1 extention as described in RFC 5910, excluding any other versions. Implementation specifications are as follows: Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 11 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 12 • The server only supports « the DS data interface » (<secDNS:dsData>), section 4.1 of RFC 5910, without information on the associated key (no <secDNS:keyData> element) ; the presence of information on the key will generate a 2102 error code. • In the same way as for name servers, DNSSEC elements are only accepted during an update[tech] operation. Their presence during a create operation will generate a 2103 error code. • A domain name can have up to 6 associated DS records: the number of elements <secDNS:dsData> present in the section <secDNS:add> during an update[tech] operation is therefore limited to have the domain's final status with no more than 6 DS records. • The maxSigLife element is not supported, it presence inside a client request will generate a 2102 error code. • The urgent attribute is not supported, it presence inside a client request will generate a 2102 error code. • During a transfer operation, the AFNIC extension frnic-1.2 must necessarily include a keepDS flag which is a boolean: if its value is 1, actual DS records for the domain name are maintained after the transfer if already present, if its value is 0 in case of a successful transfer any existing DS record will be deleted. • Trade and recover operations work the same way as the transfer described above. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 12 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 13 3.3. Implemented commands 3.3.1. The <greeting> The <greeting> is not a command the client can send to the EPP server, but it is the welcome banner it will send when a connexion is made. It is also the answer sent in response to a <hello> command (this command is detailed in the next section). Why detail this banner if it is not a command ? Simply because the information it gives out is important and necessary for the <login> command. Even though the <greeting> reproduced here is only given as an example and the detail of its content can be found in the RFC 5730, two pieces of information are of importance: the versions of the supported protocol (<version> element) and the accepted languages (<lang> element). Only one choice, among those values, will be accepted during the session establishment with the <login> command. <greeting> example that can be sent by the AFNIC EPP server: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <greeting> S: <svID>EPP PROD Server on nergal.nic.fr (V1.1.0)<svID> S: <svDate>2010-04-01T12:34:56.0Z</svDate> S: <svcMenu> S: <version>1.0</version> S: <lang>en</lang> S: <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI> S: <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI> S: <svcExtension> S: <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI> S: <extURI>http://www.afnic.fr/xml/epp/frnic-1.2</extURI> S: <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI> S: </svcExtension> S: </svcMenu> S: <dcp> S: <access><all/></access> S: <statement> S: <purpose><admin/><prov/></purpose> S: <recipient><ours/><public/></recipient> S: <retention><stated/></retention> S: </statement> S: </dcp> S: </greeting> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 13 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 14 3.3.2. The <hello> command Even though it is not an EPP command strictly speaking, this command is particularly important and usefull as it will allow an EPP client to check if the connection with the server is correctly established. Indeed, as soon as a connection is established with the server, it is possible, at any moment, to send this command to the server that will answer with an EPP welcome banner (the <greeting>), even if the authentication (<login>) phase is not completed. In the event the time-out mecanisms should be activated (for more details refer underway) to end to the document Technical policies of the Registry « inactive » sessions, it is very possible to send a « heartbeat » by regularly making this command in order to maintain sessions that are less used (of course, the frequency of this « heartbeat » shall remain reasonable, in view of the « time-out » and rate-limiting parameters eventually put in place). For example, we can imagine this command being executed every 2 minutes to maintain an open connection and check that the server is responding as being an acceptable frequency. Example of request sent by the client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <hello/> C:</epp> 3.3.3. Session management commands The EPP protocol offers 2 commands that allow to establish (<login>) and end a session with the server (<logout>). Once the session is opened, it will only end at the client's request (<logout>) or if the server should, for internal reasons, end it (« time-out » on an inactive session, technical problem, ...) or if the customer interrupts the TCP connection (if this interruption is done within the normal framework of the client use, it is strongly recommended to use a <logout> before cutting off the TCP connection). As the number of simultaneous sessions can be limited it must be meticulously managed. 3.3.3.1.The <login> command During the server connection, the server sends a (<greeting>) banner to the client indicating by doing so that it is ready to receive a command to establish a session. This command requires the EPP login generated by AFNIC for each registrar and the associated password (it has been decided, for safety reasons and partitioning of the different AFNIC interfaces, to create new logins, without any link with those already existing). If those are Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 14 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 15 correctly indicated and if the number of sessions currently opened does not exceed the maximum allowed number, the session should normally be established. The <login> command also offers the possibility to modify the password associated with this login. There is no limitation for this use and it is even strongly recommended to change it during the first session opening on the EPP server. <login> command example sent by a client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <login> C: <clID>-kiffucol911-.fr</clID> C: <pw>toto1</pw> C: <newPW>toto2</newPW> C: <options> C: <version>1.0</version> C: <lang>en</lang> C: </options> C: <svcs> C: <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI> C: <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI> C: <svcExtension> C: <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI> C: <extURI>http://www.afnic.fr/xml/epp/frnic-1.2</extURI> C: </svcExtension> C: </svcs> C: </login> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> The result for this command will be the opening of a session for the registrar with the EPP login « –kiffucol911-.fr », the password « toto1 », and that decides for security reasons to change it with « toto2 » (of course, it is this new password that will need to be used upon the next session establishment, as the change is taken into account right away). 3.3.3.2. Strict authentification A strict check is made to ensure that during each session all the EPP extensions used have been indicated by the client during its authentication at the start of the session. If a new extension appears in a command, it will be rejected. That thus means that it is at least necessary to announce explicitly: • The frnic-1.2 extension for operations on contacts and certain operations on domain names such as transfer, trade, recover, etc. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 15 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • 16 the rgp-1.0 extension in order to restore a domain name and possibly the secDNS-1.1 extension if you want to manage DNSSEC. A strict check is made to ensure that the EPP extensions chosen by the customer at the time of authentication are among the EPP extensions announced by the server; The presence of any other "exotic" extension (not announced by the server in the <greeting>) will result in a failed authentication, as will the absence of any mandatory extension. The combination of these two tests imposes you to authenticate with one of the following combinations: domain-1.0, contact-1.0, frnic-1.2, rgp-1.0 or domain-1.0, contact-1.0, frnic-1.2, rgp-1.0, secDNS-1.1 3.3.3.3.The <logout> command As already indicated, a client that wishes to have a clean EPP session management must send an end of session command (<logout>) (and, ideally, wait for a server answer) before cutting the TCP connection with the server. Even though the server can detect « wild » EPP client cut-offs, these types may not free the limited ressources allocated to each registrar quickly enough. To be totally clear, if we only authorize, for each registrar, X number of simultaneous sessions with the EPP server (cf §3.1 Configuration and parameters), and that all of these sessions are all used at the same time, disconnecting a client without a <logout> phase could have for consequence that the cut-off will not be taken immediatly into account. This will then block any new connections returning the code 2502 until the system detects and manages this cut-off. <logout> command example sent by a client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <logout/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 16 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 17 3.3.4. Interrogation commands Even though we detail the commands for the different types of objects (contact and domain) in the following chapters, here is a brief outline of what commands are available and the use they have been intended to. 3.3.4.1.The <check> command This command enables to check if an object is available. Considering our internal way of managing « contacts », namely, an internal algorythm that determines the identifier (Nic-handle) that will be associated to a « contact » object, the <check> command can only be used on « domain » objects. Before any domain creation, it is strongly recommended to check availability. It is strongly recommended to use the DAS service (Domain Availability System) IRIS D-CHK. Cf § 6. DAS. The DAS service is to be preferred to the EPP command. 3.3.4.2.The <info> command When you wish to retrieve information on a domain name or a contact for which you know the identifier, you need to use this command. A registrar can only retrieve information on contacts linked to objects in his portfolio. For domain names it is possible, if the associated password (<authInfo> element) is known, to retrieve information on a domain name maintained by another registrar (this password is given by the holder during the <transfer> operation among others). It is important to note that this command should only be used to retrieve information on objects and not used to check their availability for instance. This function is available through the <check> command. Example for a IDN: 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: <info> C: <domain:info xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd"> C: <domain:name hosts="all">xn--strae-42-tya.fr</domain:name> C: </domain:info> C: </info> C: <clTRID>PasTerribleCommeSecret666</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 17 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 18 Example of answer sent by the server: S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 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: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>xn--strae-42-tya.fr</domain:name> S: <domain:roid>DOM000003382455-FRNIC</domain:roid> S: <domain:status s="inactive"/> S: <domain:registrant>TGCA108</domain:registrant> S: <domain:contact type="admin">TGCA108</domain:contact> S: <domain:contact type="tech">VL0</domain:contact> S: <domain:clID>-naqjanir485-.fr</domain:clID> S: <domain:crDate>2012-01-20T13:16:24.0Z</domain:crDate> S: <domain:exDate>2013-01-20T00:00:00.0Z</domain:exDate> S: <domain:upDate>2012-01-20T13:16:24.0Z</domain:upDate> S: <domain:authInfo> S: <domain:pw>IDN2012</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>PasTerribleCommeSecret666</clTRID> S: <svTRID>DEV-vraiton-16996-14-1327418457.36048</svTRID> S: </trID> S: </response> S:</epp> 3.3.4.3.The <poll> command During the different operations on the objects of a registrar's portfolio, notification messages will need to be sent to him. These messages will be set in a queue that can be read with the <poll> command. A few examples can be found further down, but here is how this notification message queue works. Each time an information linked to an operation (for which a specific message exists) must be sent it is added in a message queue. As soon as the messages are ready to be read, the information is indicated in the server's answer to commands (<msgQ> element indicated). The <poll> command retrieves the oldest message in the queue. In order to delete this message from the queue the command must be used again with the message number corresponding to the one just read (the detailed procedure can be found in RFC 5730). 3.3.5. Object Update commands These commands are all detailed further down, it is strongly advised to read the following RFCs: 5730 (commands presentation), 5731 (specificities on « domain » objects), 5732 (specificities on « contact » objects) as well as the 5910 (DNSSEC specificities). Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 18 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 19 Here is an exhaustive list: • <domain:create> • <domain:update> • <domain:delete> • <domain:transfer> • <frnic:trade> and <frnic:recover> (domain operation with the use of an extention) • <contact:create> • <contact:update> 3.4. Managing a domain name 3.4.1. Create – create a domain name The EPP protocol (RFC 5730) allows domain name creation (RFC 5731). It is important to distinguish to types of creations, each one having its own specificity. The first type of creation, we will qualify of « direct », must be used for a standard domain name creation (see The AFNIC Naming Charter http://www.afnic.fr/en/ressources/reference/charters/ ) The second type of creation, we will qualify as « creation with authorization code », must be used for domain name creations under conditions (see The AFNIC Naming Charter). 3.4.1.1."Direct" domain name creation This case represents 99,99% of creation operations and does not require much information. As for the nic-handles, from an EPP point of view, XX12345-FRNIC is a ROID (Repository Object Identifier) and is not supposed to be used as a reference for « contact » objects. A « contact » object is only referenced with the left hand side of the the nic-handle, meaning without the " -FRNIC". Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 19 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 20 Here are the elements that must be indicated in the command and a brief decription. If some of these elements are missing or if others are added an error will be returned. • • • • • • • • • Element Name <domain:name> < <domain:period> d <domain:registrant> o <domain:contact type="admin"> m <domain:contact type="tech"> a <domain:authInfo> i<domain:pw> n <clTRID> Number of occurrences 1 0-1 1 1 1-3 1 1 0-1 <domain:name> contains the complete domain name (example-dnepp.fr). <domain:period> not used at this time as domain names are tacitly renewed. It has been decided not to return an error when indicated but to only accept two precise values: • Either <domain:period unit="y">1</domain:period> • Either <domain:period unit="m">12</domain:period> <domain:registrant> contains the holder identifier deduced from its nic-handle from which the suffix (FRNIC) has been removed as well as the separator character "-". <domain:contact type="admin"> contains the admin contact identifier. <domain:contact type="tech"> contains the technical contact identitifier. <domain:authInfo> contains the auth_info the registrar has chosen to associate to this domain name. In the case of a creation « with an authorization code », this auth_info is imposed. At this time a mechanism other than the password (<domain:pw>) is not scheduled. As this password is free, it is strongly recommended to associate different auth_info for each domain name. It is also impossible to use the « roid » attribute. For no ambiguity, using it will return an error. <clTRID> is optional. It is strongly advised to indicate this field for a better follow up of commands and if necessary for search requests and EPP clients « troubleshooting » operations. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 20 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 21 Example of a request sent by the client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:registrant>MM4567</domain:registrant> C: <domain:contact type="admin">NFC1</domain:contact> C: <domain:contact type="tech">NFC1</domain:contact> C: <domain:contact type="tech">VIL1666</domain:contact> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> In this context of a « simple » creation, if all the naming and syntax rules are respected and if the domain name is available, the server answers with a 1000 return code. More precisely, in case of a successfull domain creation, the only return code possible is 1000. There cannot be a 1001 return code for this type of creation unless there is a minor or major problem. Note that, in the server answer, are indicated the domain name creation and expiration dates (<domain:crDate> and <domain:exDate>), the latter being indicated to remain coherent with the <domain:period> element when it is indicated by the client. Example of answer sent by the server: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:crDate>2008-12-25T00:00:00.0Z</domain:crDate> S: <domain:exDate>2009-12-25T00:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000001</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 21 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 22 Example of answer sent by the server (1001 return code): S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>dom-epp-wytxubuz.fr</domain:name> S: <domain:crDate>2010-06-03T15:22:15.0Z</domain:crDate> S: <domain:exDate>2011-06-03T00:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>FRNIC-18673-CLIENT-1275578515</clTRID> S: <svTRID>DEV-photon-18294-4-1275578517.15639</svTRID> S: </trID> S: </response> S:</epp> 3.4.1.2.Domain name creation "with an authorization code" Such an operation requires an authorization code (see. Procedure Manual http://www.afnic.fr/en/ressources/reference/technicalguidebooks/procedures-manual-for-registrars.html ). Reminder: this code is associated to three informations (the registrar, the domain name and the holder nic-handle). Once the code is created, the domain name creation is done almost in the same way as described during the « direct » creation except for two details. The first is that the holder identifier is not free and must correspond to the one associated to the authorization code, the second is that the authorization code must be used instead of the auth_info in the <domain:authInfo> element as it is not free. On the other hand it is mandatory to change it with the <domain:update> command before giving it to the final holder. Please note that this does not change the rest of the request and that it is handled under the same rules as the previous case. Meaning that a successfull registration will generate an answer with the return code 1000 (this is the reason why the server answer is not reproduced). Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 22 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 23 Example of a request sent by the client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-reserve-0001.fr</domain:name> C: <domain:period unit="m">12</domain:period> C: <domain:registrant>MM4567</domain:registrant> C: <domain:contact type="admin">NFC1</domain:contact> C: <domain:contact type="tech">NFC1</domain:contact> C: <domain:contact type="tech">VIL1666</domain:contact> C: <domain:authInfo> C: <domain:pw>NDCR20080229T173000.123456789</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> 3.4.1.3.After the creation… Once the domain is created, it can be available for consultation with the <domain:info> command and visible in the Whois (an additional propagation delay is possible because of the way our database replication architecture is done, but in the best conditions, data synchronisation is done in near real time). Eventhough the qualification (see Procedure Manual) process is done on the holder, its progress can impact the status of the domain name once it is created. Indeed, if the holder is in phase of request for supporting documents, the domain name will be in suspending status then blocking status which will change the EPP status. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 23 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 24 Summary table of the operations accepted according to the state of the qualification process: State of the qualification process start Whois: reachstatus pending Whois: eligstatus pending Operations denied contact:update Domain status - contact:update problem (suspended) ok/- domain:trade ok/- serverTransferProhibited + serverTradeProhibited domain:transfer contact:update domain:trade domain:transfer problem (blocked) ok/- ok/- domain:restore domain:delete serverHold + serverUpdateProhibited + serverDeleteProhibited + serverTransferProhibited + serverTradeProhibited + domain:update domain:create finished ok/- ok/- aucune - 3.4.2. Update – modify a domain name attributes We have chosen to define 3 types of very distinct modifications with the same EPP command: <domain:update>. In case the modification concerns the contacts associated to a domain name (technical and/or adminstrative), or only the DNS configuration or only on the domain name status and its associated auth_info. 3.4.2.1.Update [admin] – Contact list modification The modification of the contact list associated to a domain name, whether technical and/or administrative, must be requested with a <domain:update> command. Eventhough EPP and the domain mapping allows the domain holder change with this command, we do not authorize this action. A domain holder change is done with the <domain:trade> and <domain:recover> commands that we will detail later on in this document. It is important to keep in mind that modifications on contact lists cannot overstep the rules of occurrences indicated in the domain name creation section. Indeed, as the <domain:update> command allows the use of two sub-commands <domain:add> and <domain:rem>, any deletion of a contact that leads to the deletion of that type of contact for the domain name must contain the addition of another contact of the same type. For instance, the actual rule that limits to one the number of administrative contacts for a Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 24 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 25 domain name is translated during its modification by the deletion of the actual contact and the addition of a new one, within the same EPP command (the example given further down will go over this case). Each element <domain:add> and <domain:rem> can contain <domain:contact> elements (already described in the « domain name creation » section). If the same contact is contained both in <domain:add> and <domain:rem>, the command is accepted, both operations will cancel themselves and the other modifications requested in the command will be taken into account normally. In concrete terms, a command that indicates the addition of technical contacts VIL1666 and MIS78 as well as the deletion of the technical contact VIL1666 equals a command that would only contain the addition of the technical contact MIS78. If we stay on the example of the domain we created above and add a third technical contact and change the administrative contact, here is the XML request that is sent. C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:contact type="admin">VIL1666</domain:contact> C: <domain:contact type="tech">JAP777</domain:contact> C: </domain:add> C: <domain:rem> C: <domain:contact type="admin">NFC1</domain:contact> C: </domain:rem> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 25 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 26 Example of an answer given by the server (for this type of command, the return code is 1000 unless there is a minor or major problem): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000002</svTRID> S: </trID> S: </response> S:</epp> Example of answer in case of code return 1001: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <msgQ count="1" id="63480"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000002</svTRID> S: </trID> S: </response> S:</epp> 3.4.2.2. Update [tech] – Name server configuration modification The command is used to indicate an initial DNS configuration for a domain name that doesn't have any yet or to change an existing DNS configuration. By modification, we also mean the pure and simple deletion of the domain's name server list in order to have the possibility to reserve a domain name without any DNS publication. This command is also used to add or delete signed delegations (DS records). The command is sent by the client (to simplify, we consider this command to be syntactically correct and that the necessary glues are present), the format we have chosen for the name servers is the one where they are attributes of the « domain » object and not as references on « host » objects (RFC 5732). When the command is handled, the server answers with a return code 1000. The configuration is directly visible in the Whois and can be published during the next DNS zone file reload (unless the status "clientHold" or "serverHold" is indicated which prevents the DNS publication). Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 26 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 27 IMPORTANT: The DNS configuration does not distinguish a server as being the primary or the others as being secondaries. This means the order of the servers has no importance. Even though they are usually returned according to the same order (via the Whois or via the answer to a command <domain:info>), there are no priority rules behind this order. The <domain:update> command can only contain the elements <domain:add> and/or <domain:rem>. The first contains the information necessary to add one or several name servers to the existing configuration, the second one to delete one or several name servers. The modification of a name server to update it glue has to be present in <domain:rem> (just the name server) and in <domain:add> (with the new glue to apply). As a reminder, we have not implemented RFC 5732, on objects of type "host" that allow to reference the name servers. We prefer to use the possibility to describe the name servers as attributes of the « domain » objects. Each of the <domain:add> and <domain:rem> elements can only contain the single element <domain:ns>, any other element present that could be confusing as to which type of modification is requested will lead to an error. In addition, each <domain:ns> element is only composed of a one single collection of <domain:hostAttr> elements. Here are the sub-elements that are present in the <domain:hostAttr> element and their brief description. The absence of mandatory elements and/or presence of other elements will return an error. Element name <domain:hostName> <domain:hostAddr ip="v4"> <domain:hostAddr ip="v6"> • • • Number of occurences 1 0-n 0-n <domain:hostName> contains the complete domain name of the name server. <domain:hostAddr ip="v4"> contains an Ipv4 address to associate to the name server when a glue is necessary (only for <domain:add>, forbidden for <domain:rem>). <domain:hostAddr ip="v6"> contains an Ipv6 address to associate to the name server when a glue is necessary (only for <domain:add>, forbidden for <domain:rem>). If the presence of a glue is necessary, it is not mandatory to indicate ipv4 and ipv6 addresses. One address, whatever its type, is sufficient (but several can be indicated). The command can be associated to a <secDNS:update> extension if DNSSEC operations are wanted and that the secDNS extension was chosen Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 27 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 28 by the client during connection. In that case the extension will need to contain a <secDNS:rem> element and/or a <secDNS:add> element. The <secDNS:rem> element contains either the <secDNS:all> element alone (if present with the value 1 it will delete all DS records linked to the domain name) either one or several <secDNS:dsData> elements. The <secDNS:add> element contains one or more <secDNS:dsData> elements. Each <secDNS:dsData> element is composed of the following subelements: Element name <secDNS:keyTag> <secDNS:alg> <secDNS:digestType> <secDNS:digest> Number of occurences 1 1 1 1 We would like to remind you that according to RFC 5910 order is important, as the content of element <secDNS:rem> is taken into account before the content of element <secDNS:add>. The "urgent" attribute in the <secDNS:update> element is not accepted, its presence with a value set ot 1 will generate a 2102 error code. The <secDNS:chg> element under <secDNS:update> is not accepted either because the only sub-element allowed under <secDNS:chg> is <secDNS:maxSigLife> which is not supported. The presence of the <secDNS:chg> element will generate a 2102 error code. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 28 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 29 Example of a request sent by the client after a creation to indicate the initial configuration for a domain name: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostAttr> C: <domain:hostName>ns1.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns2.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostName> C: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> C: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> C: </domain:hostAttr> C: </domain:ns> C: </domain:add> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Example of a request sent by the client after a creation to give the initial configuration of a domain name secured with DNSSEC: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostAttr> C: <domain:hostName>ns1.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns2.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostName> C: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> C: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> C: </domain:hostAttr> C: </domain:ns> C: </domain:add> C: </domain:update> C: </update> C: <extension> C: <secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:add> C: <secDNS:dsData> C: <secDNS:keyTag>12346</secDNS:keyTag> C: <secDNS:alg>3</secDNS:alg> C: <secDNS:digestType>1</secDNS:digestType> C: <secDNS:digest>38EC35D5B3A34B44C39B38EC35D5B3A34B44C39B </secDNS:digest> C: </secDNS:dsData> C: </secDNS:add> C: </secDNS:update> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 29 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 30 3.4.2.3.Update [context] - Modification of the domain status and/or its auth_info This operation is totally independant from the concerned domain name DNS configuration. It allows the registrar to set or remove the "clientHold" flag. If it is set, a domain name, even associated to a valid DNS configuration, will not be published in the DNS. Both processes are really independant. IMPORTANT: Some operations (please refer to the procedure guide for more details on that subject) may remove this flag if they are completed. Once again it is the <domain:add> and <domain:rem> elements that are used to add/remove a flag. These elements can contain only one element. Element name <domain:status s="clientHold"> • Number of occurences 1 <domain:status s="clientHold"> is sent as is. The RFC 5731 allows to send a clear message associated to the <domain:status> element and the use of a (lang) attribute indicating the language of the message. As we do not handle this message, the element must remain empty. Concerning the modification of the auth_info associated to the domain name, the use of the <domain:chg> element is necessary and even though it can be the parent to elements like <domain:registrant> and <domain:authInfo>, only the latter is accepted. The presence of the <domain:registrant> element will lead to an error returned by the EPP server. The use of <domain:authInfo> is very similar to the one indicated for a creation operation. Example of a request to forbid the DNS publication of the domain name just created and to modify its auth_info (in the present case, as it was a creation "with authorization code", the initial auth_info was imposed by AFNIC): C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 30 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 31 C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-reserve-0001.fr</domain:name> C: <domain:add> C: <domain:status s="clientHold"/> C: </domain:add> C: <domain:chg> C: <domain:authInfo> C: <domain:pw>PlusFortKeWarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:chg> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Example of an answer sent by the server (for this type of command, the return code is alway 1000 except in case of degraded server, also not that a message is awaiting on the serve, probably the result of the name server modification request on the domain name ndd-de-test-0001.fr): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="1" id="50001"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000004</svTRID> S: </trID> S: </response> S:</epp> Example of answer in case of code return 1001 (degraded server): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>FRNIC-27505-CLIENT-1275645007</clTRID> S: <svTRID>DEV-photon-27393-9-1275645009.72202</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 31 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 32 3.4.3. Delete – Delete a domain name The deletion of a domain name comes with a restoration mechanism (restore). This mechanism, based on RFC 3915, limits the application field by restricting it to the deletion operation only. The rules that come with this procedure, its delays in particular, are not discribed in this document (read Procedures Manual). The deletion command is not modified from what is described in RFC 5731, however, in case of a success (there are some cases where the domain deletion is not possible like when the domain itself is used as a name server on other domain names), the return code is not 1000, but still 1001. The status "pendingDelete" is indicated for the total duration of the "grace period" and as long as the domain is not restored or totally deleted. A notification message is added to the queue at the end of the deletion operation with paResult="0" in the case of a successful restoration, paResult="1" in the case of an effective deletion of the domain name. Example of a deletion request for our test domain name: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <delete> C: <domain:delete C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: </domain:delete> C: </delete> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Example of an answer sent by the server (for this type of command, the return code is alway 1001): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 32 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 33 3.4.4. Restore – Domain name restore The restoration command is done through an extension of the <domain:update> command. This type of operation must not be confused with the other possibilities described in § 3.5.2 that describes the use of this command to modify contacts, DNS configuration or a domain name's status. Indeed, a restoration operation must not come with any other domain modification. This problem is bypassed in the RFC by making one of the elements of the command <domain:update> mandatory but empty... But this does not comply with the XSD file which is nominative. We have therefore decided to follow the latter and, contrary to what is indicated in the RFC 3915, a <domain:update> command that only contains the <domain:name> element, associated to the extension of the <domain:update> command is the correct one to use. The extension of the <domain:update> command described in RFC 3915 only goes through if the <rgp:restore> element is added. However, it has an "op" attribute that can display 2 values. We only accept one, as described in the following table. Element name <rgp:restore op="request"> Number of occurences 1 Example of the restoration request for our test domain name: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: </domain:update> C: </update> C: <extension> C: <rgp:update C: xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> C: <rgp:restore op="request"/> C: </rgp:update> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 33 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 34 Example of an answer sent by the server (for this type of command, the return code is alway 1000 except in case of degraded server and as precised in the RFC, in case of success, the "s" attribute of the <rgp:rgpStatus> element in the extension must indicate "pendingRestore" as a value): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <rgp:update S: xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgp:rgpStatus s="pendingRestore"/> S: </rgp:update> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000006</svTRID> S: </trID> S: </response> S:</epp> Example of answer in case of code return 1001 (degraded server) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>FRNIC-27180-CLIENT-1275642432</clTRID> S: <svTRID>DEV-photon-26251-3-1275642432.11977</svTRID> S: </trID> S: </response> S:</epp> 3.4.5. Transfer – Registrar change The <transfer> command offered by EPP only allows a registrar change. A few modifications were made to this command to make it more complete. As for the access restrictions to the use of this command, RFC 5730 gives out recommandations, but these are not mandatory. To avoid confusion, AFNIC has decided to only authorize registrar changes for a domain name to registrars that do not manage the concerned domain name. Accepting or rejecting a registrar change can only be done by the outgoing registrar. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 34 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 35 3.4.5.1.Requesting a transfer (registrar change) First difference with the standard, is the <domain:pw> element (element itself of <domain:authInfo>) that cannot be used with the "roid" attribute to indicate that the given auth_info is linked to the holder or a contact associated to the domain name itself. In our case the auth_info can only be linked to the domain name. During the transfer, the holder is cloned to the incoming registrar (unless a "contact" object with the exact same information already exists with this registrar). Important, this cloning happens once the transfer is approved by the outgoing registrar. Eventhough it is planned by the RFC, the modification of the domain name validity period cannot be done. The same restrictions as for a creation apply to the <domain:period> element still considered as an optional element (in order to keep things homogenous, we have kept exactly the same logic as the creation operation). However, as the change is validated only at the end of the procedure and that it is at this moment that the new anniversary date is indicated, the <domain:exDate> element is absent from the server answer. Last difference, an extension is necessary to allow the transfered domain name to be associated to technical and administrative contacts linked to the registrar requesting the transfer as well as to specify if the potential DNSSEC configuration (DS records) must be maintained in case of a successful transfer. Here are the specific elements found in the XML request sent by the client. Element name <domain:pw> <frnic:domain keepDS="0"> <frnic:contact type="admin"> <frnic:contact type="tech"> Number of occurrences 1 1 1 1-3 The keepDS element is an XML boolean and must be set to a value among: 0, 1, true, false. Its presence is mandatory. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 35 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 36 Example of the transfer request sent by a registrar on our domain name test0001.fr with keeping the DS records: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="request"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:transfer> C: <frnic:domain keepDS="1"> C: <frnic:contact type="admin">PR1249</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:transfer> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> The answer to this transfer request (if it is acceptable on its syntax and semantics) contains a number of information described in RFC 5731. We do not use an extension for the answer. Here is the list of elements present in the answer. Element name <domain:name> <domain:trStatus> <domain:reID> <domain:reDate> <domain:acID> <domain:acDate > • • • • Number of occurences 1 1 1 1 1 1 <domain:name> contains the full domain name (exemple-nddepp.fr). <domain:trStatus> indicates the status of the request. Can only contain the "pending" value. <domain:reID> contains the incoming registrar ID. <domain:reDate> indicates the date and time of when the request was handled. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 36 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • 37 <domain:acID> contains the registrar ID of the last registrar that changed the status of the transfer robot as indicated in <domain:trStatus>. However, when the status indicates "pending", the registrar ID will the one of the outgoing registrar. <domain:acDate> indicates, when the transfer status is "pending", the date and time left to answer for the outgoing registrar ("approve" or "reject") before the procedure is handled automatically. In the other cases ("clientApproved", "clientRejected", …), it indicates the date of the action that led to that status. Example of answer sent by the server (for this type of command, the return code is always 1001): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </trID> S: </response> S:</epp> Of course, if the domain name is in "serverTransferProhibited" status (the case when the domain name holder is undergoing an identification phase), it is not possible to request a transfer. An 2106 error code is returned. The next steps of the operation, accepting or refusing the registrar change by the outgoing registrar, is done by using the "op" attribute of the <transfer> command. As long as the transfer is not finished (whatever the way it ends), the domain name status indicates "pendingTransfer". 3.4.5.2.Next steps for the outgoing registrar A message is added to the queue and the registrar can be aware of this addition during a following command as the incremented message count is present in every answer from the server to any client request. The message is similar to the answer received by the registrar who requested the transfer. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 37 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 38 Example of a request to retrieve the awaiting message: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"/> C: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> C: </command> C:</epp> Example of the answer sent by the server indicating a transfer was requested for the domain name ndd-de-test-0001.fr: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50002"> S: <qDate>2008-12-25T00:02:00.0Z</qDate> S: <msg>Transfer requested.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp> The outgoing registrar has 3 options, either approve the operation, reject it or not answer... We would like to remind you that without an answer, within a delay equal to <domain:acDate> minus <domain:reDate>, 8 days in the present case, the request is considered as accepted. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 38 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 39 To explicitly accept the transfer request, the outgoing registrar must send the following request to the server (the <domain:period> element is completly ingnored according to RFC 5731 ; and on the contrary to a transfer request no extension needs to be used) : C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="approve"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> As the possibility to accept or reject the transfer request is reserved to the outgoing registrar, we could do without the auth_info associated to the domain name, but in order to remain coherent it is mandatory, whatever the value of the "op" attribute. Example of an answer sent by the server indicating the acceptance of the transfer was taken into account (the 1000 return code appears in this case, that the transfer status is now "clientApproved" and that the date indicated in <domain:acDate> indicates when the outgoing registrar accepted the transfer): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000009</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 39 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 40 In case the outgoing registrar wishes to refuse the transfer operation, he must send a similar request to the previous one by only changing the "op" attribute value from "approve" to "reject". The server answer is also very similar to what was presented in the case of the acceptance. The difference is in the transfer status no longer indicating "clientApprove" but "clientRejected". Example in the case of a transfer refusal by the outgoing registrar: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="reject"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Example of a server answer in the case of a refusal: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2009-10-07T08:13:02.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-10-07T08:13:16.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-000000009-bis</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 40 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 41 3.4.5.3.Next steps for the incoming registrar It is possible, as long as the outgoing registrar has not answered (by an "approve" or a "reject"), to cancel the ongoing request. This possibility is available by sending a <transfer> command with the "op" attribute set to "cancel". A notification indicating the command cancelation is sent to the outgoing registrar (that remains in charge of the domain name). If the incoming registrar doe not wish to cancel the ongoing operation, two cases are possible, either the transfer is accepted, either it is refused (sic). In any case the incoming registrar is notified in his message queue of the outgoing registrar's choice. In fact, an accepted transfer generates 2 entries in the queue (sometimes 3, but we will come back to this third message later on), the first one informs the incoming registrar the operation was accepted by the outgoing registrar, the second one indicates the command he made was a success. In concrete terms, here is the message sequence that must be retrieved with the <poll> command. The first message repeats the content of the <domain:trnData> element sent as an answer to the <transfer op="approve"> command the outgoing registrar has received. Note the value for <domain:acDate> in comparison to <qDate>, the second one cannot be posterior to the first one. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 41 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 42 The second message in the queue is the initial command result to which the server had answered with a 1001 return code. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2008-12-26T00:01:00.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp> In case the outgoing registrar refuses, this second message is not present as the command is not finished. Here is the message in the queue instead of the one indicating the registrar change was accepted. Not the value for <domain:acDate> that show the increase of the delay given to the outgoing registrar... During this period, the outgoing registrar can approve the transfer at any time (generating the message sequence seen before), as the domain is in "pendingTransfer" status. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer rejected.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-16T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 42 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 43 We have seen just above the possibility of a third message in the queue. Indeed, we have said that during a transfer, the holder contact of the domain name is cloned if necessary. In that case, it is important the incoming registrar is notified of this creation, as it is not explicitly requested. A notification message is added to the queue (similar to the one received after creating a contact object), it is sent once the transfer operation is successfully ended. Therefore, it is possible to differenciate cases where the holder is re-used (no message is sent). Sending this message should prompt the incoming registrar to retrieve all the information on this new contact. 3.4.5.4.Using the <domain:transfer> command for consultation It is normally planned that this commad should give information on the ongoing transfer or on the last transfer finished on a domain name. We do not offer this possibility. A good handling of the notification messages should allow both registrars involved to have a complete follow up on the operation. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 43 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 44 3.4.6. Trade – Holder change (Transmission) The <trade> command does not exist in the EPP standards. At AFNIC, we have two specific transmission procedures that apply to different cases, the operation described here only corresponds to what we call a trade (volutary transmission). 3.4.6.1.Trade request (voluntary transmission) Unlike the <transfer> operation, the transmission does not necessarily implies a registrar change. But the holder must change. As for the other types of contacts, if the domain remains with the same registrar, there is no real reason to modify them. In order to remain coherent with, amongst others, the <transfer> operation, we have decided to have all types of contacts mandatory, whether they are modified or not... Just like the <transfer>command, the <trade> command has an "op" attribute that allows to differenciate its use in "transform" mode from its use in "query" mode. On the other hand, unlike the <transfer> command, only 3 values are possible for this attribute: « request » to request a transmission on a domain name, « cancel » to cancel a request before the holders have both answered and « query » to check the status of the transmission. The trade (voluntary transmission) can only happen if the outgoing holder was correctly identified. If this is not the case, an error code is returned during ther request. The status "serverTradeProhibited" is set for this domain name. This information can be obtain by using the <domain:info> command. As this status does not exist in the EPP standards, it is found in an extension. As for the incoming holder, he can be in a pending identification status, not yet identified, but cannot be in « problem » status. The elements that must be present in the extension (in the <frnic:domain> element of the <frnic:trade> element) are indicated in the following table. Element name <frnic:domain keepDS="0"> <frnic:name> <frnic:registrant> <frnic:contact type="admin"> <frnic:contact type="tech"> Number of occurences 1 1 1 1 1-3 The keepDS element is an XML boolean and must be set to a value among: 0, 1, true, false. Its presence is mandatory. Note that implementing a new command via the EPP extension mechanisms prevents the <clTRID> element to be used (under the <command> element). As the latter is important to ensure the follow-up of commands Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 44 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 45 and their synchronisation (particularly useful for commands that answer with a 1001 return code), we have integrated this element to the extension. Eventhough it is not at the same place, its use in the server answer and in the notification messages that remain the same. For example, during a server answer to a transmission request that we will send further down, the <clTRID> element is duplicated in the <trID> element and not in the answer extension part. Example of the trade request for our domain name ndd-de-test-0001.fr (in our example, the transmission is done keeping the same registrar, administrative and technical contacts as well as the DNSSEC configuration): C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:command> C: <frnic:trade op="request"> C: <frnic:domain keepDS="1"> C: <frnic:name>ndd-de-test-0001.fr</frnic:name> C: <frnic:registrant>PR1249</frnic:registrant> C: <frnic:contact type="admin">VIL1666</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:trade> C: <frnic:clTRID>une-reference-client-par-exemple</frnic:clTRID> C: </frnic:command> C: </frnic:ext> C: </extension> C:</epp> As for the answer, we offer an answer pretty similar to the one sent during a transfer to which we have added, in an extension, the information about the incoming and outgoing holders. Eventhough we have kept a format close to the answer made during a transfer (but it is in the <extension> part of the answer, not in the <resData> anymore), meanings change for some elements. Indeed, for a transfer, it is the registrars that initiate the necessary operations to the status changes of a domain name handled, whereas in the case of a trade, it is both concerned holders, through an « off-line » process, that will validate or reject the operation. The elements used to time-stamp operations or indicate expiration dates (<domain:reDate>, <domain:acDate> and <domain:exDate>) are completed. Indeed, we need to indicate the date and time the request was received, the delay granted to both holders to accept or reject this operation and the time and date they answered the request. The following table indicates the elements present in the extension (<frnic:trdData>) of the server answer : Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 45 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 Element name <frnic:name> <frnic:trStatus> <frnic:reID> <frnic:reDate> <frnic:reHldID> <frnic:rhDate> <frnic:acID> <frnic:acHldID> <frnic:ahDate> • • • • • • • • • 46 Number of occurences 1 1 1 1 1 1 1 0-1 1 <frnic:name> domain name subjected to the transmission request. <frnic:trStatus> indicates the transmission status. Eventhough at the time of the request the only possible value is "pending", 6 values are possible that we will detail later on ("pending", "newHolderApproved", "oldHolderApproved", "holdersApproved", "newHolderRejected", "oldHolderRejected"). <frnic:reID> contains the registrar ID making the request. <frnic:reDate> indicates the date and time the request was taken into account. <frnic:reHldID> contains the holder identifier requesting the voluntary transmission (trade). <frnic:rhDate> as long as the incoming holder as not made any action, indicates the limit date and time for him to accept or refuse the transmission (<frnic:trStatus> indicates either "pending", "oldHolderApproved" or "oldHolderRejected"). If the incoming holder accepted or rejected the request, the date of this last action will be indicated. In case the incoming holder does not answer and that the time limit is reached, the transmission is canceled. <frnic:acID> contains the outgoing registrar ID (in most of the cases, as the transmission is done by the same registrar, this value will be equal to <frnic:reID>). <frnic:acHldID> contains the identifier of the actual domain holder. This information will be given only if the transmission is done by the same registrar (the case presented in our example). <frnic:ahDate> as long as the outgoing holder has not accepted or rejected the operation, will indicate the limit date and time given to him to accept or refuse the transmission (<frnic:trStatus> then indicates either "pending", "newHolderApproved" or "newHolderRejected"). If the outgoing holder accepts or refuses, it is the date of this action that will be indicated. In case the outgoing holder does not answer and that the limit date is reached, the transmission is canceled. When <frnic:trStatus> is equal to "pending", <frnic:ahDate> and <frnic:reDate> will indicate the same value. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 46 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 47 Example of an answer sent by the server (for this type of command, the return code wil always be 1001). In the present case, values "BEsortantID" and "BEentrantID" are considered as identical, which explains why both <frnic:reHldID> and <frnic:acHldID> are present: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEentrantID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:reHldID>PR1249</frnic:reHldID> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEsortantID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-16T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </trID> S: </response> S:</epp> 3.4.6.2.Following-up on a trade (voluntary transmission) If the trade is coupled to a transfer, the outgoing and incoming registrars will receive almost identical service messages that will allow them to follow the evolution of the ongoing operation. On the other hand, only the registrar that initiated the operation will receive the conclusion message indicating the result to the <trade> command and only the registrar in charge of the domain name will receive the first service message more or less similar to the command answer (except that <frnic:reHldID> is missing unlike <frnic:acHldID>). The outgoing and incoming holders have both 15 days to validate the domain name transmission. To illustrate this, let's imagine a classic case where the outgoing holder validates the transmission, followed by the incoming holder, within the 15 days delay. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 47 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 48 First, the outgoing registrar receives a first notification message (we are here in the case of a trade coupled with a transfer, which explains the absence of the <frnic:reHldID> element) : S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50010"> S: <qDate>2009-12-25T00:02:00.0Z</qDate> S: <msg>Trade requested.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-16T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp> The outgoig holder accepts the trade, which will generate 2 notification messages, one to each registrar. These messages will be almost identical, only difference will be with the <frnic:reHldID> element not present in the message sent to the registrar used by the incoming holder to request the transmission and with the <frnic:acHldID> element not present in the message sent to the outgoing registrar. Note that the value in the <frnic:trStatus> element goes from "pending" to "oldHolderApproved" (if the incoming holder would have been the first to validate the transmission, <frnicStatus> would have indicated "newHolderApproved"). Also note the values for <qDate> and <frnic:ahDate>. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 48 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 49 Here is the message received by the outgoing registrar: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50011"> S: <qDate>2009-01-02T00:00:01.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>oldHolderApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000013</svTRID> S: </trID> S: </response> S:</epp> The incoming holder does the same and 2 messages are generated with the same limitations indicated before on the elements <frnic:reHldID> and <frnic:acHldID>. This time <frnic:trStatus> indicates "holdersApproved". Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 49 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 50 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50012"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>holdersApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-03T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000014</svTRID> S: </trID> S: </response> S:</epp> To end this operation, a message is sent to the registrar who initiated the transmission only. In our case, "paResult" indicates 1 because everything went as planned. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000015</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 50 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 51 3.4.6.3.Using the <trade> command for consultation Just like the <transfer> command, the <trade> command in consultation does not give any information on the last trade made on the domain name. Only information on the ongoing transmissions are available to the registrars involved in this operation. 3.4.7. Recover – Forced domain name transmission The other transmission method, recover ("forced" transmission), where the outgoing holder no longer exists, requires an authorization code. We are therefore in a situation that mixes a creation "with an authorization code" and a trade (voluntary transmission). 3.4.7.1.Requesting a recover (forced transmission) Just like a creation "with an authorization code", we will not detail in this document how to retrieve the authorization code necessary for a recover. But it must be retrieved before any attempt to use this command on a domain name. The logic behind the <recover> command is similar to the <transfer> and <trade> commands. For example, eventhough this is not useful in this interface version, we have chosen to keep the "op" attribute of the command. This attribute can only have one value, "request", as, on the contrary to other commands from which it is inspired, the <recover> command answers with a 1000 code instead of a 1001 code. Other than the command name, what differenciate the request sent for a <recover> from the one sent for a <trade> is the presence of the <frnic:authInfo> element used to indicate the authorization code. We would like to remind you that the authorization code is associated to three elements (the registrar, the domain name and the holder nic-handle). The recover cannot be requested for an incoming holder in problem status. There is no limitation on the <recover> command from the identification status of the outgoing holder. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 51 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 52 Here is an example for a request sent by a registrar who received the necessary authorization code for the recover of our domain name example and that does not wish to keep the DNSSEC configuration: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <frnic:command> C: <frnic:recover op="request"> C: <frnic:domain keepDS="0"> C: <frnic:name>ndd-de-test-0001.fr</frnic:name> C: <frnic:authInfo> C: <domain:pw> C: NDCR20080229T173000.123456789 C: </domain:pw> C: </frnic:authInfo> C: <frnic:registrant>PR1249</frnic:registrant> C: <frnic:contact type="admin">VIL1666</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:recover> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </frnic:command> C: </frnic:ext> C: </extension> C:</epp> The server answer is also very similar to the one made for the <trade> command. Indeed, in this case, the holders and registrars do not have to take any action to complete the command successfully. The command return code is 1000, so it is not necessary to give the information on the recover status or indicate limit dates for action by the holders or the registrars. The limitations on the presence or absence of the incoming and outgoing holder identifiers are the same as for the <trade> command. If the incoming registrar is differnt from the outgoing registrar, a notification message is added in the notification queue of the outgoing reigstrar. The following table details the elements present in the extention (<frnic:recData>) of the server answer (and in the notification message sent if necessary) : Element name <frnic:name> <frnic:reID> <frnic:reDate> <frnic:reHldID> <frnic:acID> <frnic:acHldID> Number of occurrences 1 1 1 0-1 1 0-1 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 52 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • • • • • 53 <frnic:name> domain name subjected to the transmission request. <frnic:reID> contains the registrar ID making the request. <frnic:reDate> indicates the date and time the command was taken into account. <frnic:reHldID> contains the holder identifier making the recover request. Is not present in the notification message when the recover is coupled with a transfer. <frnic:acID> contains the actual registrar ID (in most of the cases it is equal to <frnic:reID>). <frnic:acHldID> contains the actual domain holder identifier. This information is only given if the recover is done without changing the registrar. Example of an answer sent by the server (for this type of command, the return code is always 1000). In the following case, the "BEentrantID" and "BEsortantID" values are considered as identical, which explains the presence of both elements: <frnic:reHldID> and <frnic:acHldID>: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:recData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:reID>BEentrantID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:reHldID>PR1249</frnic:reHldID> S: <frnic:acID>BEsortantID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: </frnic:domain> S: </frnic:recData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000016</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 53 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 54 3.4.8. Checking a domain availability The <domain:check> command allows to check the availability of one or several domain names, up to 7 by command. Any request containing more domain names than the authorized limit will get an error message. The answer from the server indicates for each domain, with the help of a boolean type attribute if the domain can be created and if it can't, indicates the reason why. Here is a list of the messages sent in case a domain name cannot be created: Message In use Zone not opened Zone unknown Bad syntax Registry bad syntax Equivalent name in use Forbidden name Details The domain name already exists (whatever its status, a domain name, pending deletion for example, is not free). The domain name is free, but belongs to a zone managed by AFNIC not opened for registrations. The domain name is not in a zone managed by AFNIC. The argument indicated in the parameter is not a domain name. The argument indicated in the parameter is a domain name but does not respect one of the syntaxic rules imposed by AFNIC (for example: only one letter in the gender label x.fr, …). An « equivalent » domain name already exists and blocks the registration of this domain name. The domain name is part of list of forbidden domain names. In order to differenciate « reserved » names that can be registered with an authorization code from the forbidden names that cannot be registered, we have decided to indicate this information in an extension. The <frnic:name> element contains the domain name and the "reserved" attribute or "forbidden" attribute of this element. These attributes indicate that the domain name requested belongs indeed to the old list of reserved or forbiddens names. Since July 1st, 2011, this list is treated in a homogeneous way and all these terms can be subject to prior review (with a authorization code). If the domain name is « reserved », a <frnic:rsvReason> element must be present to indicate why it is categorized that way. It is the same with the presence of a <frnic:fbdReason> element. We can imagine that a reserved Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 54 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 55 name is reserved for several reasons, this is why the <frnic:rsvReason> element can be present several times for the same domain name (of course the same rule is applied to the <frnic:fbdReason> element). Request example to verify the availability of a domain name list: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <check> C: <domain:check C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>afnic.fr</domain:name> C: <domain:name>af-1234-nic.fr</domain:name> C: <domain:name>bois-guillaume.fr</domain:name> C: <domain:name>paris.fr</domain:name> C: <domain:name>trafiquants.fr</domain:name> C: <domain:name>toto.wf</domain:name> C: </domain:check> C: </check> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> The following table indicates the elements present in the <frnic:cd> elements of the (<frnic:chkData>) extension in the server answer: Element Name <frnic:name reserved="" forbidden=""> <frnic:rsvReason> <frnic:fbdReason> • • • Number of occurences 1 0-n 0-n <frnic:name reserved="" forbidden=""> domain name verified, "reserved" can indicate two values 0 or 1, the same goes for "forbidden". <frnic:rsvReason> can indicate the following values (this list may evolve in time) : • City name • Registry process <frnic:fbdReason> can indicate the following value (this list may evolve in time) : • Legal issue Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 55 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 56 Example of the anwser sent by the server (for this type of command, the return code is always 1000, never 1001). Please note that in the answer the "avail" attribute indicates either "1" or "0", but also the protocol authorizing the use of "true" and "false", one or the other can be received. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:chkData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:cd> S: <domain:name avail="0">afnic.fr</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">af-1234-nic.fr</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">bois-guillaume.fr</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">paris.fr</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">trafiquants.fr</domain:name> S: <domain:reason>Forbidden name</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">toto.wf</domain:name> S: <domain:reason>Zone not opened</domain:reason> S: </domain:cd> S: </domain:chkData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:chkData> S: <frnic:domain> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: afnic.fr S: </frnic:name> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: af-1234-nic.fr S: </frnic:name> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="1" forbidden="0"> S: bois-guillaume.fr S: </frnic:name> S: <frnic:rsvReason>City name</frnic:rsvReason> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 56 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 57 S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="1" forbidden="0"> S: paris.fr S: </frnic:name> S: <frnic:rsvReason>City name</frnic:rsvReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="1"> S: trafiquants.fr S: </frnic:name> S: <frnic:fbdReason>Legal issue</frnic:fbdReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: toto.wf S: </frnic:name> S: </frnic:cd> S: </frnic:domain> S: </frnic:chkData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000017</svTRID> S: </trID> S: </response> S:</epp> 3.4.9. Retrieve domain data The <domain:info> command allows to retrieve information on a domain name. Eventhough this command does not replace the Whois command, this command answers with the same type of information and is particularly useful to follow ongoing operations on a domain name. A request on a domain name answers with all the information available as long as the request is made by the registrar in charge of the domain name. In that case, the auth_info is not necessary. The auth_info is necessary when a registrar makes a request on a domain name not present in his portfolio. According to what is described in RFC 5731, we need to define extensions to indicate statuses that are specific to the new commands we have described, deletion with redemption (RFC 3915) also uses an extension. We accept the different values for the "hosts" attribute, that is to say "none" to have no information on the server names, "del" to only have the information concerning the name server list on which the requested domain name is installed, "sub" to know the name server list associated to this domain name and "all" to have both (value by default). Reminder, a domain name can be Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 57 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 58 registered without a technical configuration, which does not block name servers from being associated to the domain itself… Request sent made by the registrar in charge of the domain name: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name hosts="all">ndd-de-test-0001.fr</domain:name> C: </domain:info> C: </info> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Request sent made by the registrar not in charge of the domain name: C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name hosts="all">ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>ALASTOR2012</domain:pw> C: </domain:authInfo> C: </domain:info> C: </info> C: <clTRID>FRNIC-10541-CLIENT-1247215792</clTRID> C: </command> C:</epp> 3.4.9.1.Detail for the "classic" part of the answer The server answer does not contain all of the elements described in RFC 5731. First noteworthy difference, the <domain:roid> element… Eventhough we have unique identifiers for the domain names in our database, these do not quite answer the « book of specifications » defined in the RFC. Indeed, a "roid" should be created each time an object is created in the database; a created domain name, deleted, then created again should get different "roid" for each creation operation. At AFNIC, a unique ID is associated to a domain name during its very first insertion in the database, this ID follows the domain even if it is deleted in the mean time (it is never associated to another). To this unique ID we concatenate the "–FRNIC" suffix, as we do for contact objects. The domain name status can be indicated either in the <resData> part of the answer or in the extensions. However, on the contrary to the RFC, this Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 58 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 59 information is not optional. A domain name that is not in a particular status necessarly has a <domain:status s="ok"/> element present in the <resData> part of the answer. The absence of this element necessarly implies an information on the domain name status is found in the <extension> part of the answer. The elements <domain:crID> (ID of the registrar who created the domain name for the first time), <domain:upID> (ID of registrar who last updated the domain name) and <domain:trDate> (date of the last finished transfer) are not present. The following table indicates the elements <domain:infData> element of the server answer: Element Name <domain:name> <domain:roid> <domain:status s=""> <domain:registrant> <domain:contact type="admin"> <domain:contact type="tech"> <domain :ns> <domain :host> <domain:clID> <domain:crDate> <domain:exDate> <domain:upDate> <domain:authInfo> • • • • • • • • present in the Number of occurences 1 1 0-n 1 1 1-3 0-1 0-n 1 1 1 1 1 <domain:name> domain name subjected to the information request. <domain:roid> Unique ID of the object in our database. <domain:status s=""> indicates a domain name status (that can be under several different status at the same time). Any status that is not found in the list available and described in RFC 5731 must be indicated in an appropriate extension. <domain:registrant> contains the holder identifier obtained by deducting the suffix (FRNIC) and the separator "-" from its own nichandle. <domain:contact type="admin"> contains the adminstrative contact identifier. <domain:contact type="tech"> contains the identifier of a technical contact. <domain:ns> contains the technical configuration of the domain name if it has one. The format is the same as the one used during technical modifications. This information is not present if the value of the "hosts" attribute during the request was indicating "none" or "sub". <domain:host> contains the name server list known by our services and used a name servers for domain names manged by AFNIC. This information is not present if the value of the "hosts" attribute during the request was indicating "none" or "del". Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 59 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • • • • 60 <domain:clID> contains the ID of the registrar that manages the domain name. <domain:crDate>… in the current version of this interface, the timestamping information is not aligned with the role described in RFC 5731 but copied from the "Whois" pattern. The creation date is the last creation date of the domain name or the date of the last transmission (trade or recover). <domain:exDate> contains the supposed expiration date of the domain name (anniversary date). We did not implement the <domain:renew> command and the AFNIC renew mechanism is not the same as the one described in the RFCs on EPP. <domain:upDate> contains the date of the last operation that modified the database for this domain name. On the contrary to what is indicated in RFC 5731, this element is always present, even if no update command was requested. In that case, its value will be equal to the value in the <domain:crDate> element (once again, the existing rules in our "Whois" pattern were kept). <domain:authInfo> contains the auth_info associated to the domain name. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:roid>DOM000000456987-FRNIC</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>MM4567</domain:registrant> S: <domain:contact type="admin">NFC1</domain:contact> S: <domain:contact type="tech">NFC1</domain:contact> S: <domain:contact type="tech">VIL1666</domain:contact> S: <domain:ns> S: <domain:hostAttr> S: <domain:hostName>ns1.nic.fr</domain:hostName> S: </domain:hostAttr> S: <domain:hostAttr> S: <domain:hostName>ns2.nic.fr</domain:hostName> S: </domain:hostAttr> S: <domain:hostAttr> S: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostName> S: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> S: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> S: </domain:hostAttr> S: </domain:ns> S: <domain:host>ns.ndd-de-test-0001.fr</domain:host> S: <domain:host>ns1234.ndd-de-test-0001.fr</domain:host> S: <domain:clID>BEactuelID</domain:clID> S: <domain:crDate>2008-12-25T00:00:00.0Z</domain:crDate> S: <domain:exDate>2009-12-25T00:00:00.0Z</domain:exDate> S: <domain:update>2009-01-10T00:00:00.0Z</domain:update> S: <domain:authInfo> S: <domain:pw>WarlordZ666</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000018</svTRID> S: </trID> S: </response> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 60 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 61 3.4.9.2.Details of the possible extensions of the answer The <domain:info> command can contain additional information in the <extension> part of the answer. Among this can be found information on the deletion/restoration process that correspond to RFC 3915. For example, a deleted domain name in redemption period has the following extension (a part of the <resData> element was also reproduced): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="pendingDelete"/> […] S: </resData> S: <extension> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgpStatus s="pendingDelete"/> S: </rgp:infData> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000019</svTRID> S: </trID> S: </response> S:</epp> With the same domain name, but this time, imagine the holder was not successfully identified yet. The <extension> part of the answer looks like this (<domain:status> element is also present in the <resData> part): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="serverTransferProhibited"/> […] S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000021</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 61 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 62 In addition, if the client has activated the secDNS extension at login and that the domain name has DS records, these will be flagged in the answer inside an extension, according to RFC 5910. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="serverTransferProhibited"/> […] S: </resData> S: <extension> S: <secDNS:infData S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S: <secDNS:dsData> S: <secDNS:keyTag>12345</secDNS:keyTag> S: <secDNS:alg>3</secDNS:alg> S: <secDNS:digestType>1</secDNS:digestType> S: <secDNS:digest>49FD46E6C4B45C55D4AC49FD46E6C4B45C55D4AC </secDNS:digest> S: </secDNS:dsData> S: </secDNS:infData> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000018</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 62 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 63 3.5. Managing a contact A few basic rules: • • • Contacts all have a nic-handle that can be used to reference them in different domain name operations. The nic-handle is NEVER reassigned after removal of contact. Holder contacts must be created before being used in a domain name operation. The qualification data is linked to the holder. The qualification process is done on the contacts. Please note this general information on how postal addresses are managed, that is to say: • • On the contrary to what is indicated in RFC 5731, only one element of type <contact:postalInfo> can be indicated. On the contrary to what is indicated in RFC 5731, only the type "loc" for postal addresses is accepted. 3.5.1. Contact Creation To create a contact object used as holder, AFNIC requests information that are not available in the standard EPP mapping for "contact" objects, it is necessary to offer an extension. In addition, for a contact that requires a difference between first name and last name, <contact:name> must contain the last name when the <frnic:firstName> element of the given extension contains the first name of the contact. In a concrete matter, for any « individual » holder contact, this element is mandatory. Another necessary adaptation of the standard contact mapping (RFC 5733), because uncompatible with our procedures, is the <contact:id> element. Eventhough it is mandatory it is not taken into account by our server. This implies that on the contrary to the EPP standard, the registrar has no choice in the contact identifier during its creation request. AFNIC allocates the contact identifiers according to its own algorithms. Of course, in case of a successful creation, the identifier is indicated in the server answer. On the other hand this identifier can be the one of an already existing contact if the registrar send the same information contained in this contact. For this last case, we add an extension in the server answer. Another mandatory element that is not taken into account because not used is the <contact:authInfo> element. Indeed it is not possible to associate a password to a contact object. But as we did for <contact:id>, we have decided to keep the sent request to ensure a more simple compatibility with the existing client codes. The <contact:disclose> element, optional in the contact mapping, Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 63 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 64 is also not taken into account and therefore must not be present to avoid the command from being rejected with an error. In addition to the <frnic:firstName> element, the extension indicates the information needed to qualify the contacts used as domain holders. A <frnic:individualInfos> element must be present for « individual » holders, and a <frnic:legalEntityInfos> element for « corporate » holders. As for the management of the restricted publishing, the chosen method is with the presence of a « generic » <frnic:list> element that can only contain, for the moment, the "restrictedPublication" value that only applies, for the moment as well, to « individual » contact objects. Here is detailed the element found for individuals: Element Name <frnic:birthDate> <frnic:birthCity> <frnic:birthPc> <frnic:birthCc> • • • • Number of occurences 1 0-1 0-1 1 <frnic:birthDate> contains the contact's date of birth. <frnic:birthCity> contains the contact's birth city. <frnic:birthPc> contains the postal code of the birth city (or the regional code at least). <frnic:birthCc> contains the country code of the place of birth. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 64 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 65 Example of a contact creation containing information in order to be used as an individual domain holder: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>XXXX0000</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>Levigneron</contact:name> C: <contact:org>AFNIC</contact:org> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>[email protected]</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:create> C: <frnic:contact> C: <frnic:list>restrictedPublication</frnic:list> C: <frnic:individualInfos> C: <frnic:birthDate>1968-07-20</frnic:birthDate> C: <frnic:birthCity>Rouen</frnic:birthCity> C: <frnic:birthPc>76000</frnic:birthPc> C: <frnic:birthCc>FR</frnic:birthCc> C: </frnic:individualInfos> C: <frnic:firstName>Vincent</frnic:firstName> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> In the cases of contacts with qualification information, an extension is necessary to indicate the qualification status of the contact. The elements in this extension are indicated in the following table. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 65 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 Element name <frnic:idStatus> <frnic:nhStatus new=""> • • 66 Number of occurences 0-1 1 <frnic:idStatus> is used to indicate the identification status (only present for contacts created with the elements <frnic:individualInfos> or <frnic:legalEntityInfos>) : • no : The contact is not qualified. • pending : The contact is undergoing qualification (with this status the <contact:update> operation is not possible). • ok : The contact is positively qualified. • problem : Problem during the qualification process. This state has an impact on the status of the domains associated with the contact. • ko : At the end of the qualification process the contact could not be positively qualified. <frnic:nhStatus new=""> is used to indicate if the nic-handle was recently created (the value for new is set to 1) or if it using an already existing contact (the value for new is sent to 0). In the creation command response, RFC 5733 indicates the presence of the <contact:crDate> element to indicate the time and date of the contact creation. This date can be retrieved by using the the <contact:info> command. This information must be cautiously interpreted for two reasons. The first is that in our current model (1,5 million contacts are concerned), the creation date was not kept. The second is that it is not coherent with our policy of not duplicating identical contacts... so, eventhough this element is given in the server answer its value may be before the command request date for the cases using an already existing contact (<frnic:nhStatus new="0">). Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 66 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 67 Example of an answer sent by the server (for "contact" objects, the return code is always 1000 if the command is successfully handled). We can note that in this particular case, the fact that <frnic:idStatus> is equal to "ok" for a newly created contact (<frnic:nhStatus new="1">) indicates that VL99999-FRNIC is indeed an « individual » holder contact: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <contact:creData S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>VL99999</contact:id> S: <contact:crDate>2008-11-20T00:00:00.0Z</contact:crDate> S: </contact:creData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:creData> S: <frnic:nhStatus new="1"/> S: <frnic:idStatus>no</frnic:idStatus> S: </frnic:creData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000022</svTRID> S: </trID> S: </response> S:</epp> In the case where the created contact is not an « individual » but a « corporate » entity that requires identification data, either a SIREN number, trademark number or specific information for associations can be given. The standard contact mapping extension allows to indicate these elements. In the extension, the <frnic:firstName> element must not be present. The elements must respect the order of the table below: Element name <frnic:legalStatus s=""> <frnic:siren> <frnic:VAT> <frnic:trademark> <frnic:asso> <frnic:waldec> <frnic:decl> <frnic:publ announce="" page=""> <frnic:DUNS> <frnic:local> Number of occurences 1 0-1 0-1 0-1 0-1 0-1 1 if <frnic:waldec> is absent 1 if <frnic:waldec> is absent 0-1 0-1 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 67 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • • • • • • 68 <frnic:legalStatus s=""> this element is used to indicate with the "s" attribute, the name of the company to identify ("company", "association", "other"). The element is empty except in the cases where the "s" attribute will indicate "other". (Eg: <frnic:legalStatus s="other">Ambassade</frnic:legalStatus>). <frnic:siren> contains the SIREN number. <frnic :VAT> contains the european VAT number, this information is optional. <frnic:trademark> contains a trademark number. <frnic:asso> contains those 2 elements for associations. • <frnic:waldec> indicates the Waldec number of an association. If this identifier is given, it is enough to identify an association. • <frnic:decl> indicates the prefecture declaration date. • <frnic:publ announce="" page=""> contains the Official Journal publication date (the "announce" attributes indicates the announcement number, the "page" attribute indicates the page number of this announcement). <frnic:DUNS> contains a DUNS number. <frnic:local> contain a local identifiant not belonging to any other category. Here is the request with a SIREN number as identification element: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>XXXX0000</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>AFNIC</contact:name> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>[email protected]</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:create> C: <frnic:contact> C: <frnic:legalEntityInfos> C: <frnic:legalStatus s="company"/> C: <frnic:siren>123456789</frnic:siren> C: </frnic:legalEntityInfos> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 68 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 69 Also, the create:contact function can also put directly a validation tag by the registrar on the eligibility and reachability (see Procedures Manual). These elements can be added wether the holder is a corporate entity (PM) or an individual (PP). Element name <frnic:idStatus> <frnic:reachable> Number of occurences 0-1 0-1 C:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" > C: <command> C: <create> C: <contact:create xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>XXXX0000</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>Levigneron</contact:name> C: <contact:org>AFNIC</contact:org> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>vincent.levigneron\@nic.fr</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:create> C: <frnic:contact> C: <frnic:legalEntityInfos> C: <frnic:idStatus>ok</frnic:idStatus> C: <frnic:legalStatus s="company"/> C: <frnic:siren>123456789</frnic:siren> C: </frnic:legalEntityInfos> C: <frnic:reachable media="email">1</frnic:reachable> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 69 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 70 3.5.2. Modifying a contact Updating the data for a contact allows to change some of its elements in respect to the specific rules associated to the different roles it can play for a domain name, an administrative, technical or holder contact. It is also not possible to change the content of a contact associated to an authorization code that has not been used yet. Only the registrar in charge of this contact may request its modification. The authentification process with <contact:authInfo> was not implemented for contact management. Information contained in the elements <frnic:individualInfos> and <frnic:legalEntityInfos> cannot be modified. The same goes for the first and last name of the holder contacts. An extension is necessary to manage the restricted publishing list. This is the example we have chosen here.. The list management is done with elements <contact:add> and <contact:del>. The <frnic:list> element, already presented, is used the same way it is used for a creation. Let's delete the contact VL9999 from the "restrictedPublication" list: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <contact:update C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>VL99999</contact:id> C: </contact:update> C: </update> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:update> C: <frnic:contact> C: <frnic:rem> C: <frnic:list>restrictedPublication</frnic:list> C: </frnic:rem> C: </frnic:contact> C: </frnic:update> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> The server answer is not specific and always with a 1000 return code. In addition the contact:update function makes it possible to put a validation tag by the registrar on the eligibility and the joignability. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 70 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 71 C:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <contact:update C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>VL99999</contact:id> C: </contact:update> C: </update> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:update> C: <frnic:contact> C: <frnic:add> C: <frnic:idStatus>ok</frnic:idStatus> C: <frnic:reachable media="email">1</frnic:reachable> C: </frnic:add> C: </frnic:contact> C: </frnic:update> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> 3.5.3. Deleting a contact Deleting a "contact" object is not available on AFNIC's EPP interface. Indeed, a "garbage collector" deletes old objects that are not referenced. The rule is as follows: any contact not referenced for more than 3 months on another object becomes obsolete, that is to say that it can no longer be used on any type of operation. An obsolete contact will remain in our database for 15 days before being totally deleted. This "garbage collector" works in total transparency and adds notification messages to the registrar's queue concerned with the contact deletion (see § 2.6.3 Exogenous notifications). This will help the registrar to synchronise his database to AFNIC’s database. 3.5.4. Identification of a contact holder This qualiifcation process is done by AFNIC through "off-line" procedures. The impact of a holder qualification status on the possible operations is described in the procedure manual. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 71 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 72 3.5.5. Retrieve data of a contact The <contact:info> command allows to obtain information on a "contact" object. Because of the particular management of these objects, some elements are not present or have a different meaning than what is described in RFC 5733 in the answer sent by the server. Here is the list: <contact:crID> (adapted), <contact:crDate> (adapted), <contact:upID> (deleted), <contact:trDate> (deleted), <contact:authInfo> (deleted) and <contact:disclose> (deleted). In addition, an extension is necessary to take the identification data into account. The value of the <contact:crID> element is the one of the registrar where they are referenced at the time. The value of the <contact:crDate> element is always returned but must be carefully analysed due to the history of contacts at AFNIC. Another limitation different from RFC 5733, only the registrar associated to the contact object can request its information. Example for this request: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <contact:info C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>MO666</contact:id> C: </contact:info> C: </info> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 72 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 73 The server answer is as follows: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> <response> <result code="1000"> <msg>Command completed successfully</msg> </result> <resData> <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> <contact:id>MO666</contact:id> <contact:roid>MO666-FRNIC</contact:roid> <contact:status s="linked"/> <contact:postalInfo type="loc"> <contact:name>Mobibus Outlaws</contact:name> <contact:addr> <contact:street>7, avenue monchignon</contact:street> <contact:city>la Baule Escoublac</contact:city> <contact:pc>44500</contact:pc> <contact:cc>FR</contact:cc> </contact:addr> </contact:postalInfo> <contact:voice>+33.987654321</contact:voice> <contact:email>[email protected]</contact:email> <contact:clID>-wuhgejav499-.fr</contact:clID> <contact:crID>-wuhgejav499-.fr</contact:crID> <contact:crDate>2010-10-12T07:49:45.0Z</contact:crDate> <contact:upDate>2011-07-08T16:41:17.0Z</contact:upDate> </contact:infData> </resData> <extension> <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> <frnic:resData> <frnic:infData> <frnic:contact> <frnic:legalEntityInfos> <frnic:idStatus when="2011-06-21T05:30:36" source="registry">ok</frnic:idStatus> <frnic:legalStatus s="company"/> <frnic:siren>444158265</frnic:siren> </frnic:legalEntityInfos> <frnic:obsoleted>0</frnic:obsoleted> <frnic:reachable when="2011-06-21T05:30:36" media="email" source="registry">1</frnic:reachable> </frnic:contact> </frnic:infData> </frnic:resData> </frnic:ext> </extension> <trID> <clTRID>79105131472048712675</clTRID> <svTRID>PROD-nergal-11983-115-1314720487.7498</svTRID> </trID> </response> </epp> Note that the status in the qualification process is indicated through the <frnic:idStatus> element for the eligibility and the <frnic:reachable> element for the reachability. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 73 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 74 3.6. Notifications 3.6.1. Managing the notification queue Example of a request to retrieve an awaiting message: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> The request to acknowledge the receipt that the message was taken into account by the client of the message in the waiting queue is as follows: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="ack" msgID="50001"/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Example of the answer sent by the server (we consider this is the only awaiting message): S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="0" id="50001"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000006</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 74 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 75 3.6.2. Asynchronous notifications In this chapter we will give notification examples for: • • • • • • • • • • Transfer agreement (incoming registrar) Transfer finished (incoming registrar) Transfer rejected (incoming registrar) Trade finished (incoming registrar) Delete finished Restore finished Create finished Update [admin] finished Update [context] finished Transfer agreement (incoming registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 75 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 76 Transfer finished (incoming registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2008-12-26T00:01:00.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp> • transfer rejected (incoming registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer rejected.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-16T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 76 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 77 trade finished (incoming registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000015</svTRID> S: </trID> S: </response> S:</epp> • delete finished S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16020"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Deletion completed.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27244-CLIENT-1254926575</clTRID> S: <svTRID>TEST-kenobi-6435-29-1254926575.803</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 77 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 78 restore finished S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16020"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Deletion aborted. Domain successfully restored.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FooBar</clTRID> S: <svTRID>frnic-00000025</svTRID> S: </trID> S: </response> S:</epp> S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63478"> S: <qDate>2010-06-04T09:11:27.0Z</qDate> S: <msg>Pending update (restore) completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-27195-CLIENT-1275642606</clTRID> S: <svTRID>DEV-photon-26192-3-1275642606.46913</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-04T09:10:15.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27404-CLIENT-1275643628</clTRID> S: <svTRID>DEV-photon-27325-3-1275643628.62759</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 78 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 79 create finished S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63263"> S: <qDate>2010-06-03T15:23:23.0Z</qDate> S: <msg>Pending creation completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">dom-epp-wytxubuz.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-18673-CLIENT-1275578515</clTRID> S: <svTRID>DEV-photon-18294-4-1275578517.15639</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-03T15:22:09.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-18687-CLIENT-1275578623</clTRID> S: <svTRID>DEV-photon-18318-12-1275578623.9696</svTRID> S: </trID> S: </response> S:</epp> • update [admin] finished S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63482"> S: <qDate>2010-06-04T10:30:28.0Z</qDate> S: <msg>Pending update (contacts) completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">dom-epp-hyclebod.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-27901-CLIENT-1275647287</clTRID> S: <svTRID>DEV-photon-27377-4-1275647289.31733</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-04T10:28:32.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27920-CLIENT-1275647486</clTRID> S: <svTRID>DEV-photon-27344-7-1275647486.82448</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 79 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 80 update [context] finished S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63480"> S: <qDate>2010-06-04T09:52:28.0Z</qDate> S: <msg>Pending update (hold/authInfo) completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain- 1.0"> S: <domain:name paResult="1">dom-epp-hyclebod.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-27505-CLIENT-1275645007</clTRID> S: <svTRID>DEV-photon-27393-9-1275645009.72202</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-04T09:50:28.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27522-CLIENT-1275645283</clTRID> S: <svTRID>DEV-photon-27331-8-1275645283.06911</svTRID> S: </trID> S: </response> S:</epp> 3.6.3. Exogenous notifications In this chapter we will give notification examples for: • • • • • • • • • • • • • • • • • • • • Transfer requested (outgoing registrar) Transfer agreement (incoming registrar) Transfer finished (outgoing registrar) Transfer canceled Trade initiated (outgoing registrar) Trade outgoing holder agreement Trade incoming holder agreement Trade incoming and outgoing holder agreement Trade finished (outgoing registrar) Trade canceled Recover finished (outgoing registrar) Start of qualification procedure End of qualification procedure Switch to substantiation procedure Suspension of a domain name Blocking of a domain name Unblocking of a domain name End of the Substantiation procedure with deletion of the portfolio positive outcome of the Substantiation procedure with unblocking of the portfolio and updating of the WHOIS database Contact deletion Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 80 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 81 Transfer requested (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50002"> S: <qDate>2008-12-25T00:02:00.0Z</qDate> S: <msg>Transfer requested.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp> • Transfer agreement (incoming registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="28981"> S: <qDate>2009-10-06T16:27:19.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2009-10-06T16:27:08.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-10-06T16:27:19.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 81 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 82 Transfer finished (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="28982"> S: <qDate>2009-10-06T16:27:20.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>TEST_2</domain:reID> S: <domain:reDate>2009-10-06T16:27:08.0Z</domain:reDate> S: <domain:acID>TEST</domain:acID> S: <domain:acDate>2009-10-06T16:27:20.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>FRNIC-17331-CLIENT-1254902552</clTRID> S: <svTRID>DEV-photon-17205-4-1254902552.81518</svTRID> S: </trID> S: </response> S:</epp> • Transfer canceled (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16022"> S: <qDate>2009-10-07T14:18:33.0Z</qDate> S: <msg>Transfer aborted.</msg> S: </msgQ> S: <resData> S: <domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-001.fr</domain:name> S: <domain:trStatus>clientCancelled</domain:trStatus> S: <domain:reID>-huqlycuw772-.fr</domain:reID> S: <domain:reDate>2009-10-07T14:18:31.0Z</domain:reDate> S: <domain:acID>-huqlycuw772-.fr</domain:acID> S: <domain:acDate>2009-10-07T14:18:33.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>FRNIC-27244-CLIENT-1254926575</clTRID> S: <svTRID>TEST-kenobi-6591-24-1254926575.49702</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 82 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 83 Transfer canceled (incoming registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16020"> S: <qDate>2009-10-07T14:18:33.0Z</qDate> S: <msg>Transfer aborted.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test-001.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-25860-CLIENT-1254925111</clTRID> S: <svTRID>TEST-kenobi-5723-27-1254925111.01848</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-10-07T14:18:31.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27244-CLIENT-1254926575</clTRID> S: <svTRID>TEST-kenobi-6435-29-1254926575.803</svTRID> S: </trID> S: </response> S:</epp> • Trade initiated (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50010"> S: <qDate>2009-12-25T00:02:00.0Z</qDate> S: <msg>Trade requested.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-16T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 83 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 84 Trade outgoing holder agreement S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50011"> S: <qDate>2009-01-02T00:00:01.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>oldHolderApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000013</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 84 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 85 Trade incoming holder agreement S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="62373"> S: <qDate>2010-05-28T16:06:25.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>gateway-dev-1275062768-286.fr</frnic:name> S: <frnic:trStatus>newHolderApproved</frnic:trStatus> S: <frnic:reID>-naqjanir666-.fr</frnic:reID> S: <frnic:reDate>2010-05-28T16:06:18.0Z</frnic:reDate> S: <frnic:reHldID>IP649</frnic:reHldID> S: <frnic:rhDate>2010-05-28T16:06:25.0Z</frnic:rhDate> S: <frnic:acID>TEST</frnic:acID> S: <frnic:ahDate>2010-06-12T16:06:18.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-25057-CLIENT-1275400281</clTRID> S: <svTRID>DEV-photon-23773-7-1275400281.18398</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 85 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 86 Trade outgoing and incoming holder agreement S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50012"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>holdersApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-03T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000014</svTRID> S: </trID> S: </response> S:</epp> • Trade finished (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="423754"> S: <qDate>2009-08-28T14:49:55.0Z</qDate> S: <msg>Trade completed.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ventedentreprise.fr</frnic:name> S: <frnic:trStatus>clientApproved</frnic:trStatus> S: <frnic:reID>-ryjzifyz909-.fr</frnic:reID> S: <frnic:reDate>2009-08-28T15:54:53.0Z</frnic:reDate> S: <frnic:acID>-vycfazur780-.fr</frnic:acID> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-8234-51-1251471004.60964</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 86 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 87 Trade canceled (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="97" id="80527"> S: <qDate>2009-05-13T01:10:05.0Z</qDate> S: <msg>Trade aborted.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>moskitul.fr</frnic:name> S: <frnic:trStatus>clientCancelled</frnic:trStatus> S: <frnic:reID>-xanmaqub851-.fr</frnic:reID> S: <frnic:reDate>2009-04-27T14:49:37.0Z</frnic:reDate> S: <frnic:rhDate>2009-05-12T12:49:37.0Z</frnic:rhDate> S: <frnic:ahDate>2009-05-12T12:49:37.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-6724-12-1251461542.74779</svTRID> S: </trID> S: </response> S:</epp> • Recover finished (outgoing registrar) S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="207" id="59166"> S: <qDate>2010-04-15T02:20:50.0Z</qDate> S: <msg>Recover completed.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:recData> S: <frnic:domain> S: <frnic:name>identification-histo-problem.fr</frnic:name> S: <frnic:reID>-hexfyreg992-.fr</frnic:reID> S: <frnic:reDate>2010-04-15T02:20:48.0Z</frnic:reDate> S: <frnic:reHldID>NFC11</frnic:reHldID> S: <frnic:acID>TEST</frnic:acID> S: </frnic:domain> S: </frnic:recData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-25906-CLIENT-1275402635</clTRID> S: <svTRID>DEV-photon-25788-3-1275402635.52974</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 87 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 88 Start of qualification procedure S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="100" id="3006545"> S: <qDate>2011-08-29T15:13:00.0Z</qDate> S: <msg>Qualification process begins.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="start"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>pending</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>pending</frnic:reStatus> S: <frnic:voice>+33.123456789</frnic:voice> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-8-1914719304.12345</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 88 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 89 End of qualification procedure If reachability and/or eligibility checks succeed S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="110" id="3006645"> S: <qDate>2011-08-29T15:14:00.0Z</qDate> S: <msg>Qualification process finished.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="finished"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>ok</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>ok</frnic:reStatus> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-8-1914719404.12345</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 89 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 90 If reachability and/or eligibility checks fail S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="110" id="3006645"> S: <qDate>2011-08-29T15:14:00.0Z</qDate> S: <msg>Qualification process finished.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="finished"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>ko</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>ok</frnic:reStatus> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-8-1914719404.12345</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 90 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 91 Switch to substantiation procedure In the event of a complaint, or a report without being able to check the eligibility and reachability data, or contact details that are implausible. S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="120" id="3006745"> S: <qDate>2011-08-29T15:14:00.0Z</qDate> S: <msg>Qualification process in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="problem"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>ko</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>ok</frnic:reStatus> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-9-1914819404.12345</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 91 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 92 Suspension of a domain name CAUTION: this notification is sent as many times as there are suspended domain names. S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="2849"> S: <qDate>2009-05-05T07:52:50.0Z</qDate> S: <msg>Holder qualification status prevents some operations.</msg> S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nic.fr</domain:name> S: <domain:roid>DOM000002018460-FRNIC</domain:roid> S: <domain:status s="serverTransferProhibited"/> S: <domain:registrant>XXX1234</domain:registrant> S: <domain:clID>-rocfisor895-.fr</domain:clID> S: </domain:infData> S: </resData> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-31789-CLIENT-1241510727</clTRID> S: <svTRID>DEV-photon-31648-2-1241510727.18924</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 92 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 93 Blocking of a domain name CAUTION: this notification is sent as many times as there are blocked domain names. S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="2849"> S: <qDate>2009-05-05T07:52:50.0Z</qDate> S: <msg>Holder qualification status prevents some operations.</msg> S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nic.fr</domain:name> S: <domain:roid>DOM000002018460-FRNIC</domain:roid> S: <domain:status s="serverHold"/> S: <domain:status s="serverDeleteProhibited"/> S: <domain:status s="serverUpdateProhibited"/> S: <domain:status s="serverTransferProhibited"/> S: <domain:registrant>XXX1234</domain:registrant> S: <domain:clID>-rocfisor895-.fr</domain:clID> S: </domain:infData> S: </resData> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-31789-CLIENT-1241510727</clTRID> S: <svTRID>DEV-photon-31648-2-1241510727.18924</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 93 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 94 Unblocking of a domain name The status of the domain names switches from serverHold to serverProhibited if the unblocking does not correspond to the end of the Substantiation procedure. The status of the domain names switches from serverHold to ok if the unblocking corresponds to positive outcome of the Substantiation procedure. CAUTION: this notification is sent as many times as there are domain names. S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue S: </result> S: <msgQ count="15" id="198375"> S: <qDate>2011-11-10T06:42:50.0Z S: <msg>Holder qualification status doesn't prevent operations any longer. S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nomdomaine1.fr S: <domain:roid>DOM000001978303-FRNIC S: <domain:status s="inactive"/> S: <domain:registrant>BVJN1 S: <domain:contact type="admin">BLST1 S: <domain:contact type="tech">BLST1 S: <domain:clID>TEST S: <domain:crDate>2011-11-10T06:42:48.0Z S: <domain:exDate>2012-11-10T00:00:00.0Z S: <domain:upDate>2011-11-10T06:42:48.0Z S: <domain:authInfo> S: <domain:pw>authInfo S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>DOM000001978303-FRNIC S: <svTRID>DEV-photon-2257-3-1320930348.06826 S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 94 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 95 End of the Substantiation procedure with deletion of the portfolio Notification of the end of the qualification procedure has already been described earlier in this chapter. To this are added the notifications for the deleted domain names. CAUTION: this notification is sent as many times as there are domain names. S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="2849"> S: <qDate>2009-05-05T07:52:50.0Z</qDate> S: <msg>Domain deletion after failure in qualification process.</msg> S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nomdomaine1.fr</domain:name> S: <domain:roid>DOM000001978303-FRNIC</domain:roid> S: <domain:status s="serverHold"/> S: <domain:status s="pendingDelete"/> S: <domain:registrant>ET1323</domain:registrant> S: <domain:contact type="admin">VL999</domain:contact> S: <domain:contact type="tech">VL666</domain:contact> S: <domain:clID>-wuhgejav499-.fr</domain:clID> S: <domain:authInfo> S: <domain:pw>WarlordZ666</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgp:rgpStatus s="pendingDelete"/> S: </rgp:infData> S: </extension> S: <trID> S: <clTRID>FRNIC-31789-CLIENT-1241510727</clTRID> S: <svTRID>DEV-photon-31648-2-1241510727.18924</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 95 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • 96 Positive outcome of the Substantiation procedure with unblocking of the portfolio and updating of the WHOIS database This case corresponds to the transmission of the notifications already described (“If reachability and/or eligibility checks succeed” and “Unblocking of a domain name”). • Contact deletion S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="25006"> S: <qDate>2010-02-03T11:37:46.0Z</qDate> S: <msg>Contact deletion completed</msg> S: </msgQ> S: <resData> S: <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>BE408</contact:id> S: <contact:roid>BE408-FRNIC</contact:roid> S: <contact:status s="ok"/> S: <contact:postalInfo type="loc"> S: <contact:name>Eponge</contact:name> S: <contact:addr> S: <contact:street>1, rue de la mare</contact:street> S: <contact:city>Paris</contact:city> S: <contact:pc>75001</contact:pc> S: <contact:cc>FR</contact:cc> S: </contact:addr> S: </contact:postalInfo> S: <contact:voice>+33.654321789</contact:voice> S: <contact:email>[email protected]</contact:email> S: <contact:clID>-huqlycuw772-.fr</contact:clID> S: <contact:crID>-huqlycuw772-.fr</contact:crID> S: <contact:crDate>2009-10-21T09:40:34.0Z</contact:crDate> S: <contact:upDate>2009-10-21T09:40:34.0Z</contact:upDate> S: </contact:infData> S: </resData> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:contact> S: <frnic:firstName>Bob</frnic:firstName> S: </frnic:contact> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-17859-CLIENT-1267782109</clTRID> S: <svTRID>TEST-kenobi-23883-5-1267782109.19864</svTRID> S: </trID> S: </response> S:</epp> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 96 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 97 3.7. Return codes and error messsages Eventhough we strongly recommend to refer yourself to RFC 4930 that contains the complete list of all the return codes that can be sent by the EPP server following a client command, we indicate further down the ones really implemented in our server. You will also find the list of error messages the server may return when necessary. Correctly understanding the return codes is important. Their list will not evolve and the codes are not ambiguous. As for the error messages it is not safe to script them. They can evolve with new administrative rules, some cases may be refined for instance. Most of the time they will be associated to a part of the client request with the problematic elements reproduced in the server answer. In addition, even if at the time of writting this document, only the english language is available as a language choice, any new language will lead to the localisation of the messages. The return codes are not impacted by this « problem ». Here is a message example returned by the server following an erroneous command: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="2306"> S: <msg>Parameter value policy error</msg> S: <extValue> S: <value xmlns:dmn="urn:ietf:params:xml:ns:domain-1.0"> S: <dmn:name>dom-epp-defquruz-xucmexip.com</dmn:name> S: </value> S: <reason>not an AFNIC zone</reason> S: </extValue> S: </result> S: <msgQ count="3" id="28980"/> S: <trID> S: <clTRID>FRNIC-11642-CLIENT-1254846489</clTRID> S: <svTRID>DEV-photon-11442-17-1254846489.34186</svTRID> S: </trID> S: </response> S:</epp> 3.7.1. Return codes Return codes (element <result code="xyzz">) answer to a logic and are coded on 4 numbers. A problem with EPP is that the list is fixed and cannot be extended. Eventhough using a generic return code is possible and adding new codes in the AFNIC extension, we have chosen to modify the sandard and add 3 new codes to the existing list. The logic of the codes has been kept untouched. To recognize the new codes, you need to remember that the third number on the left will alway be 9 (<result code="xy9z">). You will also find in RFC 4930 the literal values associated to the codes that are sent in the <msg> element. If the server was to be localised, a corresponding translation would be given and the meaning of the heading would be kept. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 97 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 98 The « 1000 series » corresponds to codes returned when the operation requested by the client was taken into account. • • • • • 1000 : Is the normal return code for a command that was handled normaly and totally executed and that is not part of other return codes in this series. 1001 : This code indicates the command was taken into account but that its complete execution is delayed. The final result will be known later on and will sent in a message placed in the notification queue of the concerned registrar(s). The number of commands for which this code will be systematically returned is limited but would also be returned when, for an unusual reason, the server should need to postpone the execution of a command usually answering a 1000 code. 1300 : This return code is reserved to the use of the <poll> command (in question mode) and indicates there are no awaiting messages. 1301 : This code is also reserved for the <poll> command and will be used to indicate there is one message in the server answer and that this message is ready to be deleted of the message queue. 1500 : This return code will be used to answer to the logout request (<logout>) that was successful. The « 2000 series » corresponds to codes returned when a problem was detected and that the command could not be taken normally into account. • • • • • • • • • 2000 : Code returned when the command is unknown. 2001 : Code returned when a syntax error is found. 2002 : Code returned when the received command, correct on a syntax point of view, cannot be understood because of its context. For instance, if a logout command is received when the same client has not finished the connection phase... 2003 : Code returned when a compulsory parameter is missing in the command. For instance, a <transfer op="query"> command without the <authInfo> element… 2004 : Code returned when an element value is not within the limits specified by the EPP protocol. For instance, trying to create a domain "too-much-dashes- -and-spaces.fr" will return this error. 2101 : This code will be returned when the server will receive a command incorrect on the EPP level but not present in our implementation. For instance the <contact:transfer> command. 2102 : This code is returned when a command implemented on our server requested by a client includes an option not taken into account. 2103 : This code is returned if the client send a command with an extension not know by the server. 2106 : Code returned when a <domain:transfer> command is done on a domain name for which it is not possible. For instance, if the request comes from a registrar already in charge of the domain name. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 98 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • • • • • • • • • • • • • 99 2190 : Return code similar to 2106 but in the case of a <trade> command. (Code added by ourselves and not defined in the EPP standard. 2200 : Code returned during a login/password verification during the EPP server connection phase. 2201 : Code returned when a command is being executed by a registrar with no rights. For instance, a registrar that would try to send a "cancel" command on a outgoing domain name following a transfer operation. 2202 : Code returned when the registrar requesting the command could have done so if he had given the correct authorizations. Typically, this code will be used during a transfer request when the password (<authInfo>) is invalid. 2300 : Code returned when a domain transfer command is sent and the domain is alreay undergoing a transfer. 2304 : Code returned when the status of an object is not compatible with the command sent to the server. For instance, in case a technical update command is sent for a deleted domain name under redemption. 2305 : Code returned when a command cannot be executed because relations with other objects in the database are blocking. For instance, during a domain deletion request when some name servers are still being used with this zone on other domain names managed by AFNIC. 2306 : Code returned when the value of an element respects the EPP syntax but does not respect a specific AFNIC rule. Most of the time this error will indicate the problematic element but also a message indicating which rule was not respected. It is possible that this error message should not be present, as this code is being used as a value by default. The case where this code could be returned, for instance, is when an individual contact with civil status data (a potential domain holder) will be used as a technical contact during a command. 2390 : This code is returned during a <trade> command when used on a domain name already undergoing a transmission. 2391 : This code is returned when a cancel <trade> command or a <trade> information request is sent when there is no ongoing <trade> on this domain name. 2400 : Code returned when an internal problem prevents a command from being successfully completed. Normally this code should not be returned often, its presence indicates there are some problems on our registration chain. In any case, it is wise to inform the AFNIC support team in case you find this error code. 2500 : Code returned in a similar case to the 2400 code. In this case the server decides to end the session. This case should not occur often. 2501 : This code is returned if the <login> phase cannot be completed. 2502 : This code will be returned if, in the case the number of sessions per registrar would be limited, that the limit has been reached when a new <login> command is sent. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 99 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 100 3.7.2. Error messages The list of messages further down corresponds to what will be indicated in the server answer element <msg>. The complete list of messages can be found in RFC 4930, and may be suject to change. Some cases may be refined, some dissapear according to registration policy changes for example. For the moment, only an english version of these messages is available. In the future they may be localized like the rest of the EPP server. The first list refers to errors that can be returned during domain name operations. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • « not an AFNIC zone » « zone is not opened for registration » « domain name in use » « domain name doesn't exist » « domain name in use (deletion process) » « domain name in use (deletion process, waiting for purge) » « bad syntax » « registry bad syntax » « forbidden Name » « city name (AFNIC authinfo mandatory) » « special request (AFNIC authinfo mandatory) » « protected Sub Level Domain (AFNIC authinfo mandatory) » « protected label syntax (AFNIC authinfo mandatory) » « no operation allowed on this domain name » « authinfo value is not correct » « authinfo/holder/registrar/domain relationship is invalid » « legal entity infos seems to be incorrect » « there are still subordinate hosts » « registrant is not a sponsored contact » « registrant is not a "physical person" » « registrant seems to have a bad birth date » « registrant seems to be under 18 » « registrant seems to be too old » « identification data problem » « registrant is obsoleted » « “physical persons” can only register .fr/.re domain names » « admin contact has no E-Mail address » « admin contact has no phone number » « admin contact is not a sponsored contact » « admin contact doesn't exist » « admin contact is obsoleted » « tech contact doesn't exist » « tech contact is not a sponsored contact » « potential holder physical person contact can't be used as a tech contact » Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 100 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • • • • • • • • • 101 « other operation in progress » « glue is needed for this name server » « holder identification problem prevents it's usage » « holder identification problem prevents operation » « legal issue prevents operation » « pending request prevents operation » « mandatory admin or technical contact is missing » « similar domain name already exists » « domain name MUST have, at least, TWO different name servers » « domain name MUST have either 0 or, at least, TWO different name servers » The second list refers to errors that can be returned during contact operations. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • « country code is illegal » « country code is undefined » « street is illegal » « street is undefined » « post code is illegal » « post code is undefined » « city is illegal » « city is undefined » « city cedex is illegal for this country » « city cedex is illegal » « birth place geographical check failure » « non-profit announcePage mandatory if publishedDate present » « non-profit publishedDate mandatory if announcePage present » « can't update contact disclosure restriction for legal entitie holders » « can't update contact disclosure restriction for tech class » « can't update contact country code for tech class » « can't update phone number » « 'legalStatus' value is illegal » « phone number is illegal » « fax number is illegal » « bogus organization contact without extended data. Should not exist. Must not be used in operations » « waldec ID prohibited if 'legalStatus' is set to 'company' » « non-profit publishedDate prohibited if 'legalStatus' is set to 'company' » « 'siren' or 'trademark' element missing while it's mandatory » « 'trademark' element value seems to be syntaxically incorrect according AFNIC rules » « role objects can't be updated through EPP interface » « 'siren' element value seems to be syntaxically incorrect according AFNIC rules » « contact handle is illegal » « registrant doesn't exist » 3.8. RFCs Here is a reminder of the RFCs to imperatively read on which our EPP implemenntation was done: Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 101 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 • • • • • • • • 102 RFC 3375 - protocole registry-registrar : http://www.ietf.org/rfc/rfc3375.txt RFC 5730 – Extensible Provisioning Protocol (EPP) : http://www.ietf.org/rfc/rfc5730.txt RFC 5731 - Domain Name Mapping : http://www.ietf.org/rfc/rfc5731.txt RFC 5732 – Host Mapping : http://www.ietf.org/rfc/rfc5732.txt RFC 5733 – Contact Mapping : http://www.ietf.org/rfc/rfc5733.txt RFC 5734 - EPP over TCP : http://www.ietf.org/rfc/rfc5734.txt RFC 3915 - Domain Registry Grace Period mapping : http://www.ietf.org/rfc/rfc3915.txt RFC 5910 - Domain Name System (DNS) Security Extensions Mapping: http://www.rfc-editor.org/rfc/rfc5910.txt 4. Web interface : the ticket system 4.1. General principles on tickets All operations on the domain names via the Web interface and involving an asynchronous operation (update[tech], delete, trade, transfer) may be followed through a ticket and information message system sent by email. In AFNIC's internal information system, a ticket is sent as soon as a request is received by Web interface and considered as valid. A status system allows a follow-up on the evolution and handling of the operation. 4.2. Ticket format A ticket has a number un the form NIC0000000xxxxx/xxxxxx. It systematically has the fields DOMAINE=XXX, TICKET=numéro ticket,OPERATION=XXX and ETAT=XXX. du Other fields may appear according to the operation. 4.3. Description of all the tickets S Operation S : Domain deletion Existing status : Fini (finished) S - Finished From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC00001234567] To: noc [Texte introductif] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 102 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 103 DOMAINE=nom-de-domaine-concerne.fr OPERATION=Suppression ETAT=Fini TICKET=NIC00001234567/751825 FORMULAIRE=4869407 REFERENCE= NUMEROSEQUENCE=2 [Texte conclusif] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 103 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 T 104 Operation T : Technical modification on a domain Existing status : Abandonné (canceled), Fini (finished) T - Finished From: [email protected] Subject: Re: FR-NIC, nom-de-domaine-concerne.fr: Formulaire Online [1234567] T To: noc | Infos sur l'opération et le bureau d'enregistrement | 1a. (C)réation (D)élégation (S)uppression.........: | 1b. Code du bureau d'enregistrement...............: | 1c. Mot de passe du bureau d'enregistrement.......: | 1e. Référence client..............................: | 1f. Version formulaire............................: | | Infos sur le nom de domaine | 2a. Nom de domaine complet........................: domaine-concerne.fr | [../..] | Serveur de nom primaire pour le domaine | 6a. Serveur primaire..............................: | 6b. Adresse(s) IP du primaire.....................: | | Serveur(s) de nom secondaire pour le domaine | 7a. Serveur secondaire............................: | 7b. Adresse(s) IP du secondaire...................: | 7c. Serveur secondaire............................: | 7d. Adresse(s) IP du secondaire...................: | 7e. Serveur secondaire............................: | 7f. Adresse(s) IP du secondaire...................: | 7g. Serveur secondaire............................: | 7h. Adresse(s) IP du secondaire...................: | 7j. Adresse(s) IP du secondaire...................: | 7k. Serveur secondaire............................: | 7l. Adresse(s) IP du secondaire...................: | 7m. Serveur secondaire............................: | 7n. Adresse(s) IP du secondaire...................: T CODEBE xxxxxxxx refclient 2.5.0 nom-de- ns.exemple.fr nt.exemple.fr Bonjour, ZONE NS NS : nom-de-domaine-concerne.fr : ns.exemple.fr : nt.exemple.fr ==> SUCCESS [Texte conclusif] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 104 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 105 T - Canceled From: [email protected] Subject: Re: FR-NIC, nom-de-domaine-concerne.fr: Formulaire Online [1234567] T To: noc | Infos sur l'opération et le bureau d'enregistrement | 1a. (C)réation (D)élégation (S)uppression.........: T | 1b. Code du bureau d'enregistrement...............: CODEBE | 1c. Mot de passe du bureau d'enregistrement.......: xxxxxxxx | 1e. Référence client..............................: refclient | | Infos sur le nom de domaine | 2a. Nom de domaine complet........................: nom-dedomaine-concerne.fr | [../..] | Serveur de nom primaire pour le domaine | 6a. Serveur primaire..............................: ns.exemple.fr | 6b. Adresse(s) IP du primaire.....................: | | Serveur(s) de nom secondaire pour le domaine | 7a. Serveur secondaire............................: nt.exemple.fr | 7b. Adresse(s) IP du secondaire...................: | 7c. Serveur secondaire............................: | 7d. Adresse(s) IP du secondaire...................: | 7e. Serveur secondaire............................: | 7f. Adresse(s) IP du secondaire...................: | 7g. Serveur secondaire............................: | 7h. Adresse(s) IP du secondaire...................: | 7i. Serveur secondaire............................: | 7j. Adresse(s) IP du secondaire...................: | 7k. Serveur secondaire............................: | 7l. Adresse(s) IP du secondaire...................: | 7m. Serveur secondaire............................: | 7n. Adresse(s) IP du secondaire...................: Bonjour, Le zone-check ne passe pas : f> Toutes les adresses IP doivent être distinctes | Conseil: ZoneCheck | To avoid losing all connectivity with the autoritative DNS in case of | network outage it is advised to host the DNS on different networks. | | Réf: IETF RFC2182 (Abstract) | The Domain Name System requires that multiple servers exist for every | delegated domain (zone). This document discusses the selection of | secondary servers for DNS zones. Both the physical and topological | location of each server are material considerations when selecting | secondary servers. The number of servers appropriate for a zone is also | discussed, and some general secondary server maintenance issues | considered. `----- -- -- - - : Les serveurs de noms ns.exemple.fr., nt.exemple.fr. : utilisent la même adresse IP (10.0.0.1). `..... .. .. . . . => générique ==> ÉCHEC Veuillez donc : - Verifier votre nouvelle configuration avec zone-check Pour cela vous pouvez utiliser sur l'url suivante http://www.afnic.fr/outils/zonecheck/zc.cgi?afnic&intro=t&explain=t&details =t&progress=counter&zone=nom-de-domaineconcerne.fr&ns0=ns.exemple.fr&ns1=nt.exemple.fr - REFAIRE une demande de modification (via le formulaire on-line ou via mel a l'adresse [email protected]) [Texte conclusif] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 105 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 P 106 Operation P : Voluntary transmission Existing status : Attente Mail (awaiting email validation), Abandonné (canceled), Fini (finished) From: NIC France Formulaire Online <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Transmission demandee / Transmission requested To: noc bureau d’enregistrement sortant [English version below] Madame, Monsieur, Nous vous informons que nous avons reçu une demande de transmission du nom de domaine 'nom-de-domaine-concerne.fr', de Titulaire-sortant vers Titulaire-entrant. Nous sommes actuellement dans l'attente de la validation des cédant et repreneur. Sans réponse avant 15 jours, la demande sera abandonnée. [...] From: NIC France Formulaire Online <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Transmission demandee / Transmission requested To: titulaire entrant [English version below] Madame, Monsieur, Nous vous informons que nous avons reçu une demande de transmission du nom de domaine 'nom-de-domaine-concerne.fr', de Titulaire-sortant vers Titulaire-entrant. Il semble que vous demandez à devenir le nouveau titulaire de ce nom de domaine. Afin d'accepter ou refuser cette transmission, veuillez cliquer l'un des liens suivants. -----------------------------------------------------------------------------ATTENTION: une fois que vous aurez cliqué sur un lien, vous ne pourrez pas modifier votre réponse ! ------------------------------------------------------------------------------ Acceptez cette transmission: http://... - Refusez cette transmission: http://... Faute de réponse avant 15 jours, la demande sera abandonnée. [...] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 106 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 107 From: NIC France Formulaire Online <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Transmission demandee / Transmission requested To: titulaire sortant [English version below] Madame, Monsieur, Nous vous informons que nous avons reçu une demande de transmission du nom de domaine 'nom-de-domaine-concerne.fr', de Titulaire-sortant vers Titulaire-entrant. Il semble que vous soyez l'actuel titulaire de ce nom de domaine. Afin d'accepter ou refuser cette transmission, veuillez cliquer l'un des liens suivants. -----------------------------------------------------------------------------ATTENTION: une fois que vous aurez cliqué sur un lien, vous ne pourrez pas modifier votre réponse ! ------------------------------------------------------------------------------ Acceptez cette transmission: http://... - Refusez cette transmission: http://... Faute de réponse avant 15 jours, la demande sera abandonnée. [...] P – Awaiting Email Validation From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Attente Mail [NIC000012345678] To: noc [Texte introductif] DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Attente Mail TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=1 La transmission demandée est en 'Attente Mail'. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 107 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 108 P – Canceled From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Abandonne [NIC000012345678] To: noc Système de gestion des tickets : (Documentation = <URL: http://www.afnic.fr/doc/interface/tickets >) DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Abandonne TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=2 Opération abandonnée. Expiration Delai 15 jours P - Finished From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC000012345678] To: noc Système de gestion des tickets : (Documentation = <URL: http://www.afnic.fr/doc/interface/tickets >) DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Fini TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=3 AUTH_INFO=XXXXX-111116ZZZZZ-00000 TITU_NH=ABC123-FRNIC TITU_KEY=ABCDEF-123 [email protected] [Texte conclusif] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 108 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 P 109 Operation P : Forced transmission Existing status : Attente Vérification (awaiting verification), Fini (finished) P – Awaiting verification From: Subject: To: noc (in progress) P - Finished From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC000012345678] To: noc Système de gestion des tickets : (Documentation = <URL: http://www.afnic.fr/doc/interface/tickets >) DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Fini TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=2 AUTH_INFO=XXXXX-111116ZZZZZ-00000 TITU_NH=ABC123-FRNIC TITU_KEY=ABCDEF-123 [email protected] Opération effectuée. [Texte conclusif] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 109 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 D 110 Operation D : Registrar change Existing status : Attente Opposition (awaiting opposition), Attente Accord (awaiting agreement), Abandonne (canceled), Attente Verification (awaiting verification), Fini (finished) D – Awaiting opposition From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Attente Opposition To: noc bureau d’enregistrement entrant Madame, Monsieur, Une demande de résiliation a été envoyée à l'ancien prestataire (AFNIC registry). Un délai de 8 jours lui est accordé, pour s'opposer à cette opération. En cas de réponse favorable, ou faute de réponse à cette date, la délégation sera transférée. En cas de réponse négative, le délai initial sera porte à 22 jours. Nous vous rappelons qu'il est du devoir de votre client d'informer son ancien prestataire de sa volonté de résilier la gestion de son domaine. Ceci doit être fait par lettre recommandée avec accusé de réception. Dans l'intéret de tous et pour accélérer la procédure, nous vous demandons de le rappeler à votre client. [Texte conclusif] D – Awaiting opposition From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne: Attente Opposition To: noc bureau d’enregistrement sortant Madame, Monsieur, Nous vous envoyons ce message pour vous signaler que nous avons reçu une demande de changement de prestataire sur le domaine : DOMAINE=nom-de-domaine-concerne.fr OPERATION=Changement P ETAT=Attente Opposition Il semble que ce soit votre Société (AFNIC registry) qui ait actuellement la gestion de ce domaine. En cas d'accord, veuillez renvoyer ce message à [email protected] en ne conservant que les lignes suivantes : [------------------------------------------------------------------] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 110 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 111 AUTH=71C60595D551E2C3 ACTION=ACCORD [------------------------------------------------------------------] Ou en cas de désaccord, veuillez renvoyer ce message à [email protected] avant le 20/11/2009 en ne conservant que les lignes suivantes : [------------------------------------------------------------------] AUTH=71C60595D551E2C3 ACTION=OPPOSITION [------------------------------------------------------------------] Faute de réponse dans les 8 jours suivant la saisie, la délégation sera transférée. [Texte conclusif] D – Finished From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC00001234567] To: noc bureau d’enregistrement entrant [Texte introductif] DOMAINE=nom-de-domaine-concerne.fr OPERATION=Changement P ETAT=Fini TICKET=NIC00001234567/484934 FORMULAIRE=4869185 REFERENCE= NUMEROSEQUENCE=3 From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Delegation Resiliee To: noc bureau d’enregistrement sortant Madame, Monsieur, Nous venons de changer la délégation du domaine nom-de-domaineconcerne.fr au profit d'un nouveau prestataire. Pour que ce changement de délegation se déroule dans de bonnes conditions, nous vous demandons de rester "secondaire non officiel" le temps nécessaire à la propagation des nouvelles informations (au moins 5 jours). Si vos serveurs de nom étaient autoritaires pour le domaine sus-cité (en primaire ou secondaire), nous vous demandons de vous déclarer secondaire pour le domaine concerné et d'indiquer la machine [BUG] (DNS=[BUG] ) comme origine. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 111 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 112 5.Operations that can only be handled by email/fax For situations that require en email or fax answer, an email is sent from [email protected] in addition to the information notification. 5.1. Authorization code generation Authorization code cance request notification : From: [email protected] Subject: AFNIC - Notification d'abandon de la demande de generation de code pour ${domaine} To: noc Bonjour, L'AFNIC vous informe que la demande de generation de code pour le titulaire ${titulaire.prenom} ${titulaire.nom} pour le nom de domaine ${domaine} a été abandonné à votre demande. Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC Authorization code rejection notification : From: [email protected] Subject: AFNIC - Notification de rejet de la demande de generation de code pour ${domaine} To : noc Bonjour, L'AFNIC vous informe que la demande de generation de code d'autorisation pour le titulaire ${titulaire.prenom} ${titulaire.nom} pour le nom de domaine ${domaine} a été rejeté pour la raison suivante: ${commentaire} Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC Authorization code generation notification : From: [email protected] Subject: AFNIC - Notification de generation de code d'autorisation pour ${domaine} To : noc Bonjour, L'AFNIC vous informe que la demande de generation de code pour le titulaire ${titulaire.prenom} ${titulaire.nom} pour le nom de domaine ${domaine} a été acceptée. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 112 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 113 Votre code d'autorisation est : ${code} Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC 5.2. Trade validation Trade validation by fax cancelation: From : [email protected] Subject: AFNIC - Notification d'abandon de la demande de trade sur ${domaine} To : noc Bonjour, L'AFNIC vous informe que le ticket ${ticket.id} concernant le trade du domaine ${domaine} a été abandonné. Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC 5.3. Notification of Monitoring of the Qualification Procedure In parallel to the EPP notifications, email notifications are sent to the registrars not using EPP. Format of the email notifications for the launch of the qualification process: From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=start To: noc [Introductory text] HOLDER=ET1323-FRNIC STATUS=start [End text] Format of the email notifications for the end of the qualification process: From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=finished To: noc [Introductory text] HOLDER=ET1323-FRNIC STATUS= finished ELIG=valeur_de_l_identifiant ou KO Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 113 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 114 REACH=valeur_du_media_joignable (EMAIL/PHONE) [...] [End text] Format of the email notification for a switch to "problem" status: From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=problem To: noc [Introductory text] HOLDER=ET1323-FRNIC STATUS=problem [End text] 5.4. Notification of Suspension, Blocking and Deletion of Domain Name Portfolio As explained above, when a procedure starts with a request for supporting documents, the domain names associated with the portfolio are then suspended. If there is no positive outcome in the first month after the switch to suspended status, the domain names associated with the holder are blocked. If there is no positive outcome in the first month after the switch to blocked status, the domain names associated with the holder are deleted. If the portfolio is suspended / blocked / deleted, a notification email is sent to the registrar and to the holder of the domain names in question. Format of the email notifications concerning the suspension / blocking / deletion of a portfolio of domain names: From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC – Suspension/Blocking/Deletion of a portfolio of domain names To: noc [Introductory text] HOLDER=ET1323-FRNIC STATUS=problem DOMAIN=nomdedomaine1.fr DOMAIN=nomdedomaine2.fr [...] [End text] Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 114 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 115 5.5. Substantiation email Whether the registrar works with EPP or email, in the case of Substantiation procedure, an email is sent by [email protected] to request additional information in order to solve the problem. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 115 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 116 6. DAS (Domain Availability Service) The Domain Availability Service (DAS) is preferred to the EPP command <check>. This service leans upon a standard whose technical specifications can be found in: • • RFC5144 (A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)), for a description of the data structures implemented, RFC 4993 (A Lightweight UDP Transfer Protocol for the Internet Registry Information Service) for a description of the transport protocol 6.1. Parameters to interrogate the service • • in production, the server name and port number are not necessary with automatic discovery. Eg: dchk afnic.fr on the sandbox, it is necessary to indicate the test server: dchk.test.nic.fr and port number: 715 Eg: dchk-h-p 715 dchk.test.nic.fr nic.fr 6.2. The information available 6.2.1. Validity of the domain tested The first tests concern the validity of the domain name. A specific error code is returned when the name syntax is not correct, either by the presence of invalid characters or the fact of a specific rule to AFNIC (domain names with one letter for example). 6.2.2. domain name This is the primary function of this service. Once the answer is "nameNotFound", the registrar is absolutly certain that the domain name may be registered and will have no special restrictions on registration. Moreover, in the case of an existing domain name, states "redemptionPeriod" and "delete" respectively indicate that the domain name is in redemption period after a delete operation for the first and the domain name will be destroyed in the hour for the second (redemption period finished on standby of Garbage Collector). Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 116 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 117 6.2.3. State of DNS publication When a domain name exists in the registry, the service discriminates that the domain name is published or not in the DNS. If the status "active" is returned to a domain name, it means that it exists and is published in the DNS. The status "inactive" indicate that the field exists but is not published in DNS. Note however, DNS zones are updated once an hour, and during this time, a domain name in the status "active" may not yet have been published and not to be found following a request DNS. 6.2.4. Information on restrictions relating to this domain name Whether registered or not, a domain name may be subject to certain limitations in the registration. Some are irrevocable, others require authorization codes. In both cases, we were obliged to introduce "sub-status" specific to AFNIC in order to bring more precision. • Reserved domain names (state "reserved") for which a procedure with authorization code is required. • "city" specifies that the name is reserved for a town. • "special" / "sld" / "protectedLabel" for specific legal frameworks. • Another type of restriction (state "policyNonCompliant") • "forbidden" indicates that the name can never be registered. • "equivalentExists" indicates that a domain name with the same label already exists in the area. 6.2.5. Key dates on existing domain names Up to three dates can be answered for a domain name: • • • The creation date (createdDateTime) of domain name, the date of last modification (lastDatabaseUpdateDateTime) the expiration date of domain name (expirationDateTime) It is important to note that we use exactly the same format of date as for EPP server. The dates are with format UTC. 6.3. DAS and IDN Accounting for IDNs is an integral part of the existing DAS protocol used by AFNIC, namely IRIS:DCHK (RFC 5144); on the other hand, this protocol refers to the IDNA2003 standard. In the DAS protocol implemented by AFNIC (IDNA2008), the Nameprep step no longer exists. However, as discussed in the IDN paragraph, given the alphabet used, and in order to be consistent with our other interfaces and current uses at AFNIC, we also accept uppercase input. Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 117 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 118 It is possible to query an IDN in its ASCII or Unicode form; on the other hand, the 'entityClass' attribute of the <lookupEntity> element will not be the same. In the case of an ASCII form, indicate "domain-name"; in the case of a Unicode form, indicate "idn". This is not specific to AFNIC, so if your client code complies with the RFC, no change is to be expected. The answer, in the case of an IDN query, will contain an additional element, namely <idn> containing the Unicode version of the domain name. On the other hand, unlike the domain name entered, only the 67 characters listed above will be used as output (no capitals). The <domainName> element of the answer will always contain the ASCII form of the domain name. The values of the 'entityClass' and 'entityName' attributes in the answer will be identical to those in the query. 6.4. Examples 6.4.1. Domain name that does not exist and is not subject to any restrictions Resquest: > dchk nic007.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic007.fr"/> </iris1:searchSet> </iris1:request> Answer: nic007.fr: free <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer/> <iris:nameNotFound/> </iris:resultSet> </iris:response> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 118 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 119 6.4.2. Domain name subject to prior review Request: > dchk nazis.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nazis.fr"/> </iris1:searchSet> </iris1:request> Answer: nazis.fr: policyNoncompliant <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="nazis.fr"> <domainName>nazis.fr</domainName>lastDatabaseUpdateDateTime <status> <policyNoncompliant> <subStatus authority="fr">forbidden</subStatus> <description language="en">Legal issue</description> </policyNoncompliant> </status> </domain> </iris:answer> </iris:resultSet> </iris:response> 6.4.3. Fanciful domain name Request: > dchk nic_france.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic_france.fr"/> </iris1:searchSet> </iris1:request> Answer: nic_france.fr: invalid <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer/> <iris:invalidName/> </iris:resultSet> </iris:response> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 119 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 120 6.4.4. Domain name that exists and is not subject to any restrictions Request: > dchk nic.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic.fr"/> </iris1:searchSet> </iris1:request> Answer: nic.fr: active [2011-01-21T22:24:31.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="nic.fr"> <domainName>nic.fr</domainName> <status> <active/> </status> <createdDateTime>1994-12-31T23:00:00.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2011-0121T22:24:31.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response> 6.4.5. Deleted domain name in redemption period Request: > dchk ouais-okay-super.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="ouais-okay-super.fr"/> </iris1:searchSet> </iris1:request> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 120 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 121 Answer : ouais-okay-super.fr: redemptionPeriod [2011-04-04T09:21:04.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="ouais-okaysuper.fr"> <domainName>ouais-okay-super.fr</domainName> <status> <inactive/> <redemptionPeriod/> </status> <createdDateTime>2010-03-03T16:35:07.0Z</createdDateTime> <expirationDateTime>2011-05-04T09:21:04.0Z</expirationDateTime> <lastDatabaseUpdateDateTime>2011-0404T09:21:04.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> 6.4.6. Existing domain name and subject to prior review Request: > dchk paris.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="paris.fr"/> </iris1:searchSet> </iris1:request> Answer: paris.fr: reserved [2006-10-05T15:58:33.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="paris.fr"> <domainName>paris.fr</domainName> <status> <active/> <reserved> <subStatus authority="fr">city</subStatus> <description language="en">City name</description> </reserved> </status> <createdDateTime>2001-07-11T22:00:00.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2006-1005T15:58:33.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 121 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 122 6.4.7. Query on different domains with different Request: > dchk nic007.fr afnic.fr --nic--.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic007.fr"/> </iris1:searchSet> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="afnic.fr"/> </iris1:searchSet> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="--nic--.fr"/> </iris1:searchSet> </iris1:request> Answer: nic007.fr: free afnic.fr: active [2009-11-09T15:47:45.0Z] --nic--.fr: invalid] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer/> <iris:nameNotFound/> </iris:resultSet> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="afnic.fr"> <domainName>afnic.fr</domainName> <status> <active/> </status> <createdDateTime>2001-12-10T23:00:00.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2009-1109T15:47:45.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> <iris:resultSet> <iris:answer/> <iris:invalidName/> </iris:resultSet> </iris:response> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 122 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 123 6.4.8. IDN query in its Unicode form Request: > dchk àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="idn" entityName="àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr"/> </iris1:searchSet> </iris1:request> Answer: àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr: 20T13:16:24.0Z] active [2012-01- <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="idn" entityName=" àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr"> <domainName> xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr </domainName> <idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn> <status> <active/> </status> <createdDateTime>2012-01-20T13:16:24.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2012-0120T13:16:24.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response> 6.4.9. IDN query in its ACE form Request: > dchk xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName=" xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr"/> </iris1:searchSet> </iris1:request> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 123 - Technical Integration Guide November 2009 TECHNICAL INTEGRATION GUIDE – February 25th, 2013 124 Answer : xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr: active [201201-20T13:16:24.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName=" xn-zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr"> <domainName> xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr </domainName> <idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn> <status> <inactive/> </status> <createdDateTime>2012-01-20T13:16:24.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2012-0120T13:16:24.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response> Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr - 124 - Technical Integration Guide November 2009