Équipe d’ingénierie de l’Internet (IETF)

S. Bradner, Harvard University

Request for Comments : 6116

L. Conroy, Roke Manor Research

RFC rendue obsolète : 3761

K. Fujiwara, JPRS

Catégorie : En cours de normalisation

mars 2011

ISSN : 2070-1721

Traduction Claude Brière de L’Isle




Application de E.164 au système de découverte dynamique de délégation (DDDS) d'identifiants de ressource uniformes (URI) (ENUM)



Résumé

Le présent document discute de l’utilisation du système des noms de domaines (DNS, Domain Name System) pour la mémorisation de données associées aux numéros E.164, et pour la résolution de ces numéros dans des URI qui peuvent être utilisés (par exemple) dans l’établissement des appels téléphoniques. Le présent document décrit aussi comment le DNS peut être utilisé pour identifier les services associés à un numéro E.164. Le présent document rend obsolète la RFC3761.


Statut de ce mémoire

Ceci est un document de l'Internet qui est en cours de normalisation.


Le présent document a été produit par l'équipe d'ingénierie de l'Internet (IETF). Il représente le consensus de la communauté de l'IETF. Il a été accepté après relecture publique et sa publication a été approuvée par le groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group). D'autres informations sur les normes de l'Internet sont disponibles à la Section 2 de la RFC5741.


Les informations sur le statut actuel du présent document, sur tout errata, et sur la façon d'y faire des commentaires peuvent être obtenues à : http://www.rfc-editor.org/info/rfc6116 .


Notice de copyright

Copyright (c) 2011 IETF Trust et les personnes identifiées comme les auteurs du document. Tous droits réservés.


Le présent document est soumis aux dispositions légales du BCP 78 et de l'IETF Trust qui se rapportent aux documents de l'IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication du présent document. Prière de relire ces documents avec soin, car ils décrivent vos droits et obligations à l'égard du présent document. Les composants de code extraits de ce document doivent comporter le texte de la licence simplifiée de BSD telle que décrite au paragraphe 4.e des dispositions légales du Trust et ils sont fournis sans garantie comme décrit dans la licence BSD simplifiée.


Table des Matières

1. Introduction

1.1 Terminologie

2. Utilisation de ces mécanismes pour les plans de numérotation privés

3. Spécifications d’application ENUM

3.1 Chaîne unique d’application

3.2 Première règle bien connue

3.3 Résultat attendu

3.4 Bases de données valides

3.5 L’algorithme ENUM retourne toujours une seule règle

3.6 Sensibilité à la casse dans ENUM

3.7 Évitement de collision

4. Exemple de service ENUM

5. Précisions sur l’utilisation de DDDS dans ENUM

5.1 Collecte des implications pour le provisionnement ENUM

5.2 Collecte des implications pour les clients ENUM

6. Considérations relatives à l’IANA

7. Considérations sur la sécurité

7.1 Sécurité du DNS

7.2 Sécurité de la mise en antémémoire

7.3 Sécurité de l’acheminement d’appel

7.4 Sécurité de la résolution d’URI

8. Remerciements

9. Changements par rapport à la RFC3761

10. Références

10.1 Références normatives

10.2 Références pour information

Adresse des auteurs



1. Introduction


Le présent document expose l'utilisation du système des noms de domaines (DNS, Domain Name System) [RFC1034] [RFC1035] pour la mémorisation de données associées aux numéros E.164 [E.164], et pour résoudre ces numéros en URI qui peuvent être utilisés (par exemple) dans l'établissement des appels téléphoniques. Le présent document décrit aussi comment le DNS peut être utilisé pour identifier les services associés à un numéro E.164. Le présent document inclut une spécification d'application du système de recherche dynamique de délégation (DDDS, Dynamic Delegation Discovery System) comme détaillé dans la série de documents décrite dans la [RFC3401]. Le présent document rend obsolète la [RFC3761].


En utilisant le processus défini dans le présent document, les numéros de téléphone public international dans le format international défini dans la Recommandation [E.164] de l'Union Internationale des Télécommunications (UIT) (qu'on appelle ici des "numéros E.164") peuvent être transformés en noms du DNS. En utilisant les services existants du DNS (comme la délégation à travers un enregistrement NS et les interrogations de ressources de pointeur d’autorité de nommage (NAPTR, Naming Authority PoinTeR) on peut chercher les services associés à ce numéro E.164. Cela tire parti des caractéristiques standard de l'architecture du DNS de contrôle décentralisé et de gestion des différents niveaux du processus de recherche.


Le domaine "e164.arpa" a été alloué pour fournir une infrastructure dans le DNS pour mémoriser les données associées aux numéros E.164. Pour faciliter les opérations réparties, ce domaine est divisé en sous domaines. Les détenteurs de numéros E.164 qui veulent que ces numéros figurent dans le DNS devraient contacter l'administrateur de zone approprié comme mentionné dans la politique attachée à la zone. On devrait commencer par chercher ces informations en examinant l'enregistrement de ressource SOA associé à la zone, tout comme pour une opération normale du DNS.


Bien sûr, comme avec les autres domaines, les politiques pour de telles listes seront contrôlées sur la base du sous domaine et peuvent différer dans les différentes parties du monde.


1.1 Terminologie


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


Les types d’enregistrement de ressource DNS mentionnés dans le présent document sont définis, respectivement dans la [RFC1035] (NS, SOA, A, MX), la [RFC3403] (NAPTR), et la [RFC2782] (SRV).


Tous les autres termes en majuscules sont tirés du vocabulaire de la spécification d’algorithme DDDS de la [RFC3402].


2. Utilisation de ces mécanismes pour les plans de numérotation privés


Des mécanismes similaires pourraient être utilisés pour d'autres sortes de chaînes numériques (comme les nombres dans des plans de numérotation privés). Si ces mécanismes sont utilisés pour des plans de numérotages (ou pour d'autres chaînes numériques sans rapport) l'apex de domaine utilisé pour une telle traduction NE DOIT PAS être e164.arpa, pour éviter des conflits avec cette spécification.


Aussi, la chaîne unique d'application (voir le paragraphe 3.1) utilisée avec les plans de numérotage DEVRAIT être le numéro complet comme spécifié, sans le caractère '+' en tête. Le caractère '+' est utilisé pour mieux distinguer les numéros E.164 en format international des chaîne de numéros composées dans d'autres séquences de chiffres.


Par exemple, pour s'adresser au numéro E.164 +44-3069-990038, un usager devrait composer "03069990038" ou "00443069990038" ou "011443069990038". Ces chaînes numériques composées diffèrent l'une de l'autre, mais aucune d'elles ne commence par le caractère '+'.


Finalement, si ces techniques sont utilisées pour les plans de numérotage ou d'autres chaînes numériques, les mises en œuvre et les opérateurs de systèmes qui utilisent ces techniques pour de tels objets NE DOIVENT PAS décrire ces schémas comme "ENUM". Le "E" initial dans ENUM signifie E.164, et le terme "ENUM" est utilisé exclusivement pour décrire l'application de ces techniques aux numéros E.164 conformément à la présente spécification.


3. Spécifications d’application ENUM


Le présent gabarit définit l'application DDDS ENUM conformément aux règles et exigences qu'on trouve dans la [RFC3402]. La base de données DDDS utilisée par cette application se trouve dans la [RFC3403], qui est le document qui définit le type d'enregistrement de ressource NAPTR du DNS.


ENUM est conçu comme un moyen pour traduire les numéros E.164 en URI en utilisant les enregistrements NAPTR mémorisés dans le DNS. La première règle bien connue pour toute interrogation ENUM crée une clé (un nom de domaine pleinement qualifié ou FQDN, au sein de l'apex de domaine e164.arpa) à partir d'un numéro E.164. Ce FQDN est interrogé pour des enregistrements de NAPTR et les enregistrements retournés sont traités et interprétés conformément à la présente spécification.


3.1 Chaîne unique d’application

La chaîne unique d'application (AUS, Application Unique String) est un numéro E.164 pleinement qualifié moins tout caractère non numérique sauf le caractère '+' qui apparaît au début du numéro. Le '+' est conservé pour fournir une ancre bien comprise du AUS afin de le distinguer des autres numéros de téléphone qui ne font pas partie de l'espace de noms E.164.


Par exemple, le numéro E.164 pourrait se présenter comme "+44-116-496-0348". Pour s'assurer qu'il n'y a pas d'erreur syntaxique dans le AUS, tous les caractères non numériques sauf le '+' sont retirés, donnant "+441164960348".


3.2 Première règle bien connue

La première règle bien connue convertit un AUS en une clé initiale. Cette clé est utilisée comme indice dans la base de données des règles de l'application. Pour ENUM, la base de données des règles est le DNS, de sorte que la clé est un nom de domaine pleinement qualifié (FQDN, fully qualified domain name).


Pour convertir l'AUS en une clé unique dans cette base de données, la chaîne est convertie en un nom de domaine selon l'algorithme suivant :

1. Retirer tous les caractères à l'exception des chiffres. Par exemple, soit le numéro E.164 "+44-20-7946-0148" (qui aurait été ensuite converti en l'AUS de "+442079460148") cette étape retirerait simplement le '+' de tête, produisant "442079460148".

2. Inverser l'ordre des chiffres. Exemple : "841064970244"

3. Mettre des points ('.') entre chaque chiffre. Exemple : "8.4.1.0.6.4.9.7.0.2.4.4"

4. Ajouter la chaîne ".e164.arpa." à la fin et interpréter comme nom de domaine. Exemple : 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.


L'espace de noms E.164 et cette base de données d'application sont organisés d'une façon telle qu'il est possible d'aller directement du nom à la plus fine granularité de l'espace de noms directement du nom lui-même, de sorte qu'aucun autre traitement n'est nécessaire pour générer la clé initiale.


Ce nom de domaine est utilisé pour demander les enregistrements NAPTR. Chacun de ces enregistrements peut contenir le résultat final ou, si son champ de fanions est vide, produire une nouvelle clé sous la forme d 'un nom de domaine qui est utilisé pour demander d'autres enregistrements NAPTR au DNS.


3.3 Résultat attendu

Le résultat de la dernière boucle de DDDS est un identifiant de ressource universel (URI, Uniform Resource Identifier) dans sa forme absolue selon la production <absolute-URI> dans l'ABNF collecté de la [RFC3986].


3.4 Bases de données valides

À présent seule une base de données de DDDS est spécifiée pour cette application. La troisième partie du "système de recherche dynamique de délégation (DDDS) : base de données DDDS" [RFC3403] spécifie une base de données DDDS qui utilise l'enregistrement de ressource NAPTR du DNS pour contenir les règles de réécriture. Les clés pour cette base de données sont codées comme des noms de domaine.


Le jeu de caractères utilisé pour l'expression de substitution est UTF-8 [RFC3629]. Les caractères d'entrée admis sont tous les caractères qui sont admis partout dans un numéro E.164. Les caractères admis dans une clé sont ceux qui sont actuellement définis pour les noms de domaine du DNS.


3.4.1 Traitement de la section supplémentaire de serveur de nom facultative

Certaines mises en œuvre de serveur de noms tentent d'être intelligentes avec les éléments qui sont insérés dans la section des informations supplémentaires d'une réponse du DNS. Par exemple, BIND va tenter de détermine si elle donne une autorisation pour un domaine chaque fois qu'il en code une dans un paquet. Si elle le fait, il va alors insérer tous les enregistrements A qu'il trouve pour ce domaine dans la section des informations supplémentaires de la réponse jusqu'à ce que le paquet atteigne la longueur maximale autorisée. Il est donc potentiellement utile pour un client de vérifier ces informations supplémentaires.


Il est aussi facile de considérer un serveur de noms ENUM amélioré qui comprend le contenu réel des enregistrements NAPTR qu'il sert et qui insère des informations plus appropriées dans la section des informations supplémentaires de la réponse. Donc, les serveurs DNS PEUVENT interpréter les valeurs des fanions et utiliser ces informations pour inclure des enregistrements de ressource appropriés dans la section des informations supplémentaires du paquet DNS. Les clients sont encouragés à vérifier les informations supplémentaires mais ne sont pas obligés de le faire. Voir au paragraphe 4.2 de la [RFC3403] ("Traitement des informations supplémentaires") plus d'informations sur les enregistrements NAPTR et la section des informations supplémentaires d'un paquet de réponse DNS.


3.4.2 Fanions

Cette base de données contient un champ qui contient des fanions qui signalent quand l'algorithme de DDDS est terminé. Pour l'instant, un seul fanion, "U", est défini. Cela signifie que cette règle est la dernière et que le résultat de la règle est un URI [RFC3986]. Voir le paragraphe 4.3 de la [RFC3404].


Si un client rencontre un enregistrement de ressource avec un fanion inconnu, il DOIT l'ignorer et passer à la règle suivante. Cette vérification a la préséance sur tout ordre car les fanions peuvent contrôler l'interprétation des champs.


Un nouveau fanion pourrait changer l'interprétation des champs Regexp et/ou Replacement de façon telle qu'il est impossible de déterminer si un enregistrement de ressource correspond à une certaine cible.


Si ce fanion n'est pas présent, cette règle n'est alors pas terminale. Si une règle n'est pas terminale, alors le résultat produit par cette règle réécrite DOIT être un FQDN. Les clients DOIVENT utiliser ce résultat comme la nouvelle clé dans la boucle DDDS (c'est-à-dire, le client va demander des enregistrements de ressource NAPTR à ce FQDN).


3.4.3 Paramètres de service

Les paramètres de service pour cette application prennent la forme Backus-Naur augmenté (ABNF, spécifié dans la [RFC5234]) suivante et se trouvent dans le champ Services de l'enregistrement NAPTR qui détient une règle terminale. Lorsque le NAPTR détient une règle non terminale, le champ Services DEVRAIT être vide, et les clients DEVRAIENT ignorer son contenu.


service-field = "E2U" 1*(servicespec)

servicespec = "+" enumservice

enumservice = type 0*(subtypespec)

subtypespec = ":" subtype

type = 1*32(ALPHA / DIGIT / "-")

subtype = 1*32(ALPHA / DIGIT / "-")


En d'autres termes, un "E2U" non facultatif (utilisé pour noter des règles de réécriture seulement ENUM afin de diminuer le risque de collisions d'enregistrements) est suivi par un ou plusieurs Enumservices qui indiquent la classe de fonctionnalités qu'offre un certain point d'extrémité. Chaque Enumservice est indiqué par un caractère '+' initial.


3.4.3.1 Services ENUM

Les Enumservices peuvent être spécifiés et enregistrés via le procès défini dans la [RFC6117]. Ce processus d'enregistrement n'est pas ouvert à un Enumservice qui a '-' comme second caractère dans sa chaîne de type.


En particulier, ce procès d'enregistrement n'est pas ouvert aux types d'Enumservice qui commencent par la combinaison "X-". Cette combinaison "X-" est réservée aux utilisations expérimentales ou d'essai, et de tels Enumservices ne peuvent pas être enregistrés selon le processus normal.


Finalement, tout type de Enumservice qui commence par la combinaison "P-" est destiné exclusivement à une utilisation sur des réseaux privés. À ce titre les enregistrements NAPTR qui contiennent des types Enumservice qui commencent par "P-" ne devraient pas se voir sur l'Internet mondial. Même si un client ENUM reconnaît et peut s'engager dans le Enumservice, il peut être incapable de résoudre l'URI généré par le NAPTR qui le contient. Ces Enumservices NE SERONT PAS enregistrés.


De tels Enumservices NE DOIVENT PAS être provisionnés dans un système qui fournit des réponses aux interrogations au DNS sur des ensembles d'enregistrement de ressource (RRSet, resource record set) de NAPTR provenant d'entités en dehors du contexte de réseau privé dans lequel ces Enumservices sont destinés à être utilisés. Sauf si un client ENUM est sûr qu'il est connecté au réseau privé pour lequel ces NAPTR sont provisionnés et destinés, il DOIT éliminer tout NAPTR qui a un type Enumservice qui commence par la combinaison "P-".


3.4.3.2 NAPTR composés et valeurs implicites d’ordre/préférence

Il est possible d'avoir plus d'un Enumservice associé à un seul NAPTR. Ces Enumservices partagent le même champ Regexp et ainsi génèrent le même URI. Un tel NAPTR "composé" pourrait très bien être utilisé pour indiquer un téléphone mobile qui prend en charge les Enumservices aussi bien "voice:tel" que "sms:tel". Le champ Services serait "E2U+voice:tel+sms:tel" dans ce cas.


Un NAPTR composé peut être traité comme un ensemble de NAPTR qui chacun détiennent un seul Enumservice. Ces NAPTR reconstruits partagent les mêmes valeurs de champ ORDER et PREFERENCE/PRIORITY mais devraient être traités comme si chacun avait une priorité logiquement différente. On suppose une priorité de gauche à droite.


3.5 L’algorithme ENUM retourne toujours une seule règle

L'algorithme ENUM retourne toujours une seule règle. Des applications individuelles peuvent avoir des connaissances ou facilités spécifiques de l'application qui leur permettent de présenter des résultats multiples ou un choix de vitesse, mais cela ne devrait jamais changer le fonctionnement de l'algorithme.


3.6 Sensibilité à la casse dans ENUM

La sensibilité à la casse n'était pas mentionnée du tout dans la [RFC3761] (ou la [RFC2916]) mais cela a posé un problème dans les événements d'essai d'interopérabilité faits depuis. Il y a un grand nombre de clients sensibles à la casse dans les déploiements actuels.


Le seul endroit où le contenu du champ NAPTR est sensible à la casse est dans un texte statique dans le sous champ Repl du champ Regexp (voir au paragraphe 3.2 de la [RFC3402] la définition du champ Regexp). Dans ce sous champ, la casse doit être préservée lorsque on génère le résultat de l'enregistrement. Ailleurs, la sensibilité à la casse n'est pas utilisée.


Lorsque les clients ENUM peuvent être exposés à des enregistrements NAPTR qui pourraient détenir un contenu de champ de casses différentes, les clients DOIVENT utiliser le traitement insensible à la casse. Les clients ENUM qui fonctionnent en utilisant l'Internet pour envoyer leurs interrogations, normalement appelés des scénarios "Public ENUM", entrent dans cette catégorie.


Certains clients ENUM opèrent au sein de réseaux clos ; par exemple, au sein de réseaux de données isolés gérés par des fournisseurs de services de communications. On les appelle normalement des scénarios "d'infrastructure ENUM". Toutes les zones approvisionnées dans de tels réseaux clos ont habituellement une casse connue pour le contenu de la chaîne d'enregistrement ENUM, car les systèmes d'approvisionnement pour de tels réseaux sont souvent contrôlés avec soin. Dans un tel environnement, les clients ne sont jamais exposés à des enregistrements dont la casse serait "inattendue" et peuvent donc (et ont été) conçus avec un traitement sensible à la casse. C'est seulement si un client est connu pour fonctionner dans un environnement dans lequel la casse de tous les enregistrements ENUM qu'il va rencontrer est connue et contrôlée que le client PEUT utiliser un traitement sensible à la casse.


3.7 Évitement de collision

Une application conforme à ENUM DOIT seulement passer les nombres au processus d'interrogation de client ENUM dont elle pense que ce sont des numéros E.164 (par exemple, elle NE DOIT PAS passer des chaînes de chiffres composés au processus d'interrogation ENUM).


Comme les plans de numérotage peuvent changer au cours du temps, il peut être impossible à un client de savoir si le numéro sur lequel il a l'intention d'interroger est alloué et actif dans le plan de numérotage actuel. Il est donc important que de tels clients puissent distinguer les données associées au plan de numérotage E.164 de celles associées à d'autres chaînes de chiffres (c'est-à-dire, de numéros qui NE se conforment PAS au plan de numérotage E.164).


Il est de la responsabilité des opérateurs qui provisionnent les données dans les domaines de s'assurer que les données associées à une interrogation sur un numéro E.164 ne peuvent pas être à tort prises pour des données associées à d'autres usages des NAPTR.


Trois techniques sont utilisées pour arriver à cela :

o l'apex du domaine utilisé pour des besoins autres que les données associées au plan de numérotage E.164 NE DOIT PAS être e164.arpa ;

o pour une utilisation autre que les numéros E.164, la chaîne unique d'application NE DOIT PAS commencer par le caractère '+', tandis que pour l'usage de ENUM, le AUS DOIT commencer par ce caractère ;

o les NAPTR qui sont destinés à d'autres applications DDDS NE DOIVENT PAS inclure le jeton E2U dans leur champ Service, tandis que les NAPTR destinés à l'usage de ENUM DOIVENT inclure ce jeton.


4. Exemple de service ENUM


$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.

NAPTR 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .

NAPTR 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .

NAPTR 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .


Ceci décrit que le domaine 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. est de préférence contacté par SIP, ensuite via H.323 pour le vocal, et en troisième lieu par SMTP pour la messagerie. Noter que les jetons Enumservice "sip", "h323", et "email" sont des types Enumservice enregistrés par l'IANA, et n'ont pas de connexion implicite avec les schémas de protocole ou d'URI du même nom.


Dans tous les cas, l'étape suivante dans le processus de résolution est d'utiliser le mécanisme de résolution pour chacun des protocoles (spécifiés par les schémas d'URI sip, h323, et mailto) pour savoir quel nœud contacter.


Dans chacun des deux premiers enregistrements, le sous champ ERE correspond seulement aux interrogations qui ont été faites pour le numéro de téléphone +441632960083. Dans le dernier enregistrement, le ERE correspond à toutes les valeurs de chaîne unique d'application. Le premier enregistrement montre aussi comment le schéma de correspondance peut être utilisé dans l'URI généré.


Noter que lorsque des enregistrements de ressource NAPTR sont montrés dans la syntaxe de fichier maître du DNS (comme dans l'exemple ci-dessus) chaque barre oblique inverse (\) doit être échappée en utilisant une seconde barre oblique inverse. Le paquet DNS dans le réseau aura seulement une seule barre oblique inverse dans chaque cas.


5. Précisions sur l’utilisation de DDDS dans ENUM


ENUM est une application DDDS. Cela signifie qu'elle s'appuie sur le DDDS pour son fonctionnement. DDDS est conçu pour être souple, mais cela ouvre la possibilité de différences d'interprétation. La présente section est destinée à couvrir les interprétations spécifiques de ENUM de textes dans les spécifications de DDDS. Le but est de s'assurer de l'interopérabilité entre les clients ENUM et les systèmes d'approvisionnement utilisés pour remplir les domaines avec des NAPTR E2U.


Au titre du travail de développement en cours sur les spécifications ENUM, la [RFC5483] donne une analyse (informative) de la façon dont le client ENUM et les mises en œuvre de système d'approvisionnement se comportent et des questions d'interopérabilité qui surviennent. Les recommandations suivantes reflètent cette analyse, et des explications décrivant ces problèmes se trouvent dans cette RFC.


5.1 Collecte des implications pour le provisionnement ENUM

Les NAPTR ENUM NE DEVRAIENT PAS inclure de caractères en dehors de la gamme équivalente de l'US-ASCII imprimable (de U+0020 à U+007E) sauf si il est clair que tous les clients ENUM qui sont conçus pour les prendre en charge sont capables de traiter correctement de tels caractères. Si les systèmes d'approvisionnement de zone ENUM exigent des caractères non ASCII, ces systèmes DOIVENT coder les données non ASCII pour émettre seulement des caractères US-ASCII en appliquant le mécanisme approprié (comme celui des [RFC3492], [RFC3987]). Les caractères non imprimables NE DEVRAIENT PAS être utilisés car les clients ENUM peuvent avoir besoin de présenter le contenu du NAPTR sous une forme lisible par l'homme.


Le fanion de sensibilité à la casse ('i') n'est pas approprié pour ENUM, et NE DEVRAIT PAS être provisionné dans le champ Regexp des NAPTR E2U.


L'enregistrant et le système d'approvisionnement de zone ENUM qu'il utilise NE DEVRAIENT PAS s'appuyer seulement sur les clients ENUM pour tenir compte de la valeur des champs ORDER et PREFERENCE/PRIORITY dans les NAPTR ENUM. Donc, un enregistrant DEVRAIT placer dans sa zone seulement les contacts qu'il veut prendre en charge, même ceux qui ont les pires valeurs de ORDER et de PREFERENCE/PRIORITY PEUVENT être choisis par un utilisateur final.


Tous les NAPTR E2U DEVRAIENT contenir une valeur par défaut dans leur champ ORDER. Une valeur de "100" est recommandée, car elle semble être utilisée dans la plupart des domaines provisionnés.


Certains clients ENUM sont connus pour avoir pré éliminé des NAPTR au sein d'un RRSet simplement parce que ces enregistrements n'avaient pas la plus faible valeur de ORDER trouvée dans ce RRSet. D'autres mises en œuvre de client ENUM paraissent avoir confondu les champs ORDER et PREFERENCE/PRIORITY, utilisant ce dernier comme terme majeur de tri plutôt que le premier, comme spécifié. À l'inverse, des zones ENUM ont été provisionnées au sein desquelles la valeur de ORDER varie mais la valeur du champ PREFERENCE/PRIORITY est statique. Ceci peut avoir été intentionnel, mais étant donné les différents comportements de client en face de valeurs variables du champ ORDER, cela ne peut pas produire la réponse désirée.

Plusieurs NAPTR avec des valeurs de champ ORDER et PREFERENCE/ PRIORITY identiques NE DEVRAIENT PAS être provisionnés dans un RRSet sauf si l'intention est que ces NAPTR soient vraiment identiques et qu'il n'y ait pas de préférence entre eux. Les mises en œuvre NE DEVRAIENT PAS supposer que le DNS va délivrer des NAPTR au sein d'un RRSet dans une séquence particulière.

Un système de provisionnement de zone ENUM DEVRAIT supposer que, si il génère des NAPTR composés, les Enumservices vont normalement être traités dans l'ordre de gauche à droite au sein de tels NAPTR.

Les systèmes de provisionnement de zone ENUM DEVRAIENT supposer que, une fois qu'un NAPTR non terminal a été choisi pour être traité, la valeur du champ ORDER dans un domaine référencé par ce NAPTR non terminal ne sera considérée que dans le contexte de ce domaine référencé (c'est-à-dire, la valeur de ORDER sera utilisée seulement pour le tri au sein du RRSet courant et ne sera utilisée dans le traitement des NAPTR d'aucun autre RRSet).


Les systèmes de provisionnement de zone ENUM DEVRAIENT utiliser '!' (U+0021) comme caractère délimiteur de Regexp.


Si le délimiteur Regexp est un caractère dans le texte statique du sous champ Repl, il DOIT être "échappé" en utilisant la production de délimiteur échappé de la spécification de BNF du paragraphe 3.2 de la [RFC3402] (c'est-à-dire, "\!", U+005C U+0021). Noter que lorsque un enregistrement de ressource NAPTR est entré dans la syntaxe de fichier maître du DNS, la barre oblique inverse elle-même doit être échappée en utilisant une seconde barre oblique inverse.


Si il est présent dans le sous champ ERE d'un NAPTR ENUM, le caractère littéral '+' DOIT être échappé comme "\+" (c'est-à-dire U+005C U+002B). Noter que, comme toujours, lorsque un enregistrement de ressource NAPTR est entré dans une syntaxe de fichier maître du DNS, la barre oblique elle-même doit être échappée en utilisant une seconde barre oblique inverse.


Bien que ce comportement de client soit non conforme, les systèmes de provisionnement ENUM et leurs utilisateurs devraient savoir que certains clients ENUM ont été détectés avec une mauvaise prise en charge (ou pas de prise en charge du tout) d'expressions de sous champ ERE non triviales.


Les systèmes de provisionnement ENUM DEVRAIENT être prudents dans l'utilisation de schémas de plusieurs rétro références dans le sous champ Repl des NAPTR qu'ils provisionnent. Certains clients ont un espace de mémoire tampon limité pour l'expansion de caractères lorsque ils génèrent des URI. Ces systèmes de provisionnement DEVRAIENT vérifier les schémas de remplacement de rétro référence qu'ils utilisent, et s'assurer que le traitement régulier de l'expression ne va pas produire des URI d'une longueur excessive.


Les zones ENUM NE DOIVENT PAS être provisionnées avec des NAPTR selon la syntaxe obsolète de la [RFC2916], et elles DOIVENT être provisionnées avec des NAPTR dans lesquels le champ Services est conforme au paragraphe 3.4.3 du présent document.


Les [RFC2915] et [RFC2916] ont été rendues obsolètes, respectivement, par les [RFC3401]-[RFC3404] et par le présent document.


Les Enumservices dans lesquels le type Enumservice commence par la combinaison "P-" NE DOIVENT PAS être provisionnés dans un système qui fournit des réponses aux interrogations du DNS pour des ensembles d'enregistrements de ressource NAPTR qui proviennent d'entités en dehors du contexte du réseau privé dans lequel l'utilisation de ces Enumservices est prévue. Comme la prise en charge actuelle est limitée, les NAPTR non terminaux NE DEVRAIENT PAS être provisionnés en zones ENUM si il n'est pas clair que tous les clients ENUM que cet environnent prend en charge peuvent les traiter.


Lorsque on remplit un ensemble de domaines avec des NAPTR, les systèmes de provisionnement de zone ENUM NE DEVRAIENT PAS configurer des NAPTR non terminaux de telle sorte que plus de cinq tels NAPTR soient traités dans une interrogation ENUM.


Dans un NAPTR non terminal qui peut se rencontrer dans une interrogation ENUM (c'est-à-dire, une avec un champ Fanions vide) le champ Services DEVRAIT être vide.


Un NAPTR non terminal DOIT inclure son domaine cible dans le champ (non vide) Replacement, car ce champ sera interprété comme détenant le FQDN qui forme le résultat de prochaine clé de cette règle non terminale. Le champ Regexp DOIT être vide dans un NAPTR non terminal destiné à être rencontré durant une interrogation ENUM.


5.2 Collecte des implications pour les clients ENUM

Si un NAPTR est éliminé, cela NE DEVRAIT PAS causer la terminaison de toute interrogation ENUM et le traitement DEVRAIT continuer avec le prochain NAPTR dans le RRSet retourné.


Les clients ENUM NE DEVRAIENT PAS éliminer les NAPTR dans lesquels ils détectent des caractères hors de la gamme US-ASCII imprimable (0x20 à 0x7E hexadécimal).


Les clients ENUM PEUVENT éliminer les NAPTR qui ont des octets dans les champs Fanions, Services, ou Regexp qui ont des valeurs d'octets hors de la gamme équivalente de l'US-ASCII (c'est-à-dire, des valeurs d'octets au dessus de 0x7F). Les clients DOIVENT être prêts à rencontrer sans échec des NAPTR avec de telles valeurs.


Les clients ENUM DOIVENT trier les enregistrements d'un RRSet NAPTR restitué en séquence en utilisant les champs ORDER et PREFERENCE de ces enregistrement. Le champ ORDER est à traiter comme le terme majeur de tri, les valeurs numériques inférieures étant les premières dans la séquence. Le champ PREFERENCE/PRIORITY est à traiter comme le terme de tri mineur, les valeurs numériques inférieures étant les premières dans la séquence.


Les clients ENUM NE DEVRAIENT PAS éliminer un enregistrement NAPTR avant qu'il ait été pris en compte ou qu'un enregistrement qui se trouve avant lui dans la séquence d'évaluation ait été accepté.


Notamment, si un enregistrement a une valeur de ORDER "pire" que d'autres dans ce RRSet, cet enregistrement NE DOIT PAS être éliminé avant sa prise en considération sauf si un enregistrement a été accepté comme résultat de cette interrogation ENUM.


Lorsque le client ENUM présente une liste d'URL possibles au choix de l'utilisateur final, il PEUT présenter tous les NAPTR – pas seulement ceux qui ont la plus faible valeur du champ ORDER actuellement non traitée. Le client DEVRAIT observer les valeurs de ORDER et de PREFERENCE/PRIORITY spécifiées par l'enregistrant.


Les clients ENUM DEVRAIENT accepter tous les NAPTR avec des valeurs identiques des champs ORDER et PREFERENCE/PRIORITY, et les traiter dans la séquence selon laquelle elles apparaissent dans la réponse du DNS. (Il n'y a aucun avantage à rendre plus aléatoire l'ordre dans lequel elles sont traitées, comme l'ont déjà fait les serveurs du DNS actuels).


Les clients ENUM DEVRAIENT considérer la valeur du champ ORDER seulement quand ils trient les NAPTR au sein d'un seul RRSet. La valeur du champ ORDER NE DEVRAIT PAS être prise en compte lors du traitement des NAPTR à travers une séquence d'interrogations du DNS créées par la traversée de références de NAPTR non terminales.


Les clients ENUM qui reçoivent des NAPTR composés (c'est-à-dire, ceux qui ont plus d'un Enumservice) DEVRAIT traiter ces Enumservices en utilisant un ordre de tri de gauche à droite, afin que le premier Enumservice traité soit le plus à gauche, et que le dernier soit le plus à droite.


Les clients ENUM DOIVENT être prêts à traiter sans échec les NAPTR qui utilisent un caractère différent de '!' comme délimiteur de Regexp.


Les clients ENUM NE DEVRAIERNT PAS supposer que le délimiteur est le dernier caractère du champ Regexp. Sauf si ils sont sûrs que c'est le cas dans leur environnement, en général un client ENUM peut quand même rencontrer des NAPTR qui ont été provisionnés avec un fanion 'i' (insensible à la casse) suivant, même si ce fanion n'a pas d'effet du tout dans un scénario ENUM.


Les clients ENUM DEVRAIENT éliminer les NAPTR qui ont plus ou moins de trois instances non échappées du caractère délimiteur au sein du champ Regexp.


Dans l'esprit d'être libéral dans ce qu'on accepte, si le client ENUM est sûr de la façon dont le champ Regexp devrait être interprété, il PEUT choisir de traiter le NAPTR même en présence d'un nombre incorrect de caractères délimiteurs non échappés. Si la façon d'interpréter le champ Regexp n'est pas claire, le client DOIT éliminer le NAPTR.


Les clients ENUM DOIVENT être prêts à traiter sans échec les NAPTR qui ont des schémas non triviaux dans leurs valeurs de sous champ ERE.


Les clients ENUM DOIVENT être prêts à traiter sans échec les NAPTR qui ont plusieurs schémas de copies de rétro références au sein du sous champ Repl.


Les clients ENUM DOIVENT être prêts à traiter sans échec les NAPTR qui ont un identifiant d'application DDDS autre que 'E2U'.


Lorsque un client ENUM rencontre un NAPTR composé (c'est-à-dire, qui contient plus d'un Enumservice) et qu'il ne peut pas traiter ou ne peut pas reconnaître un des Enumservices en son sein, ce client ENUM DEVRAIT ignorer cet Enumservice et continuer avec le prochain Enumservice dans le champ Services de ce NAPTR, n'éliminant le NAPTR que si il ne peut traiter aucun des Enumservices contenus. Ces conditions NE DEVRAIENT PAS être considérées comme des erreurs.


Les clients ENUM DOIVENT prendre en charge les NAPTR ENUM conformément à la syntaxe définie au paragraphe 3.4.3. Les clients ENUM DEVRAIENT aussi prendre en charge les NAPTR ENUM conformément à la syntaxe obsolète de la [RFC2916] ; il y a encore des zones qui contiennent la "vieille" syntaxe de NAPTR. La [RFC3824] pour information recommandait une telle prise en charge.


Sauf si un client ENUM est sûr qu'il est connecté au réseau privé pour lequel ces NAPTR sont provisionnés et destinés, il DOIT éliminer tout NAPTR qui a un type Enumservice qui commence par la combinaison "P-".


5.2.1 Traitement de NAPTR non terminal

Les clients ENUM DOIVENT être prêts à traiter sans échec les NAPTR qui ont un champ Fanions vide (les NAPTR "non terminaux"). Plus généralement, le traitement de NAPTR non terminal DEVRAIT être mis en œuvre, mais les clients ENUM PEUVENT éliminer les NAPTR non terminaux qu'ils rencontrent.


Les clients ENUM DEVRAIT ignorer tout contenu du champ Services lorsque ils rencontrent un NAPTR non terminal avec un champ Fanions vide .


Les clients ENUM qui reçoivent un NAPTR non terminal avec un champ Fanions vide DOIVENT traiter le champ Replacement comme contenant le FQDN à utiliser dans le prochain tour de l'interrogation ENUM. Un client ENUM DOIT éliminer un tel NAPTR non terminal si le champ Replacement est vide ou si il ne contient pas un FQDN valide. Par définition, il s'ensuit que le champ Regexp sera vide dans un tel NAPTR non terminal. Si il est présent dans un NAPTR non terminal, un champ Regexp non vide DOIT être ignoré par les clients ENUM.


Si un problème est détecté lors du traitement d'une interrogation ENUM sur plusieurs domaines (en suivant les références de NAPTR non terminal) l'interrogation ENUM NE DEVRAIT PAS être abandonnée, mais le traitement DEVRAIT plutôt continuer sur le prochain NAPTR après le NAPTR non terminal qui se référait au domaine dans lequel le problème serait survenu.


Si tous les NAPTR dans un domaine traversé par suite d'une référence dans un NAPTR non terminal ont été éliminés, le client ENUM DEVRAIT continuer son traitement avec le prochain NAPTR dans le RRSet "référant" (c'est-à-dire, celui qui inclut le NAPTR non terminal qui a causé la traversée).


Les clients ENUM DOIVENT être prêts à rencontrer une boucle référentielle dans laquelle une séquence de NAPTR non terminaux est restituée au sein d'une interrogation ENUM qui se réfère à un FQDN antérieur. Les clients ENUM DOIVENT être capables de détecter et récupérer d'une telle boucle, sans échec.


Les clients ENUM PEUVENT considérer une chaîne de plus de cinq NAPTR "non terminaux" traversés dans une seule interrogation ENUM comme une indication qu'une boucle de références s'est produite.


Lorsque un domaine va être pénétré par suite d'une référence dans un NAPTR non terminal, et que le client ENUM a détecté une boucle potentielle de références, le client DEVRAIT éliminer le NAPTR non terminal de son traitement et continuer avec le prochain NAPTR de sa liste. Il NE DEVRAIT PAS faire l'interrogation de DNS indiquée par ce NAPTR non terminal.


6. Considérations relatives à l’IANA


La RFC 2916 puis la RFC 3761 (que remplace le présent document) demandaient à l'IANA de déléguer le domaine E164.ARPA suivant les instructions qui étaient fournies par l'IAB (comme décrit dans la [RFC3245]). Le domaine était délégué conformément à ces instructions (qui sont publiées à <http://www.ripe.net/data-tools/dns/enum/iab-instructions>).


Les noms dans cette zone sont à déléguer à des parties cohérentes avec la Recommandation UIT-T E.164. Les noms alloués devraient être hiérarchisés conformément à la Recommandation UIT-T E.164, et les codes devraient être alloués conformément à cette Recommandation.


L'IAB se coordonnera avec le bureau de la normalisation des télécommunications de l'UIT si le contact technique pour le domaine e164.arpa devait changer, car ce bureau de l'UIT a une relation de travail fonctionnelle avec ce contact technique qui devrait être rétabli.


Voir dans la [RFC6117] les considérations relatives à l'IANA pour Enumservice.


7. Considérations sur la sécurité

7.1 Sécurité du DNS

Comme ENUM utilise le DNS, qui sous sa forme actuelle est un protocole non sûr, il n'y a pas de mécanisme pour assurer que les données qu'on récupère sont authentiques. Comme ENUM est déployé dans l'Internet mondial, on s'attend à ce qu'il soit une cible populaire de toutes sortes d'attaques, et attaquer l'infrastructure DNS sous-jacente est une façon d'attaquer le service ENUM lui-même.


Il y a de multiples types d'attaques qui peuvent se produire contre le DNS que devraient envisager les mises en œuvre de ENUM. Voir dans "Analyse des menaces contre le système des noms de domaines" [RFC3833] un catalogue des diverses menaces pour le DNS.


À cause de ces menaces, un service ENUM déployé DEVRAIT inclure des mécanismes pour les atténuer. La plupart des menaces peuvent se résoudre en vérifiant l'authenticité des données via des mécanismes comme ceux de la sécurité du DNS (DNSSEC) [RFC4033].


D'autres, comme les attaques de déni de service, ne peuvent pas être résolues par l'authentification des données. Il est important de se souvenir que ces menaces n'incluent pas seulement les recherches de NAPTR elles-mêmes, mais aussi les divers enregistrements nécessaires pour que les services soient utiles (par exemple, les enregistrements NS, MX, SRV, et A).


Même si DNSSEC est déployé, il ne peut pas protéger contre toutes les sortes d'attaques contre le DNS. ENUM est souvent utilisé pour des traductions de numéro ou d'adresse ; restituer une adresse par une recherche ENUM avec la prise en charge de DNSSEC n'assure cependant pas que le service soit protégé contre les attaques. Il n'est pas raisonnable de croire aveuglément que le service va restituer une adresse valide et que l'entité à laquelle il connecte en utilisant cette adresse est le service homologue qu'on avait l'intention de contacter. Un service DEVRAIT toujours authentifier l'entité à laquelle il se connecte durant la phase d'établissement du service, et ne pas s'appuyer sur les données d'adresse ou d'identité récupérées en dehors de ce service.


Finalement, comme un service ENUM va mettre en œuvre un certain type de mécanisme de sécurité, le logiciel qui met en œuvre ENUM DOIT être prêt à recevoir des réponses DNSSEC et d'autres réponses de sécurité standard du DNS, incluant de grandes réponses et d'autres signaux EDNS0 (voir la [RFC2671]), des enregistrements de ressource inconnus (voir la [RFC3597]), et ainsi de suite.


7.2 Sécurité de la mise en antémémoire

L'architecture du DNS fait un usage extensif de la mise en antémémoire des enregistrements aux nœuds intermédiaires pour améliorer les performances. Le temps de propagation (pour que les changements d'enregistrements de ressource soient reflétés dans les réponses aux interrogations aux nœuds d'extrémité) approche la valeur de la "durée de vie" de ces enregistrements. Il peut y avoir un certain nombre d'enregistrements de ressources différents qui sont impliqués dans la résolution d'une cible de communication. Des changements à ces enregistrements peuvent n'être pas synchronisés (en particulier si ces enregistrements de ressource indiquent des durées de vie différentes). Donc, un changement dans un de ces enregistrement peut causer des décisions inappropriées sur les cibles de communications. Sachant qu'une mise à jour du DNS (spécifiée dans la [RFC2136]) peut introduire des changements assez rapides du contenu de différentes zones, ces états transitoires peuvent devenir importants.


Considérons un ensemble typique d'interrogations qui suivent une interrogation ENUM qui retourne un URI SIP (pour les détails, voir la [RFC3263]) :

o l'évaluation de l'URI SIP déclanche une interrogation sur la partie domaine SIP pour les NAPTR D2U/D2T ;

o cela déclanche à son tour une interrogation sur le domaine cible de cet enregistrement pour des enregistrements SRV ;

o les enregistrements SRV vont retourner le nom d'hôte du serveur SIP, qui va déclancher une autre interrogation sur ce nom d'hôte sur un enregistrement A pour obtenir l'adresse IP associée au serveur ;

o finalement, le client d'agent d'utilisateur SIP local va tenter d'initier une session de communications à cette adresse IP.


Le NAPTR E2U peut avoir changé son URI, indiquant une nouvelle identité SIP. Le NAPTR D2U pour la partie domaine de l'URI SIP peut avoir changé sa cible. L'enregistrement SRV pointé par ce NAPTR D2U peut avoir changé le nom d'hôte de sa cible. L'enregistrement A peut avoir changé d'adresse IP. Finalement, si le serveur existe dans un environnement où les adresses IP sont allouées de façon dynamique (par exemple, quand on utilise DHCP [RFC2131]), un point d'extrémité inattendu peut avoir été alloué à l'adresse IP retournée de la chaîne de résolution SIP.


Dans des environnements où surviennent des changements à un des éléments de cette chaîne d'enregistrements de ressource ou des allocations dynamiques des adresses IP, les systèmes qui provisionnent ces données DEVRAIENT veiller à minimiser les changements et à considérer les durées de vie respectives des enregistrements de ressource et/ou des temps d'emprunt de DHCP. Les utilisateurs de ces données DEVRAIENT veiller à détecter et récupérer des tentatives non intentionnelles de sessions de communications ; dans un environnement transitoire, cela peut arriver.


7.3 Sécurité de l’acheminement d’appel

Dans un certain nombre de pays (et dans d'autres environnements de numérotation) il y a plusieurs fournisseurs d'acheminement des appels et services de traduction de numéros/noms. Dans ces zones, tout système qui permet aux usagers, ou aux agents possibles pour les usagers, de changer l'acheminement ou si les informations du fournisseur peuvent inciter à des changements qui en fait ne sont pas autorisés (et dans certains cas, à des refus de demandes de changements légitimes). De tels environnements devraient être désignés avec des mécanismes adéquats pour l'identification et l'authentification de ceux qui demandent les changements et pour l'autorisation de ces changements.


7.4 Sécurité de la résolution d’URI

Une grande quantité de questions de sécurité ont à voir avec le processus de résolution lui-même, et l'utilisation des URI produits par le mécanisme de DDDS. Elles doivent être spécifiées dans l'enregistrement de l'Enumservice utilisé, comme spécifié dans "Enregistrement par l’IANA des services Enum : Guide, Gabarit, et considérations relatives à l’IANA" [RFC6117].


8. Remerciements


Le présent document est une mise à jour de la RFC 3761, qui a été éditée par Patrik Faltstrom et Michael Mealling. Prière de se reporter à la section Remerciements de cette RFC pour les autres remerciements. Les auteurs tiennent aussi à remercier Alfred Hoenes et Bernie Hoeneisen de leurs relectures détaillées.


9. Changements par rapport à la RFC3761


Un paragraphe a été ajouté pour expliquer la façon dont DDDS est utilisé avec la présente spécification. Ces recommandations ont été collectées de l'expérience du déploiement de ENUM. Les différences d'interprétation des spécifications de DDDS ont conduit à des problèmes d'interopérabilité ; le présent document met à jour la RFC3761 pour ajouter de nombreux éclaircissements, destinés à améliorer l'interopérabilité.


Les éclaircissements incluent une valeur par défaut pour le champ ORDER et pour le caractère délimiteur Regexp, l'utilisation exigée du champ Replacement dans les NAPTR non terminaux, et que la correspondance de chaîne est sensible à la casse (paragraphe 3.6).


Les autres changements de substance incluent de supprimer la discussion des mécanismes d'enregistrement, (maintenant spécifiés dans "Enregistrement par l’IANA des services Enum : Guide, Gabarit, et considérations relatives à l’IANA" [RFC6117]) qui corrige une erreur existante en ajoutant "-" comme caractère valide dans les champs type et sous type spécifiés dans les paramètres des services (paragraphe 3.4.3) et en ajoutant le type de service privé "P-" (paragraphe 3.4.3.1).


10. Références

10.1 Références normatives

[E.164] Recommandation UIT-T E.164, "Plan de numérotation des télécommunications publiques internationales", Union Internationale des Télécommunications, Genève, février 2005.


[RFC1034] P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987.


[RFC1035] P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par la RFC6604)


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


[RFC3402] M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie II : l'algorithme", octobre 2002. (P.S.)

[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.)


[RFC3404] M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie IV : Identifiants de ressource uniformes (URI)", octobre 2002. (P.S.)


[RFC3492] A. Costello, "Punycode : Codage Bootstring d'Unicode pour les noms de domaine internationalisés dans les applications (IDNA)", mars 2003. (P.S.)


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


[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)


[RFC3986] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005.


[RFC3987] M. Duerst et M. Suignard, "Identifiant de ressource internationalisé (IRI)", janvier 2005.


[RFC5234] D. Crocker, éd., P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)


10.2 Références pour information

[RFC2131] R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS) (Mà J par RFC3396, RFC4361, RFC5494, et RFC6849)


[RFC2136] P. Vixie, S. Thomson, Y. Rekhter et J. Bound, "Mises à jour dynamiques dans le système de noms de domaine (DNS UPDATE)", avril 1997.


[RFC2671] P. Vixie, "Mécanismes d'extension pour le DNS (EDNS0)", août 1999. (P.S.) (Remplacée par RFC6891)


[RFC2782] A. Gulbrandsen, P. Vixie et L. Esibov, "Enregistrement de ressource DNS pour la spécification de la localisation des services (DNS SRV)", février 2000.


[RFC2915] M. Mealling, R. Daniel, "Enregistrement de ressource DNS Pointeur d'autorité de dénomination (NAPTR)", septembre 2000. (Obsolète, voir RFC3401, RFC3402, RFC3403, RFC3404) (P.S.)


[RFC2916] P. Faltstrom, "Numéros E.164 et DNS", septembre 2000. (Obsolète, voir RFC3761) (P.S.)


[RFC3245] J. Klensin, éd., IAB, "Histoire et contexte de décisions opérationnelles de transposition des numéros de téléphone (ENUM) : Documents d'information fournis à la Commission 2 de l'UIT-T (SG2)", mars 2002. (Information)


[RFC3263] J. Rosenberg, H. Schulzrinne, "Protocole d'initialisation de session (SIP) : Localisation des serveurs SIP", juin 2002. (Remplace RFC2543) (P.S.)


[RFC3401] M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie I : DDDS complet", octobre 2002. (Info.)


[RFC3597] A. Gustafsson, "Traitement des types inconnus d'enregistrement de ressource du DNS ", septembre 2003. (P.S.)


[RFC3824] J. Peterson et autres, "Utilisation de numéros E.164 avec le protocole d'initialisation de session (SIP)", juin 2004. (Info.)


[RFC3833] D. Atkins, R. Austein, "Analyse des menaces contre le système des noms de domaines (DNS)", août 2004. (Information)


[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey et S. Rose, "Introduction et exigences pour la sécurité du DNS", mars 2005.


[RFC5483] L. Conroy, K. Fujiwara, "Problèmes et expériences de mises en œuvre de ENUM", mars 2009. (Information)


[RFC6117] B. Hoeneisen, A. Mayrhofer, J. Livingood "Enregistrement par l’IANA des services Enum : Guide, Gabarit, et considérations relatives à l’IANA", mars 2011. (Remplace RFC3761) (P.S.)


Adresse des auteurs


Scott Bradner

Lawrence Conroy

Kazunori Fujiwara

Harvard University

Roke Manor Research

Japan Registry Services Co., Ltd.

29 Oxford St.

Roke Manor

Chiyoda First Bldg. East 13F

Cambridge MA 02138

Old Salisbury Lane

3-8-1 Nishi-Kanda Chiyoda-ku

USA

Romsey

Tokyo 101-0165

téléphone : +1-617-495-3864

United Kingdom

JAPAN

mél : sob@harvard.edu

téléphone : +44-1794-833666

mél : fujiwara@jprs.co.jp


mél : lconroy@insensate.co.uk

URI: http://jprs.jp/en/


URI : http://lawrence.tel