Groupe de travail Réseau	S. Hollenbeck, VeriSign, Inc.	
Request for Comments : 4114	juin 2005	
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Transposition des numéros E.164 
pour le protocole de provisionnement extensible (EPP)

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2005).

Résumé
Le présent document décrit une extension au protocole de provisionnement extensible (EPP, Extensible Provisioning Protocol) de transposition pour le provisionnement et la gestion des numéros E.164 qui représentent les noms de domaines mémorisés dans un répertoire central partagé. Spécifiée en XML, cette transposition étend la transposition de nom de domaine EPP pour fournir les caractéristiques supplémentaires requises pour le provisionnement des numéros E.164.
Table des Matières
1. Introduction	1
1.1 Conventions utilisées dans le présent document	2
2. Attributs d'objet	2
2.1 Noms de domaine E.164	2
2.2 Champs NAPTR	2
3. Transposition de commande EPP	3
3.1 Commandes d'interrogation EPP	3
3.2 Commandes EPP de transformation	5
4. Syntaxe formelle	7
7. Considérations d'internationalisation	9
6. Considérations relatives à l'IANA	9
9. Considérations sur la sécurité	9
8. Remerciements	9
9. Références	10
9.1 Références normatives	10
9.2 Références pour information	10
Adresse de l'auteur	10
Déclaration complète de droits de reproduction	10

1.	Introduction

Le présent document décrit une transposition de numéro E.164 pour la version 1.0 du protocole de provisionnement extensible (EPP, Extensible Provisioning Protocol). Cette transposition, une extension de la transposition de nom de domaine décrite dans la [RFC3731], est spécifiée en utilisant le langage de balisage extensible (XML, Extensible Markup Language) 1.0, comme décrit dans [XML], et la notation de schéma XML, décrite dans [XML-STR] et [XML-DATA].

La spécification du cœur du protocole EPP [RFC3730] donne une description complète des structures de commande et réponse EPP. Une bonne compréhension de la spécification du protocole de base est nécessaire pour comprendre la transposition décrite dans le présent document.

ENUM [RFC3761] décrit comment le système des noms de domaines  (DNS, Domain Name System) peut être utilisé pour identifier les services associés à un numéro E.164. La transposition EPP décrite dans le présent document spécifie un mécanisme pour le provisionnement et la gestion des numéros E.164 mémorisés dans un répertoire central partagé. Les informations échangées via cette transposition peuvent être extraites du répertoire et utilisées pour publier les enregistrements de ressource du DNS comme décrit dans ENUM [RFC3761]. Les exemples utilisés dans le présent document ont été choisis spécifiquement pour illustrer les concepts de provisionnement pour les exemples d'enregistrements de ressource décrits dans la spécification ENUM.

1.1	Conventions utilisées dans le présent document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Dans les exemples, "C:" représente les lignes envoyées par un client de protocole, et "S:" représente les lignes retournées par un serveur de protocole. Les retours à la ligne et les espaces dans les exemples ne sont fournis que pour illustrer les relations des éléments et ne sont pas une caractéristique EXIGÉE de la présente spécification.

XML est sensible à la casse. Sauf mention contraire, les spécifications et exemples XML fournis dans le présent document DOIVENT être interprétés dans la casse de caractères présentée pour développer une mise en œuvre conforme.

2.	Attributs d'objet

Cette extension ajoute des éléments à la transposition de noms de domaine EPP [RFC3731]. Seules les nouvelles descriptions d'éléments sont données ici.

2.1	Noms de domaine E.164
Un nom de domaine E.164 est une représentation d'un numéro E.164 qui a été traduit pour se conformer à la syntaxe de nom de domaine, comme décrit dans la spécification ENUM [RFC3761]. Les étiquettes utilisées pour décrire l'espace de noms d'un nom de domaine E.164 sont une affaire de politique qui sort du domaine d'application du présent document.

2.2	Champs NAPTR
Selon ENUM [RFC3761], les enregistrements de ressource pointeur d'autorité de dénomination (NAPTR, Naming Authority Pointer) sont utilisés pour identifier les façons disponibles pour contacter un nœud spécifique identifié par un nom de domaine créé à partir de la traduction d'un numéro E.164. Le format de base d'enregistrement NAPTR est décrit dans la [RFC3403]. Les règles de structuration et d'utilisation des enregistrements NAPTR à utiliser avec ENUM sont décrites dans la [RFC3761].

Plusieurs valeurs de champ NAPTR sont facultatives selon la [RFC3403]. La [RFC3761] décrit les règles de traitement qui exigent la présence de certaines valeurs de champ NAPTR. Le présent document décrit les exigences de valeur des champs qui correspondent à la [RFC3761].

2.2.1	Order
Le champ NAPTR Order, un entier non signé de 16 bits, est représenté dans cette transposition en utilisant le schéma XML type de données  "unsignedShort".

2.2.2	Preference
Le champ NAPTR Preference, un entier non signé de 16 bits, est représenté dans cette transposition en utilisant le schéma XML type de données "unsignedShort".

2.2.3	Flags
Le champ NAPTR Flags est représenté dans cette transposition en utilisant un seul caractère. La casse du caractère Flag n'est pas significative.

2.2.4	Service
Le champ NAPTR Service est représenté dans cette transposition en utilisant une chaîne de caractères d'une longueur maximum non spécifiée. Les valeurs valides dépendent de l'application.

2.2.5	Expression régulière
Le champ NAPTR Regexp est représenté dans cette transposition en utilisant une chaîne de caractère d'une longueur maximum non spécifiée. Ce champ peut contenir de nombreuses barres obliques inverses (\) et devrait donc être traité avec une grande attention.

2.2.6	Replacement
Le champ NAPTR Replacement, dont la valeur est un nom de domaine, est représenté dans cette transposition en utilisant une chaîne de caractères d'une longueur maximum de 255 caractères.

3.	Transposition de commande EPP

Une description de la syntaxe et de la sémantique de EPP se trouve dans la spécification du cœur du protocole EPP [RFC3730]. Les transpositions de commandes décrites ici sont pour l'usage spécifique des mises en œuvre du processus de provisionnement de ENUM via EPP.

3.1	Commandes d'interrogation EPP
EPP fournit trois commandes pour restituer les informations d'objet : <check> pour déterminer si un objet est connu du serveur, <info> pour restituer les informations détaillées associées à un objet, et <transfer> pour restituer les informations d'état de transfert d'objet.

3.1.1	Commande EPP <check>
La présente extension n'ajoute aucun élément à la commande EPP <check> ou à la réponse <check> décrites dans la transposition de domaine EPP [RFC3731].

3.1.2	Commande EPP <info>
La présenteextension n'ajoute aucun élément à la commande EPP <info> décrite dans la transposition de domaine EPP [RFC3731]. Des éléments supplémentaires sont définis pour la réponse <info>.

Lorsque une commande <info> a été traitée avec succès, l'élément EPP <resData> DOIT contenir des éléments fils comme décrit dans la transposition de domaine EPP [RFC3731]. De plus, l'élément EPP <extension> DOIT contenir un élément fils <e164:infData> qui identifie l'espace de noms d'extension et la localisation du schéma d'extension. L'élément <e164: infData> contient un ou plusieurs éléments <e164:naptr> qui contiennent les éléments fils suivants :
- Un élément <e164:order> qui contient une valeur de NAPTR order.
- Un élément <e164:pref> qui contient une valeur de NAPTR preference.
- Un élément FACULTATIF <e164:flags> qui contient une valeur de NAPTR flags.- Un élément <e164:svc> qui contient une valeur de NAPTR service.
- Un élément FACULTATIF <e164:regex> qui contient une valeur de NAPTR regular expression.
- Un élément FACULTATIF <e164:replacement> qui contient une valeur de NAPTR replacement.

Exemple de réponse <info> :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S: <response>
S:  <result code="1000">
S:   <msg>Commande achevée avec succès</msg>
S:  </result>
S:  <resData>
S:   <domain:infData
S:    xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:    xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:    domain-1.0.xsd">
S:    <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name>
S:    <domain:roid>EXAMPLE1-REP</domain:roid>
S:    <domain:status s="ok"/>
S:    <domain:registrant>jd1234</domain:registrant>
S:    <domain:contact type="admin">sh8013</domain:contact>
S:    <domain:contact type="tech">sh8013</domain:contact>
S:    <domain:ns>
S:     <domain:hostObj>ns1.exemple.com</domain:hostObj>
S:     <domain:hostObj>ns2.exemple.com</domain:hostObj>
S:    </domain:ns>
S:    <domain:host>ns1.exemple.com</domain:host>
S:    <domain:host>ns2.exemple.com</domain:host>
S:    <domain:clID>ClientX</domain:clID>
S:    <domain:crID>ClientY</domain:crID>
S:    <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:    <domain:upID>ClientX</domain:upID>
S:    <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S:    <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:    <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:    <domain:authInfo>
S:     <domain:pw>2fooBAR</domain:pw>
S:    </domain:authInfo>
S:   </domain:infData>
S:  </resData>
S:  <extension>
S:   <e164:infData xmlns:e164="urn:ietf:params:xml:ns:e164epp-1.0"
S:    xsi:schemaLocation="urn:ietf:params:xml:ns:e164epp-1.0
S:    e164epp-1.0.xsd">
S:    <e164:naptr>
S:     <e164:order>10</e164:order>
S:     <e164:pref>100</e164:pref>
S:     <e164:flags>u</e164:flags>
S:     <e164:svc>E2U+sip</e164:svc>
S:     <e164:regex>"!^.*$!sip:info@exemple.com!"</e164:regex>
S:    </e164:naptr>
S:    <e164:naptr>
S:     <e164:order>10</e164:order>
S:     <e164:pref>102</e164:pref>
S:     <e164:flags>u</e164:flags>
S:     <e164:svc>E2U+msg</e164:svc>
S:     <e164:regex>"!^.*$!mailto:info@exemple.com!"</e164:regex>
S:    </e164:naptr>
S:   </e164:infData>
S:  </extension>
S:  <trID>
S:   <clTRID>ABC-12345</clTRID>
S:   <svTRID>54322-XYZ</svTRID>
S:  </trID>
S: </response>
S:</epp>

Une réponse d'erreur EPP DOIT être retournée si une commande <info> étendue ne peut pas être traitée pour toute raison.

3.1.3	Commande EPP <transfer>
La présente extension n'ajoute aucun élément à la commande EPP <transfer>  ou à la réponse <transfer> décrites dans la transposition de domaine EPP [RFC3731].

3.2	Commandes EPP de transformation
EPP fournit cinq commandes pour transformer les objets : <create> pour créer une instance d'un objet, <delete> pour supprimer une instance d'un objet, <renew> pour étendre la période de validité d'un objet, <transfer> pour gérer les changements de parrainage d'un objet , et <update> pour changer les informations associées à un objet.

3.2.1	Commande EPP <create>
Cette extension définit des éléments supplémentaires pour la commande EPP <create> décrite dans la transposition de domaine EPP [RFC3731]. Aucun élément supplémentaire n'est défini pour la réponse EPP <create>.

La commande EPP <create> donne une opération de transformation qui permet à un client de créer un objet de domaine. En plus des éléments de commande EPP décrits dans la transposition de domaine EPP [RFC3731], la commande DOIT contenir un élément <extension>. L'élément <extension> DOIT contenir un élément fils <e164:create> qui identifie l'espace de noms d'extension et la localisation du schéma d'extension. L'élément <e164:create> contient un ou plusieurs éléments <e164:naptr> qui contiennent les éléments fils suivants :
- Un élément <e164:order> qui contient une valeur NAPTR order.
- Un élément <e164:pref> qui contient une valeur NAPTR preference.
- Un élément FACULTATIF <e164:flags> qui contient une valeur NAPTR flags.
- Un élément <e164:svc> qui contient une valeur NAPTR service.
- Un élément FACULTATIF <e164:regex> qui contient une valeur NAPTR regular expression.
- Un élément FACULTATIF <e164:replacement> qui contient une valeur NAPTR replacement.

Exemple de commande <create> :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C: <command>
C:  <create>
C:   <domain:create
C:    xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:    xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:    domain-1.0.xsd">
C:     <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name>
C:     <domain:period unit="y">2</domain:period>
C:     <domain:ns>
C:      <domain:hostObj>ns1.exemple.com</domain:hostObj>
C:      <domain:hostObj>ns2.exemple.com</domain:hostObj>
C:     </domain:ns>
C:     <domain:registrant>jd1234</domain:registrant>
C:     <domain:contact type="admin">sh8013</domain:contact>
C:     <domain:contact type="tech">sh8013</domain:contact>
C:     <domain:authInfo>
C:      <domain:pw>2fooBAR</domain:pw>
C:     </domain:authInfo>
C:   </domain:create>
C:  </create>
C:  <extension>
C:   <e164:create
C:    xmlns:e164="urn:ietf:params:xml:ns:e164epp-1.0"
C:    xsi:schemaLocation="urn:ietf:params:xml:ns:e164epp-1.0
C:    e164epp-1.0.xsd">
C:    <e164:naptr>
C:     <e164:order>10</e164:order>
C:     <e164:pref>100</e164:pref>
C:     <e164:flags>u</e164:flags>
C:     <e164:svc>E2U+sip</e164:svc>
C:     <e164:regex>"!^.*$!sip:info@exemple.com!"</e164:regex>
C:    </e164:naptr>
C:    <e164:naptr>
C:     <e164:order>10</e164:order>
C:     <e164:pref>102</e164:pref>
C:     <e164:flags>u</e164:flags>
C:     <e164:svc>E2U+msg</e164:svc>
C:     <e164:regex>"!^.*$!mailto:info@exemple.com!"</e164:regex>
C:    </e164:naptr>
C:   </e164:create>
C:  </extension>
C:  <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>

Lorsque une commande <create> étendue a été traitée avec succès, la réponse EPP est comme décrit dans la transposition de domaine EPP [RFC3731].

3.2.2	Commande EPP <delete>
La présente extension n'ajoute aucun élément à la commande EPP <delete> ou à la réponse <delete> décrites dans la transposition de domaine EPP [RFC3731].

3.2.3	Commande EPP <renew>
La présente extension n'ajoute aucun élément à la commande EPP <renew> ou à la réponse <renew> décrites dans la transposition de domaine EPP [RFC3731].

3.2.4	Commande EPP <transfer>
La présente extension n'ajoute aucun élément à la commande EPP <transfer> ou à la réponse <transfer> décrites dans la transposition de domaine EPP [RFC3731].

3.2.5	Commande EPP <update>
La présente extension définit des éléments supplémentaires pour la commande EPP <update> décrite dans la transposition de domaine EPP [RFC3731]. Aucun élément supplémentaire n'est défini pour la réponse EPP <update>.

La commande EPP <update> donne une opération de transformation qui permet à un client de changer l'état d'un objet de domaine. En plus des éléments de commande EPP décrits dans la transposition de domaine EPP [RFC3731], la commande <update> DOIT contenir un élément <extension>. L'élément <extension> DOIT contenir un élément fils <e164:update> qui identifie l'espace de noms d'extension et la localisation du schéma d'extension. L'élément <e164:update> contient un ou plusieurs éléments <e164:addr> ou <e164:rem>. Chaque élément <e164:add> et <e164:rem> contient un élément <e164:naptr>qui contient les éléments fils suivants :
- Un élément <e164:order> qui contient une valeur NAPTR order.
- Un élément <e164:pref> qui contient une valeur NAPTR preference.
- Un élément FACULTATIF <e164:flags> qui contient une valeur NAPTR flags.
- Un élément <e164:svc> qui contient une valeur NAPTR service.
- Un élément FACULTATIF <e164:regex> qui contient une valeur NAPTR regular expression.
- Un élément FACULTATIF <e164:replacement> qui contient une valeur NAPTR replacement.

Exemple de commande <update> :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C: <command>
C:  <update>
C:   <domain:update
C:    xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:    xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:    domain-1.0.xsd">
C:    <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name>
C:     </domain:update>
C:   </update>
C:   <extension>
C:    <e164:update xmlns:e164="urn:ietf:params:xml:ns:e164epp-1.0"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:e164epp-1.0
C:     e164epp-1.0.xsd">
C:     <e164:rem>
C:      <e164:naptr>
C:       <e164:order>10</e164:order>
C:       <e164:pref>102</e164:pref>
C:       <e164:flags>u</e164:flags>
C:       <e164:svc>E2U+msg</e164:svc>
C:       <e164:regex>"!^.*$!mailto:info@exemple.com!"</e164:regex>
C:      </e164:naptr>
C:     </e164:rem>
C:    </e164:update>
C:   </extension>
C:  <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>

Quand une commande <update> étendue a été traitée avec succès, la réponse EPP est comme décrit dans la transposition de domaine EPP [RFC3731].

4.	Syntaxe formelle

Une transposition d'objet EPP est spécifiée en notation de schéma XML. La syntaxe formelle présentée ici est une représentation de schéma complète de la transposition d'objet convenable pour la validation automatique des instances XML EPP. Les fanions DÉBUT et FIN ne font pas partie du schéma ; ils sont utilisés pour noter le début et la fin du schéma pour les besoins de l'enregistrement d'URI.

DÉBUT
<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:ietf:params:xml:ns:e164epp-1.0"
        xmlns:e164="urn:ietf:params:xml:ns:e164epp-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

  <annotation>
    <documentation>
      Extensible Provisioning Protocol v1.0
      domain name extension schema for E.164 number provisioning.
    </documentation>
  </annotation>

<!--   Éléments fils trouvés dans les commandes EPP.   -->
     <element name="create" type="e164:createType"/>
     <element name="update" type="e164:updateType"/>
<!--   Éléments globaux.   -->
     <element name="naptr" type="e164:naptrType"/>

<!--  Éléments fils de la commande <create>.   -->
     <complexType name="createType">
       <sequence>
         <element ref="e164:naptr" maxOccurs="unbounded"/>
       </sequence>
     </complexType>

     <complexType name="naptrType">
       <sequence>
         <element name="order" type="unsignedShort"/>
         <element name="pref" type="unsignedShort"/>
         <element name="flags" type="e164:flagsType"
          minOccurs="0"/>
         <element name="svc" type="e164:svcType"/>
         <element name="regex" type="e164:regexType"
          minOccurs="0"/>
         <element name="repl" type="e164:replType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <simpleType name="flagsType">
       <restriction base="token">
         <pattern value="[A-Z]|[a-z]|[0-9]"/>
         <length value="1"/>
       </restriction>
     </simpleType>

     <simpleType name="svcType">
       <restriction base="token">
         <minLength value="1"/>
       </restriction>
     </simpleType>

     <simpleType name="regexType">
       <restriction base="token">
         <minLength value="1"/>
       </restriction>
     </simpleType>
     <simpleType name="replType">
       <restriction base="token">
         <minLength value="1"/>
         <maxLength value="255"/>
       </restriction>
     </simpleType>

<!--   Éléments fils de la commande <update>.   -->
     <complexType name="updateType">
       <sequence>
         <element name="add" type="e164:addRemType"
          minOccurs="0"/>
         <element name="rem" type="e164:addRemType"
          minOccurs="0"/>
       </sequence>
     </complexType>

<!--   Éléments de données qui peuvent être ajouté ou supprimés.   -->
     <complexType name="addRemType">
       <sequence>
         <element ref="e164:naptr" maxOccurs="unbounded"/>
       </sequence>
     </complexType>

<!--   Éléments de réponse fils.   -->
     <element name="infData" type="e164:infDataType"/>

<!--   Éléments de réponse <info>.   -->
     <complexType name="infDataType">
       <sequence>
         <element ref="e164:naptr" maxOccurs="unbounded"/>
       </sequence>
     </complexType>

<!--   Fin de schéma.   -->
   </schema>
FIN

7.	Considérations d'internationalisation

EPP est représenté en XML, qui fournit une prise en charge native des informations de codage en utilisant le jeu de caractères Unicode et ses représentations plus compactes, incluant UTF-8 [RFC3629]. Les processeurs XML conformes reconnaissent UTF-8 et UTF-16 [RFC2781]. Bien que XML comporte des dispositions pour identifier et utiliser d'autres codages de caractères grâce à un attribut "encoding" dans une déclaration <?xml?>, l'utilisation de UTF-8 est RECOMMANDÉE dans les environnements où il existe des incompatibilités de prise en charge de l'analyse du codage.

En tant qu'extension de la transposition de domaine EPP [RFC3731], les éléments, le contenu d'élément, les attributs, et les valeurs d'attribut décrits dans le présent document DOIVENT hériter des conventions d'internationalisation utilisées pour représenter les structures de domaine de couche supérieure et de cœur de protocole présentes dans une instance XML qui inclut la présente extension.

6.	Considérations relatives à l'IANA

Le présent document utilise des URN pour décrire les espaces de noms XML et les schémas XML se conformant à un mécanisme de registre décrit dans la [RFC3688]. Deux allocations d'URI ont été réalisées par l'IANA :

Enregistrement pour l'espace de nom d'extension :
URI : urn:ietf:params:xml:ns:e164epp-1.0
Contact de l'enregistrant : IESG
XML : aucun. Les URI d'espace de nom ne représentent pas une spécification XML.

Enregistrement pour le schéma XML d'extension :
URI : urn:ietf:params:xml:schema:e164epp-1.0
Contact de l'enregistrant : IESG
XML : voir la section "Syntaxe formelle" du présent document.

9.	Considérations sur la sécurité

Les extensions de transposition décrites dans le présent document ne fournissent aucun service de sécurité au delà de ceux décrits par EPP [RFC3730], la transposition de nom de domaine EPP [RFC3731], et les couches de protocole utilisées par EPP. Les considérations sur la sécurité relatives à ENUM sont décrites dans la section de "Considérations sur la sécurité" de la spécification ENUM [RFC3761] ; les considérations sur la sécurité relatives au système de découverte dynamique de délégation et les enregistrements NAPTR sont décrites dans la section "Considérations sur la sécurité" de la [RFC3403]. Les considérations sur la sécurité décrites dans ces spécifications s'appliquent aussi à la présente spécification.

Comme avec les autres transformations d'objet de domaines, les opérations de transformation EPP décrites dans le présent document DOIVENT se restreindre au client parrein tel qu'authentifié en utilisant les mécanismes décrits aux paragraphes 2.9.1.1 et à la section 7 de la [RFC3730]. Toute tentative d'effectuer des opération de transformation sur un objet de domaine par un client autre que le client parrain DOIT être rejetée avec une erreur d'autorisation EPP appropriée.

8.	Remerciements

L'auteur tient à remercier les personnes suivantes de leurs contributions significatives au développement du présent document : Lawrence Conroy, Edward Lewis, Michael Mealling, Allison Mankin, Chip Sharp, et James Yu.

9.	Références
9.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3403]	M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie III : base de données du système de noms de domaines (DNS)", octobre 2002. (P.S.)

[RFC3688]	M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

[RFC3730]	S. Hollenbeck, "Protocole d'approvisionnement extensible (EPP)", mars 2004. (Obsolète, voir RFC4930) (P.S.)

[RFC3731]	S. Hollenbeck, "Protocole d'approvisionnement extensible (EPP) : transposition de nom de domaine", mars  2004. (Obsolète, voir RFC4931) (P.S.)

[RFC3761]	P. Faltstrom, M. Mealling, "Application de E.164 au système de découverte dynamique de délégation (DDDS) d'identifiants de ressource uniformes (URI) (ENUM)", avril 2004. (P.S.) (Remplacée par la RFC6116)

[XML]	Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,  "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C  FirstEdition REC-xml-20001006, octobre 2000.

[XML-DATA]	Malhotra, A. and P. Biron, "schéma XML Part 2: Datatypes", W3C REC REC-xmlschema-2-20010502, mai 2001.

[XML-STR]	Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML   Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, mai 2001.

9.2	Références pour information

[RFC2781]	P. Hoffman et F. Yergeau, "UTF-16, un codage de la norme ISO 10646", février 2000.

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre  2003.

Adresse de l'auteur

Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20166-6503
US

mél : shollenbeck@verisign.com 

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.