Technical Integration Guide

Transcription

TECHNICAL INTEGRATION GUIDE – February 27th, 2015
1
Technical
Integration Guide
- Version 3.0 February 27th, 2015
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]
Twitter : @AFNIC | Facebook : afnic.fr
-1-
November 2009
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 ................................................................................................... 33
Restore – Domain name restore .................................................................................................. 34
Transfer – Registrar change ........................................................................................................ 35
Trade – Holder change (Transmission) ....................................................................................... 45
Recover – Forced domain name transmission ............................................................................. 52
Checking a domain availability ................................................................................................... 55
-2-
November 2009
3
3.4.9. Retrieve domain data ................................................................................................................... 58
3.5. Managing a contact ..................................................................................... 64
3.5.1.
3.5.2.
3.5.3.
3.5.4.
3.5.5.
Contact Creation .......................................................................................................................... 64
Modifying a contact .................................................................................................................... 71
Deleting a contact ........................................................................................................................ 72
Identification of a contact holder ................................................................................................. 72
Retrieve data of a contact ............................................................................................................ 73
3.6. Notifications ................................................................................................. 75
3.6.1. Managing the notification queue ................................................................................................. 75
3.6.2. Asynchronous notifications ......................................................................................................... 76
3.6.3. Exogenous notifications .............................................................................................................. 81
3.7. Return codes and error messsages ........................................................... 98
3.7.1. Return codes ................................................................................................................................ 98
3.7.2. Error messages .......................................................................................................................... 101
3.8. RFCs ........................................................................................................... 102
4. Web interface : the ticket system ..................................................103
4.1. General principles on tickets .................................................................... 103
4.2. Ticket format .............................................................................................. 103
4.3. Description of all the tickets ..................................................................... 103
5. Operations that can only be handled by email/fax .......................113
5.1. Authorization code generation ................................................................. 113
5.2. Trade validation ......................................................................................... 114
5.3. Notification of Monitoring of the Qualification Procedure ..................... 114
5.4. Notification of Suspension, Blocking and Deletion of Domain Name
Portfolio ......................................................................................................... 115
5.5. Substantiation email .................................................................................. 116
6. DAS (Domain Availability Service) ................................................117
6.1. Parameters to interrogate the service...................................................... 117
6.2. The information available.......................................................................... 117
6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.2.5.
Validity of the domain tested .................................................................................................... 117
domain name ............................................................................................................................. 117
State of DNS publication .......................................................................................................... 118
Information on restrictions relating to this domain name .......................................................... 118
Key dates on existing domain names ........................................................................................ 118
-3-
November 2009
4
6.3. DAS and IDN ............................................................................................... 118
6.4. Examples .................................................................................................... 119
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 .................................... 119
Domain name subject to prior review ....................................................................................... 120
Fanciful domain name ............................................................................................................... 120
Domain name that exists and is not subject to any restrictions ................................................. 121
Deleted domain name in redemption period.............................................................................. 121
Existing domain name and subject to prior review ................................................................... 122
Query on different domains with different ................................................................................ 123
IDN query in its Unicode form .................................................................................................. 124
IDN query in its ACE form ....................................................................................................... 124
-4-
November 2009
5
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
-5-
November 2009
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
27/02/2015 – V3.0 – Update of domain:create, addition of domain:renew, update of domain:info
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).
-6-
November 2009
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
-7-
November 2009


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
-8-
November 2009
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
-9-
November 2009
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 : 3
•
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
- 10 -
November 2009
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:
- 11 -
November 2009
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.
- 12 -
November 2009
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>
- 13 -
November 2009
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
to the document Technical policies of the Registry
underway) to end
« 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
- 14 -
November 2009
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: <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.
- 15 -
November 2009
•
•
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: <command>
C:
<logout/>
C:
C: </command>
C:</epp>
- 16 -
November 2009
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>
- 17 -
November 2009
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).
- 18 -
November 2009
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 the usual way to create a domain name 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".
- 19 -
November 2009
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
Number of occurrences
<domain:name>
1
 <domain:period>
<
0-1
d
<domain:registrant>
1
o
<domain:contact type="admin">
1
m
<domain:contact type="tech">
1-3
a
<domain:ns>
0-1
i
<domain:authInfo>
1
n
<domain:pw>
1

<clTRID>
0-1

<domain:name> contains the complete domain name (example-dnepp.fr).

<domain:period> contain the registration duration whose value must
be equal to 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10 years. You must provide the
unit attribute and specify the unit type used.
Examples :

<domain:period unit="y">1</domain:period>

<domain:period unit="m">12</domain:period>
If the domain:period is not provided, the default registration duration
is one year.

<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.
- 20 -
November 2009
21
Example of a request sent by the client:
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:
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:
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>), in case of
1001, these dates are just indicative and incorrect. A poll message will
notify you that the domain name is effectively created and the corret dates
will be provided.
Example of answer sent by the server:
S: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:creData
S:
S:
S:
S:
S:
</domain:creData>
S:
</resData>
S:
<trID>
S:
S:
<svTRID>frnic-00000001</svTRID>
S:
</trID>
S: </response>
S:</epp>
- 21 -
November 2009
22
Example of answer sent by the server (1001 return code):
S: <response>
S:
S:
<msg>Command completed successfully; action pending</msg>
S:
</result>
S:
<resData>
S:
<domain:creData
S:
S:
<domain:name>dom-epp-wytxubuz.fr</domain:name>
S:
S:
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).
- 22 -
November 2009
23
Example of a request sent by the client:
C: <command>
C:
<create>
C:
<domain:create
C:
C:
<domain:name>ndd-reserve-0001.fr</domain:name>
C:
<domain:period unit="m">12</domain:period>
C:
C:
C:
C:
C:
<domain:authInfo>
C:
<domain:pw>NDCR20080229T173000.123456789</domain:pw>
C:
</domain:authInfo>
C:
</domain:create>
C:
</create>
C:
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.
- 23 -
November 2009
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. Renew – Renouveler un nom de domaine
The renewal of a domain name allows to add one or several additional years of
registration. These years will be added to the current expiry date but this one
cannot exceed 10 years of registration between the date of day and the new
expiry date.
The command requires to supply besides the domain name and the number of
additional years of registration, the current expiry date.
Example of a renew command :
C: <command>
C:
<renew>
C:
<domain:renew
C:
C:
<domain:name>renouvellement.fr</domain:name>
C:
<domain:curExpDate>2015-07-03</domain:curExpDate>
C:
C:
</domain:renew>
C:
</renew>
C:
<clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Answer by the server to the previous command :
- 24 -
November 2009
25
S: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:renData
S:
S:
<domain:name>renouvellement.fr</domain:name>
S:
S:
</domain:renData>
S:
</resData>
S:
<trID>
S:
<clTRID>ABC-12345</clTRID>
S:
<svTRID>54322-XYZ</svTRID>
S:
</trID>
S: </response>
S:</epp>
3.4.3. 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.3.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
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
- 25 -
November 2009
26
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: <command>
C:
<update>
C:
<domain:update
C:
C:
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:
C:
</domain:rem>
C:
</domain:update>
C:
</update>
C:
C: </command>
C:</epp>
- 26 -
November 2009
27
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: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
Example of answer in case of code return 1001:
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">S: <response>
S:
S:
S:
</result>
S:
<msgQ count="1" id="63480"/>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
3.4.3.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).
- 27 -
November 2009
28
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
- 28 -
November 2009
29
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>
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.
- 29 -
November 2009
30
Example of a request sent by the client after a creation to indicate the initial
configuration for a domain name:
C: <command>
C:
<update>
C:
<domain:update
C:
C:
C:
<domain:add>
C:
<domain:ns>
C:
<domain:hostAttr>
C:
<domain:hostName>ns1.nic.fr</domain:hostName>
C:
</domain:hostAttr>
C:
<domain:hostAttr>
C:
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:
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: <command>
C:
<update>
C:
<domain:update
C:
C:
C:
<domain:add>
C:
<domain:ns>
C:
<domain:hostAttr>
C:
C:
</domain:hostAttr>
C:
<domain:hostAttr>
C:
C:
</domain:hostAttr>
C:
<domain:hostAttr>
C:
C:
C:
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:
C: </command>
C:</epp>
- 30 -
November 2009
31
3.4.3.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">

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: <command>
- 31 -
November 2009
32
C:
<update>
C:
<domain:update
C:
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:
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: <response>
S:
S:
S:
</result>
S:
<msgQ count="1" id="50001"/>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
Example of answer in case of code return 1001 (degraded server):
S: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 32 -
November 2009
33
3.4.4. 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: <command>
C:
<delete>
C:
<domain:delete
C:
C:
C:
</domain:delete>
C:
</delete>
C:
C: </command>
C:</epp>
Example of an answer sent by the server (for this type of command, the return
code is alway 1001):
S: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 33 -
November 2009
34
3.4.5. 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">
1
Example of the restoration request for our test domain name:
C: <command>
C:
<update>
C:
<domain:update
C:
C:
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:
C: </command>
C:</epp>
- 34 -
November 2009
35
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: <response>
S:
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
Example of answer in case of code return 1001 (degraded server)
S: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
3.4.6. 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.
- 35 -
November 2009
36
3.4.6.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">
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.
- 36 -
November 2009
37
Example of the transfer request sent by a registrar on our domain name test0001.fr with keeping the DS records:
C: <command>
C:
<transfer op="request">
C:
<domain:transfer
C:
C:
C:
C:
<domain:authInfo>
C:
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:
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:
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 >




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.
- 37 -
November 2009


38
<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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:trnData
S:
S:
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:
S:
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.6.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.
- 38 -
November 2009
39
Example of a request to retrieve the awaiting message:
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: <response>
S:
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:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
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.
- 39 -
November 2009
40
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: <command>
C:
<transfer op="approve">
C:
<domain:transfer
C:
C:
C:
<domain:authInfo>
C:
C:
</domain:authInfo>
C:
</domain:transfer>
C:
</transfer>
C:
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
<domain:trStatus>clientApproved</domain:trStatus>
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 40 -
November 2009
41
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: <command>
C:
<transfer op="reject">
C:
<domain:transfer
C:
C:
C:
<domain:authInfo>
C:
C:
</domain:authInfo>
C:
</domain:transfer>
C:
</transfer>
C:
C: </command>
C:</epp>
Example of a server answer in the case of a refusal:
S: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
<domain:trStatus>clientRejected</domain:trStatus>
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
<svTRID>frnic-000000009-bis</svTRID>
S:
</trID>
S: </response>
S:</epp>
- 41 -
November 2009
42
3.4.6.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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
<msg>Transfer approved.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 42 -
November 2009
43
The second message in the queue is the initial command result to which the
server had answered with a 1001 return code.
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:01:00.0Z</qDate>
S:
<msg>Transfer completed.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
<domain:name paResult="1">ndd-de-test-0001.fr</domain:name>
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
<domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate>
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
<msg>Transfer rejected.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 43 -
November 2009
44
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.6.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.
- 44 -
November 2009
45
3.4.7. 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.7.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:name>
<frnic:registrant>
<frnic:contact type="admin">
<frnic:contact type="tech">
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
- 45 -
November 2009
46
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: <extension>
C:
<frnic:ext
C:
C:
<frnic:command>
C:
<frnic:trade op="request">
C:
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:
C:
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 :
- 46 -
November 2009
Element name
<frnic:name>
<frnic:trStatus>
<frnic:reID>
<frnic:reDate>
<frnic:reHldID>
<frnic:rhDate>
<frnic:acID>
<frnic:acHldID>
<frnic:ahDate>









47
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.
- 47 -
November 2009
48
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: <response>
S:
S:
S:
</result>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
3.4.7.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.
- 48 -
November 2009
49
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-12-25T00:02:00.0Z</qDate>
S:
<msg>Trade requested.</msg>
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
S:
<frnic:reID>BEdemandeurID</frnic:reID>
S:
S:
S:
<frnic:acID>BEactuelID</frnic:acID>
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
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>.
- 49 -
November 2009
50
Here is the message received by the outgoing registrar:
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-02T00:00:01.0Z</qDate>
S:
<msg>Trade in progress.</msg>
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>oldHolderApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
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".
- 50 -
November 2009
51
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>holdersApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
<msg>Trade completed.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 51 -
November 2009
52
3.4.7.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.8. 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.8.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.
- 52 -
November 2009
53
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: <extension>
C:
<frnic:ext
C:
xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"
C:
C:
<frnic:command>
C:
<frnic:recover op="request">
C:
C:
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:
C:
C:
</frnic:domain>
C:
</frnic:recover>
C:
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>
1
1
1
0-1
1
0-1
- 53 -
November 2009






54
<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.
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: <response>
S:
S:
S:
</result>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:recData>
S:
<frnic:domain>
S:
S:
<frnic:reID>BEentrantID</frnic:reID>
S:
S:
<frnic:reHldID>PR1249</frnic:reHldID>
S:
<frnic:acID>BEsortantID</frnic:acID>
S:
S:
</frnic:domain>
S:
</frnic:recData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 54 -
November 2009
55
3.4.9. 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
- 55 -
November 2009
56
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: <command>
C:
<check>
C:
<domain:check
C:
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:
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>



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
- 56 -
November 2009
57
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:chkData
S:
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:
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:
S:
af-1234-nic.fr
S:
</frnic:name>
S:
</frnic:cd>
S:
<frnic:cd>
S:
S:
bois-guillaume.fr
S:
</frnic:name>
S:
<frnic:rsvReason>City name</frnic:rsvReason>
- 57 -
November 2009
58
S:
</frnic:cd>
S:
<frnic:cd>
S:
S:
paris.fr
S:
</frnic:name>
S:
<frnic:rsvReason>City name</frnic:rsvReason>
S:
</frnic:cd>
S:
<frnic:cd>
S:
S:
trafiquants.fr
S:
</frnic:name>
S:
<frnic:fbdReason>Legal issue</frnic:fbdReason>
S:
</frnic:cd>
S:
<frnic:cd>
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
3.4.10.
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
- 58 -
November 2009
59
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: <command>
C:
<info>
C:
<domain:info
C:
C:
<domain:name hosts="all">ndd-de-test-0001.fr</domain:name>
C:
</domain:info>
C:
</info>
C:
C: </command>
C:</epp>
Request sent made by the registrar not in charge of the domain name:
C: <command>
C:
<info>
C:
<domain:info
C:
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:
C: </command>
C:</epp>
3.4.10.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
- 59 -
November 2009
60
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
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".
- 60 -
November 2009





61
<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 expiration date of the domain name.
<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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:infData
S:
S:
S:
S:
<domain:status s="ok"/>
S:
S:
S:
S:
S:
<domain:ns>
S:
<domain:hostAttr>
S:
S:
</domain:hostAttr>
S:
<domain:hostAttr>
S:
S:
</domain:hostAttr>
S:
<domain:hostAttr>
S:
S:
S:
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:
S:
S:
<domain:update>2009-01-10T00:00:00.0Z</domain:update>
S:
<domain:authInfo>
S:
S:
</domain:authInfo>
S:
</domain:infData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
C:</epp>
3.4.10.2. Details of the possible extensions of the answer
- 61 -
November 2009
62
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:
<resData>
S:
<domain:infData
S:
S:
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:
S:
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:
<resData>
S:
<domain:infData
S:
S:
S:
<domain:status s="serverTransferProhibited"/>
[…]
S:
</resData>
S:
<extension>
S:
<frnic:ext
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
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.
- 62 -
November 2009
63
[…]
S:
<resData>
S:
<domain:infData
S:
S:
S:
[…]
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:
S:
S:
</trID>
S: </response>
S:</epp>
- 63 -
November 2009
64
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,
- 64 -
November 2009
65
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>




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.
- 65 -
November 2009
66
Example of a contact creation containing information in order to be used as an
individual domain holder:
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:
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:
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.
- 66 -
November 2009
Element name
<frnic:idStatus>
<frnic:nhStatus new="">


67
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">).
- 67 -
November 2009
68
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<contact:creData
S:
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:
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:
S:
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>
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
- 68 -
November 2009







69
<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: <command>
C:
<create>
C:
<contact:create
C:
C:
C:
C:
<contact:name>AFNIC</contact:name>
C:
<contact:addr>
C:
C:
C:
C:
C:
C:
C:
</contact:addr>
C:
C:
C:
C:
C:
<contact:authInfo>
C:
C:
</contact:authInfo>
C:
</contact:create>
C:
</create>
C:
<extension>
C:
<frnic:ext
C:
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:
C: </command>
C:</epp>
- 69 -
November 2009
70
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>
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:
C:
C:
<contact:name>Levigneron</contact:name>
C:
<contact:org>AFNIC</contact:org>
C:
<contact:addr>
C:
C:
C:
C:
C:
C:
C:
</contact:addr>
C:
C:
C:
C:
<contact:email>vincent.levigneron\@nic.fr</contact:email>
C:
<contact:authInfo>
C:
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:
C:
<frnic:idStatus>ok</frnic:idStatus>
C:
C:
C:
C:
<frnic:reachable media="email">1</frnic:reachable>
C:
</frnic:contact>
C:
</frnic:create>
C:
</frnic:ext>
C:
</extension>
C:
C: </command>
C:</epp>
- 70 -
November 2009
71
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: <command>
C:
<update>
C:
<contact:update
C:
C:
C:
</contact:update>
C:
</update>
C:
<extension>
C:
<frnic:ext
C:
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:
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.
- 71 -
November 2009
72
C:<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
C: <command>
C:
<update>
C:
<contact:update
C:
C:
C:
</contact:update>
C:
</update>
C:
<extension>
C:
<frnic:ext
C:
C:
<frnic:update>
C:
<frnic:contact>
C:
<frnic:add>
C:
C:
<frnic:reachable media="email">1</frnic:reachable>
C:
</frnic:add>
C:
</frnic:contact>
C:
</frnic:update>
C:
</frnic:ext>
C:
</extension>
C:
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.
- 72 -
November 2009
73
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: <command>
C:
<info>
C:
<contact:info
C:
C:
<contact:id>MO666</contact:id>
C:
</contact:info>
C:
</info>
C:
C: </command>
C:</epp>
- 73 -
November 2009
74
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>
<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:name>Mobibus Outlaws</contact:name>
<contact:addr>
<contact:street>7, avenue monchignon</contact:street>
<contact:city>la Baule Escoublac</contact:city>
</contact:addr>
<contact:clID>-wuhgejav499-.fr</contact:clID>
<contact:crID>-wuhgejav499-.fr</contact:crID>
<contact:upDate>2011-07-08T16:41:17.0Z</contact:upDate>
</contact:infData>
</resData>
<extension>
<frnic:resData>
<frnic:infData>
<frnic:contact>
<frnic:idStatus when="2011-06-21T05:30:36"
source="registry">ok</frnic:idStatus>
<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.
- 74 -
November 2009
75
3.6. Notifications
3.6.1. Managing the notification queue
Example of a request to retrieve an awaiting message:
C: <command>
C:
<poll op="req"/>
C:
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: <command>
C:
<poll op="ack" msgID="50001"/>
C:
C: </command>
C:</epp>
Example of the answer sent by the server (we consider this is the only
awaiting message):
S: <response>
S:
S:
S:
</result>
S:
<msgQ count="0" id="50001"/>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 75 -
November 2009
76
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
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 76 -
November 2009
•
77
Transfer finished (incoming registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:01:00.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
transfer rejected (incoming registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
<msg>Transfer rejected.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 77 -
November 2009
•
78
trade finished (incoming registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
delete finished
S: <response>
S:
S:
S:
</result>
S:
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:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
<svTRID>TEST-kenobi-6435-29-1254926575.803</svTRID>
S:
</trID>
S: </response>
S:</epp>
- 78 -
November 2009
•
79
restore finished
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
<msg>Deletion aborted. Domain successfully restored.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
<clTRID>FooBar</clTRID>
S:
S:
</trID>
S: </response>
S:</epp>
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-06-04T09:11:27.0Z</qDate>
S:
<msg>Pending update (restore) completed successfully.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 79 -
November 2009
•
80
create finished
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-06-03T15:23:23.0Z</qDate>
S:
<msg>Pending creation completed successfully.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name paResult="1">dom-epp-wytxubuz.fr</domain:name>
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
update [admin] finished
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-06-04T10:30:28.0Z</qDate>
S:
<msg>Pending update (contacts) completed successfully.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name paResult="1">dom-epp-hyclebod.fr</domain:name>
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 80 -
November 2009
•
81
update [context] finished
S: <response>
S:
S:
S:
</result>
S:
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:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
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 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
- 81 -
November 2009
•
82
Transfer requested (outgoing registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-25T00:02:00.0Z</qDate>
S:
<msg>Transfer requested.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-10-06T16:27:19.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 82 -
November 2009
•
83
Transfer finished (outgoing registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-10-06T16:27:20.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:
S:
S:
<domain:reID>TEST_2</domain:reID>
S:
S:
<domain:acID>TEST</domain:acID>
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Transfer canceled (outgoing registrar)
S: <response>
S:
S:
S:
</result>
S:
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:
S:
<domain:trStatus>clientCancelled</domain:trStatus>
S:
<domain:reID>-huqlycuw772-.fr</domain:reID>
S:
S:
<domain:acID>-huqlycuw772-.fr</domain:acID>
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 83 -
November 2009
•
84
Transfer canceled (incoming registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-10-07T14:18:33.0Z</qDate>
S:
<msg>Transfer aborted.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Trade initiated (outgoing registrar)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-12-25T00:02:00.0Z</qDate>
S:
<msg>Trade requested.</msg>
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 84 -
November 2009
•
85
Trade outgoing holder agreement
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-02T00:00:01.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>oldHolderApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 85 -
November 2009
•
86
Trade incoming holder agreement
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-05-28T16:06:25.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
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:
S:
<frnic:reHldID>IP649</frnic:reHldID>
S:
S:
<frnic:acID>TEST</frnic:acID>
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 86 -
November 2009
•
87
Trade outgoing and incoming holder agreement
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>holdersApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Trade finished (outgoing registrar)
S: <response>
S:
S:
S:
</result>
S:
<msgQ count="1" id="423754">
S:
<qDate>2009-08-28T14:49:55.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
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:
S:
<frnic:acID>-vycfazur780-.fr</frnic:acID>
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 87 -
November 2009
•
88
Trade canceled (outgoing registrar)
S: <response>
S:
S:
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:
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:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
Recover finished (outgoing registrar)
S: <response>
S:
S:
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:
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:
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:
S:
S:
</trID>
S: </response>
S:</epp>
- 88 -
November 2009
•
89
Start of qualification procedure
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
<frnic:id>ZNE51</frnic:id>
S:
<frnic:qualificationProcess s="start"/>
S:
S:
<frnic:idStatus>pending</frnic:idStatus>
S:
<frnic:legalStatus s="association"/>
S:
S:
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:
S:
</trID>
S: </response>
S:</epp>
- 89 -
November 2009
•
90
End of qualification procedure
If reachability and/or eligibility checks succeed
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
S:
<frnic:qualificationProcess s="finished"/>
S:
S:
S:
S:
S:
S:
S:
<frnic:reStatus>ok</frnic:reStatus>
S:
S:
S:
</frnic:contact>
S:
</frnic:quaData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 90 -
November 2009
91
If reachability and/or eligibility checks fail
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
S:
<frnic:qualificationProcess s="finished"/>
S:
S:
<frnic:idStatus>ko</frnic:idStatus>
S:
S:
S:
S:
S:
S:
S:
S:
</frnic:contact>
S:
</frnic:quaData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 91 -
November 2009
•
92
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: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
S:
<frnic:qualificationProcess s="problem"/>
S:
S:
<frnic:idStatus>ko</frnic:idStatus>
S:
S:
S:
S:
S:
S:
S:
S:
</frnic:contact>
S:
</frnic:quaData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
- 92 -
November 2009
•
93
Suspension of a domain name
CAUTION: this notification is sent as many times as there are
suspended domain names.
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-05-05T07:52:50.0Z</qDate>
S:
<msg>Holder qualification status prevents some operations.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name>nic.fr</domain:name>
S:
S:
S:
<domain:registrant>XXX1234</domain:registrant>
S:
<domain:clID>-rocfisor895-.fr</domain:clID>
S:
</domain:infData>
S:
</resData>
S:
<extension>
S:
S:
<frnic:resData>
S:
<frnic:infData>
S:
<frnic:domain>
S:
S:
</frnic:domain>
S:
</frnic:infData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 93 -
November 2009
•
94
Blocking of a domain name
CAUTION: this notification is sent as many times as there are
blocked domain names.
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-05-05T07:52:50.0Z</qDate>
S:
<msg>Holder qualification status prevents some operations.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name>nic.fr</domain:name>
S:
S:
<domain:status s="serverHold"/>
S:
<domain:status s="serverDeleteProhibited"/>
S:
<domain:status s="serverUpdateProhibited"/>
S:
S:
<domain:registrant>XXX1234</domain:registrant>
S:
<domain:clID>-rocfisor895-.fr</domain:clID>
S:
</domain:infData>
S:
</resData>
S:
<extension>
S:
S:
<frnic:resData>
S:
<frnic:infData>
S:
<frnic:domain>
S:
S:
</frnic:domain>
S:
</frnic:infData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
- 94 -
November 2009
•
95
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: <response>
S:
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:
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>
- 95 -
November 2009
•
96
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-05-05T07:52:50.0Z</qDate>
S:
<msg>Domain deletion after failure in qualification
process.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name>nomdomaine1.fr</domain:name>
S:
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:
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:
S:
S:
</trID>
S: </response>
S:</epp>
- 96 -
November 2009
•
97
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: <response>
S:
S:
S:
</result>
S:
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:
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:
S:
S:
</contact:addr>
S:
S:
S:
S:
<contact:clID>-huqlycuw772-.fr</contact:clID>
S:
<contact:crID>-huqlycuw772-.fr</contact:crID>
S:
S:
<contact:upDate>2009-10-21T09:40:34.0Z</contact:upDate>
S:
</contact:infData>
S:
</resData>
S:
<extension>
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
- 97 -
November 2009
98
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: <response>
S:
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:
S:
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.
- 98 -
November 2009
99
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 correct 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.
- 99 -
November 2009
•
•
•
•
•
•
•
•
•
•
•
•
•
•
100
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.
- 100 -
November 2009
101
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 »
- 101 -
November 2009
•
•
•
•
•
•
•
•
•
•
102
« 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:
- 102 -
November 2009








103
RFC 3375 - protocole registry-registrar :
http://www.ietf.org/rfc/rfc3375.txt
RFC 5730 – Extensible Provisioning Protocol (EPP) :
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 :
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]
- 103 -
November 2009
104
DOMAINE=nom-de-domaine-concerne.fr
OPERATION=Suppression
ETAT=Fini
TICKET=NIC00001234567/751825
FORMULAIRE=4869407
REFERENCE=
NUMEROSEQUENCE=2
[Texte conclusif]
- 104 -
November 2009
T
105
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]
- 105 -
November 2009
106
T - Canceled
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]
- 106 -
November 2009
P
107
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.
[...]
To: titulaire entrant
Madame, Monsieur,
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.
[...]
- 107 -
November 2009
108
To: titulaire sortant
Madame, Monsieur,
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
Subject: FR-NIC, nom-de-domaine-concerne.fr: Attente Mail
[NIC000012345678]
To: noc
[Texte introductif]
OPERATION=Transmission
ETAT=Attente Mail
TICKET=NIC000012345678/123456
FORMULAIRE=1234567
REFERENCE=REFCLIENT
NUMEROSEQUENCE=1
La transmission demandée est en 'Attente Mail'.
- 108 -
November 2009
109
P – Canceled
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 >)
ETAT=Abandonne
TICKET=NIC000012345678/123456
FORMULAIRE=1234567
REFERENCE=REFCLIENT
NUMEROSEQUENCE=2
Opération abandonnée.
Expiration Delai 15 jours
P - Finished
[NIC000012345678]
To: noc
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]
- 109 -
November 2009
P
110
Operation P : Forced transmission
Existing status : Attente Vérification (awaiting
verification), Fini (finished)
P – Awaiting verification
From:
Subject:
To: noc
(in progress)
P - Finished
[NIC000012345678]
To: noc
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]
- 110 -
November 2009
D
111
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
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
Subject: FR-NIC, nom-de-domaine-concerne: Attente Opposition
Madame, Monsieur,
Nous vous envoyons ce message pour vous signaler que nous avons reçu
une demande de changement de prestataire sur le domaine :
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 :
- 111 -
November 2009
112
[------------------------------------------------------------------]
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
[NIC00001234567]
To: noc bureau d’enregistrement entrant
[Texte introductif]
OPERATION=Changement P
ETAT=Fini
TICKET=NIC00001234567/484934
FORMULAIRE=4869185
REFERENCE=
NUMEROSEQUENCE=3
Subject: FR-NIC, nom-de-domaine-concerne.fr: Delegation
Resiliee
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.
- 112 -
November 2009
113
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 :
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 :
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}
Cordialement,
AFNIC
Authorization code generation notification :
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.
- 113 -
November 2009
114
Votre code d'autorisation est :
${code}
Cordialement,
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é.
Cordialement,
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:
Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=finished
To: noc
[Introductory text]
HOLDER=ET1323-FRNIC
STATUS= finished
ELIG=valeur_de_l_identifiant ou KO
- 114 -
November 2009
115
REACH=valeur_du_media_joignable (EMAIL/PHONE)
[...]
[End text]
Format of the email notification for a switch to "problem" status:
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:
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]
- 115 -
November 2009
116
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.
- 116 -
November 2009
117
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).
- 117 -
November 2009
118
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.
- 118 -
November 2009
119
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
<iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
<iris:resultSet>
<iris:answer/>
<iris:nameNotFound/>
</iris:resultSet>
</iris:response>
- 119 -
November 2009
120
6.4.2. Domain name subject to prior review
Request:
> dchk nazis.fr
<iris1:searchSet>
entityName="nazis.fr"/>
</iris1:searchSet>
</iris1:request>
Answer:
nazis.fr: policyNoncompliant
<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
<iris1:searchSet>
entityName="nic_france.fr"/>
</iris1:searchSet>
</iris1:request>
Answer:
nic_france.fr: invalid
<iris:resultSet>
<iris:answer/>
<iris:invalidName/>
</iris:resultSet>
</iris:response>
- 120 -
November 2009
121
6.4.4. Domain name that exists and is not subject to any restrictions
Request:
> dchk nic.fr
<iris1:searchSet>
entityName="nic.fr"/>
</iris1:searchSet>
</iris1:request>
Answer:
nic.fr: active [2011-01-21T22:24:31.0Z]
<iris:resultSet>
<iris:answer>
<domain
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
<iris1:searchSet>
entityName="ouais-okay-super.fr"/>
</iris1:searchSet>
</iris1:request>
- 121 -
November 2009
122
Answer :
ouais-okay-super.fr: redemptionPeriod [2011-04-04T09:21:04.0Z]
<iris:resultSet>
<iris:answer>
<domain
authority="fr"
registryType="dchk1" entityClass="domain-name" entityName="ouais-okaysuper.fr">
<domainName>ouais-okay-super.fr</domainName>
<status>
<inactive/>
<redemptionPeriod/>
</status>
<expirationDateTime>2011-05-04T09:21:04.0Z</expirationDateTime>
</domain>
</iris:answer>
</iris:resultSet>
6.4.6. Existing domain name and subject to prior review
Request:
> dchk paris.fr
<iris1:searchSet>
entityName="paris.fr"/>
</iris1:searchSet>
</iris1:request>
Answer:
paris.fr: reserved [2006-10-05T15:58:33.0Z]
<iris:resultSet>
<iris:answer>
<domain
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>
</domain>
</iris:answer>
</iris:resultSet>
</iris:response>
- 122 -
November 2009
123
6.4.7. Query on different domains with different
Request:
> dchk nic007.fr afnic.fr --nic--.fr
<iris1:searchSet>
entityName="nic007.fr"/>
</iris1:searchSet>
<iris1:searchSet>
entityName="afnic.fr"/>
</iris1:searchSet>
<iris1:searchSet>
entityName="--nic--.fr"/>
</iris1:searchSet>
</iris1:request>
Answer:
nic007.fr: free
afnic.fr: active [2009-11-09T15:47:45.0Z]
--nic--.fr: invalid]
<iris:resultSet>
<iris:answer/>
<iris:nameNotFound/>
</iris:resultSet>
<iris:resultSet>
<iris:answer>
<domain
authority="fr"
registryType="dchk1" entityClass="domain-name" entityName="afnic.fr">
<domainName>afnic.fr</domainName>
<status>
<active/>
</status>
</domain>
</iris:answer>
</iris:resultSet>
<iris:resultSet>
<iris:answer/>
<iris:invalidName/>
</iris:resultSet>
</iris:response>
- 123 -
November 2009
124
6.4.8. IDN query in its Unicode form
Request:
> dchk àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr
<iris1:searchSet>
<iris1:lookupEntity
registryType="dchk1"
entityClass="idn"
entityName="àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr"/>
</iris1:searchSet>
</iris1:request>
Answer:
àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr:
20T13:16:24.0Z]
active
[2012-01-
<iris:resultSet>
<iris:answer>
<domain
authority="fr"
entityClass="idn"
entityName="
àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr">
<domainName>
xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr
</domainName>
<idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn>
<status>
<active/>
</status>
</domain>
</iris:answer>
</iris:resultSet>
</iris:response>
6.4.9. IDN query in its ACE form
Request:
> dchk xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr
<iris1:searchSet>
entityName=" xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr"/>
</iris1:searchSet>
</iris1:request>
- 124 -
November 2009
125
Answer :
xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr: active [201201-20T13:16:24.0Z]
<iris:resultSet>
<iris:answer>
<domain
authority="fr"
entityClass="domain-name"
entityName="
xn-zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr">
<domainName>
xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr
</domainName>
<idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn>
<status>
<inactive/>
</status>
</domain>
</iris:answer>
</iris:resultSet>
</iris:response>
- 125 -
November 2009

Technical Integration Guide

Transcription

Documents pareils

Identification Form

Identification form

Registration rules for .fr domain names with 1 and 2 characters

Open policy for IDN registration

Measuring Internet resilience

New gTLD - Registry Solution

Press kit - AFNIC creates two new types of domain

XML databases

practical memo - Cabane du perche