Groupe de travail Réseau	L. Daigle, Cisco Systems
Request for Comments : 4848	
Catégorie : Sur la voie de la normalisation	avril 2007
Traduction Claude Brière de L'Isle	

Localisation de service d'application fondé sur le domaine avec les URI et le service dynamique de découverte de délégation (DDDS)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de 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 IETF Trust (2007).

Résumé
L'objet du présent document est de définir une nouvelle application, directe, de service de découverte de délégation dynamique (DDDS, Dynamic Delegation Discovery Service) pour permettre la transposition des noms de domaines en URI pour les services et protocoles d'application particuliers. Bien que définie comme une nouvelle application DDDS, appelée U-NAPTR, c'est effectivement une extension de l'application DDS de pointeur d'autorité de dénomination (NAPTR, Naming Authority PoinTeR) direct (S-NAPTR, Straightforward NAPTR).
Table des matières
1. Introduction	1
2. NAPTR direct à capacité d'URI (U-NAPTR)	2
2.1 Fanions permis	2
2.2 Expressions régulières permises	2
3. Échantillon d'enregistrements U-NAPTR du DNS	2
4. Définition formelle de l'application U-NAPTR de DDDS	3
4.1 Chaîne unique d'application	3
4.2 Première règle bien connue	3
4.3 Résultat attendu	3
4.4 Fanions	3
4.5 Paramètres de service	3
4.6 Règles valides	4
4.7 Bases de données valides	4
5. Considérations relatives à l'IANA	4
6. Considérations sur la sécurité	5
7. Remerciements	5
8. Références	5
8.1 Références normatives	5
8.2 Références pour information	5
Adresse de l'auteur	6
Déclaration complète de droits de reproduction	6

 	1.	Introduction

L'objet du présent document est de définir une nouvelle application directe de service de découverte dynamique de délégation (DDDS, Dynamic Delegation Discovery Service) [RFC3401] pour permettre la transposition des noms de domaines en URI pour des services et protocoles d'application particuliers. Cela permet, par exemple, la "recherche" de services particuliers disponibles pour certains domaines.

Bien que cela définisse une nouvelle application DDDS séparée, nommée U-NAPTR, elle est construite à partir des mêmes principes que l'application NAPTR direct (S-NAPTR, Straightforward NAPTR) spécifiée dans la [RFC3958]. La présente spécification n'est pas une mise à jour de S-NAPTR, mais le lecteur est invité à revoir ce document pour une couverture extensive des motifs et des considérations de mise en œuvre.

S-NAPTR assure la localisation de service d'application qui ne repose pas sur des conventions rigides de dénomination de domaine. Il est réputé "direct" en partie parce que il exclut l'utilisation des expressions régulières dans les enregistrements NAPTR (pour l'application de DDDS S-NAPTR). Cependant, cela exclut aussi la possibilité de fournir un URI comme cible de résolution de DDDS. Un certain nombre d'applications, spécifiées (par exemple, la [RFC4095]) et proposées, trouvent cette restriction trop limitative, rendant S-NAPTR inapplicable pour satisfaire leurs besoins.

Cet U-NAPTR est effectivement une modeste extension à S-NAPTR, pour s'accommoder de l'utilisation des URI comme cibles, sans permettre la gamme complète des possibles expressions régulières dans les enregistrements NAPTR.

 	2.	NAPTR direct à capacité d'URI (U-NAPTR)

Le présent document suppose que le lecteur est familiarisé avec la spécification de S-NAPTR [RFC3958]. L'intention de U-NAPTR est de fournir tout ce que fournit S-NAPTR, sauf qu'il permet l'utilisation du fanion "U" dans l'enregistrement NAPTR, et une forme spécifique de REGEXP.

 	2.1	Fanions permis
U-NAPTR permet les mêmes fanions que S-NAPTR ("S", "A", ou vide) plus le fanion "U". Pour l'application DDDS de U-NAPTR, la présence du fanion "U" dans l'enregistrement NAPTR indique que le champ REGEXP doit être rempli (et, par conséquent, que le champ REPLACEMENT est vide). L'expression régulière dans le champ REGEXP doit être de la forme limitée décrite ci-dessous, et le résultat de l'évaluation de l'expression régulière va être un URI qui est le résultat de la résolution du DDDS.

 	2.2	Expressions régulières permises
U-NAPTR permet des expressions régulières d'une forme qui fait un remplacement complet de la chaîne correspondante par un URI, exprimé par une chaîne constante. Ceci est essentiellement un truc pour contourner le fait que le champ REPLACEMENT dans un NAPTR est obligé de produire seulement un nom de domaine pleinement qualifié (et, donc, ne peut pas être utilisé pour un URI).

La syntaxe spécifique permise pour les expressions régulières U-NAPTR est :

u-naptr-regexp = "!.*!"<URI>"!"

où <URI> est comme défini dans le STD 66 [RFC3986], la spécification de la syntaxe d'URI.

Avec cette forme limitée d'expression régulière, les applications qui utilisent U-NAPTR n'ont pas besoin de mettre en œuvre des analyseurs d'expression régulière complète.

 	3.	Échantillon d'enregistrements U-NAPTR du DNS

Dans l'échantillon d'enregistrement de ressource NAPTR pour exemple.com montré ci-dessous, "WP" est l'étiquette de service d'application imaginée pour "pages blanches", et "EM" est l'étiquette de service d'application pour un service d'application "Messagerie Extensible" imaginaire.

exemple.com.
;;      fanions d'ordre de préférence
IN NAPTR 100   10   ""    "WP:whois++"      ( ; service
                             ""                  ; regexp
                             bunyip.exemple.com. ; remplacement
                                               )
IN NAPTR 100   20   "s"   "WP:ldap"         ( ; service
                          ""                  ; regexp
                         _ldap._tcp.monldap.exemple.com. ; remplacement
                                            )
IN NAPTR 200   10   "u"    "EM:protA"        ( ; service
                          "!.*!prota://unfai.exemple.com!" ; regexp
                          ""                  ; remplacement
                                            )
IN NAPTR 200   30   "a"   "EM:protB"          ; service
                          ""                  ; regexp
                          monprotB.exemple.com.; remplacement
                                            )

 	4.	Définition formelle de l'application U-NAPTR de DDDS

Cette Section définit formellement l'application DDDS, comme décrite dans la [RFC3401].

 	4.1	Chaîne unique d'application
La chaîne unique d'application est un nom de domaine pleinement qualifié (FQDN) pour lequel un serveur d'autorité est recherché pour un service particulier.

 	4.2	Première règle bien connue
La "première règle bien connue" est identité – c'est-à-dire que le résultat de la règle est la chaîne unique d'application, le FQDN pour lequel le serveur d'autorité est recherché pour un service particulier.

 	4.3	Résultat attendu
Le résultat attendu de cette application sont les informations nécessaires pour se connecter à un ou des serveurs d'autorité (hôte, accès, protocole, ou URI) pour un service d'application dans un certain domaine.

 	4.4	Fanions
Cette application DDDS utilise seulement trois des fanions définis pour l'application de résolution d'URI/URN dans la [RFC3404] : "S", "A", et "U". Aucun autre fanion n'est valide. Si un client obtient un RR NAPTR pour une application utilisant U-NAPTR qui contient tout autre fanion, ce RR NAPTR devrait être ignoré et le traitement devrait se continuer avec le prochain enregistrement (si il en est).

Ces fanions sont pour les recherches terminales. Cela signifie que la règle est que c'est le dernier et que le fanion détermine ce que l'étape suivante devrait être. Le fanion "S" signifie que le résultat de cette règle est un FQDN pour lequel un ou plusieurs enregistrements SRV [RFC2782] existent. Un "A" signifie que le résultat de la règle est un nom de domaine et devrait être utilisé pour chercher des enregistrements d'adresse pour ce domaine. Un "U" signifie que le résultat de la règle est un URI qui devrait être résolu afin d'obtenir l'accès au service décrit.

En cohérence avec l'algorithme de DDDS, si la chaîne de fanions est vide, la prochaine recherche est pour un autre enregistrement NAPTR (pour la cible de remplacement).

 	4.5	Paramètres de service
Les paramètres de service pour cette application prennent la forme d'une chaîne de caractères qui suit l'ABNF [RFC4234] suivant :

service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E  ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; les étiquettes app-service et app-protocol sont limitées à 32 caractères et doivent commencer par un caractère alphabétique. Les paramètres de service sont considérés comme insensibles à la casse.

Donc, les paramètres de service peuvent consister en une chaîne vide, tout comme app-service, ou un app-service avec une ou plusieurs spécifications app-protocol séparées par le symbole ":".

Noter que ceci est similaire à, mais pas le même que, la syntaxe utilisée dans l'application DDDS d'URI [RFC3404]. La base de données DDDS du DNS exige que chaque application DDDS définisse la syntaxe des chaînes de service admises. La syntaxe est ici étendue pour permettre des caractères qui sont valides dans tout nom de schéma d'URI (voir la [RFC3986]). Comme "+" (le séparateur utilisé dans la chaîne de paramètre de service de la RFC3404) est un caractère admis pour les noms de schéma d'URI, ":" est choisi ici comme séparateur.

 	4.5.1	Services d'application
Le "app-service" doit être un service enregistré par l'IANA ; voir à la Section 5 les instructions sur l'enregistrement de nouvelles étiquettes de service d'application.

 	4.5.2	Protocoles d'application
Les identifiants de protocole qui sont valides pour la production "app-protocol" sont des protocoles standard, enregistrés ; voir à la Section 5 les instructions sur l'enregistrement de nouvelles étiquettes de protocole d'application.

 	4.6	Règles valides
Les règles permises sont des règles de substitution et d'expressions régulières de la syntaxe suivante (c'est-à-dire, une expression régulière pour remplacer le nom de domaine par un URI) :

u-naptr-regexp = "!.*!"<URI>"!"

où <URI> est comme défini dans le STD 66 [RFC3986], la spécification de la syntaxe d'URI.

 	4.7	Bases de données valides
À présent, une seule base de données DDDS est spécifiée pour cette application. La [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éécritrure. Les clés pour cette base de données sont codées comme des noms de domaines.

La première règle bien connue produit un nom de domaine, et c'est la clé qui est utilisée pour la première recherche -- les enregistrements NAPTR pour le domaine qui est demandé.

Les serveurs DNS PEUVENT interpréter les valeurs de fanions et utiliser cette information pour inclure les enregistrements NAPTR, SRV, ou A appropriés dans la portion Informations supplémentaires du paquet DNS. Les clients sont invités à vérifier les informations supplémentaires mais ne sont pas obligés de le faire. Voir la section Traitement des informations supplémentaires de la [RFC3403] pour plus d'informations sur les enregistrements NAPTR et la section Informations supplémentaires d'un paquet de réponse du DNS.

 	5.	Considérations relatives à l'IANA

Le présent document ne pose par lui-même aucune exigence pour l'IANA, mais fournit la base sur laquelle les services qui utilisent U-NAPTR peuvent faire usage des registres existants de l'IANA pour les étiquettes de service d'application et les étiquettes de protocole d'application (définies dans la [RFC3958]).

Comme c'est le cas pour S-NAPTR, toutes les étiquettes de service et protocoles d'application qui commencent par "x-" sont considérées comme expérimentales, et aucune disposition n'est prise pour empêcher une utilisation dupliquée de la même chaîne. On les utilise à ses propres risques.

Toutes les autres étiquettes de service et protocoles d'application sont enregistrées sur la base de l'option "spécification exigée" définie dans la [RFC2434], avec la stipulation supplémentaire que "spécification" est une RFC (de n'importe quelle catégorie).

Il n'y a pas d'autre restriction sur les étiquettes que elles doivent se conformer à la syntaxe définie ci-dessus (au paragraphe 4.5).

La RFC de définition doit clairement identifier et décrire, pour chaque étiquette enregistrée :
o	le protocole d'application ou l'étiquette de service,
o	l'usage prévu,
o	les considérations d'interopérabilité,
o	les considérations de sécurité (voir à la Section 6 de ce document une discussion plus apporfondie des types de considérations qui sont applicables)
o	toutes les publications en rapport pertinentes

La RFC de définition peut aussi inclure des restrictions spécifiques de l'application supplémentaires, comme des limitations sur les types d'URI qui peuvent être retournés pour le service d'application.

 	6.	Considérations sur la sécurité

U-NAPTR a les mêmes considérations de sécurité que S-NAPTR ; voir la Section 8 de la [RFC3958]. U-NAPTR a de plus à considérer que la résolution des URI (à partir du résultat de la résolution DDDS) a son propre ensemble d'implications de sécurité, couvertes dans la spécification d'URI (en particulier, la Section 7 de la [RFC3986]). Par nature, avec l'utilisation de DNSSEC, le logiciel client peut avoir confiance que l'URI obtenu en utilisant U-NAPTR est bien celui spécifié par l'administrateur du domaine d'où il a été restitué; mais la validité du service atteint en résolvant cet URI est une affaire de pratiques de sécurité de résolution d'URI.

 	7.	Remerciements

Merci à Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, Dan Romascanu, Suresh Krishnan, et Lars Eggert pour leur relecture des versions antérieures et leur capture des erreurs !

 	8.	Références
 	8.1	Références normatives

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

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

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

[RFC3958]	L. Daigle, A. Newton, "Localisation de service d'application fondée sur le domaine avec les enregistrements de ressource de SRV et le service de recherche dynamique de délégation (DDDS)", janvier 2005. (P.S.)

[RFC4234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplace RFC2234, remplacée par RFC5234)

 	8.2	Références pour information

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

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

[RFC4095]	C. Malamud, "Découvrir la signification des mots clés de classe de sollicitation", mai 2005. (P.S.)

 	Adresse de l'auteur

Leslie L. Daigle
Cisco Systems
13615 Dulles Technology Drive
Herndon, VA  20171
US

mél : ledaigle@cisco.com ; leslie@thinkingcat.com 

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

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

Le présent document et les informations contenues sont fournis 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, le IETF TRUST 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 encloses ne viole 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 pourraient ê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 le 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.