Network Working Group M

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

Le présent document définit un schéma d’URI, 'go:' à utiliser avec le protocole de résolution de nom courant. Il établit précisément les composants syntaxiques et la façon dont ces composants sont utilisés par la résolution d’URI pour trouver les transports disponibles pour un service CNRP. Il faut faire attention avec plusieurs des composants d’URI parce que, bien qu’ils puissent ressembler à ceux qui se trouvent dans d’autres schémas d’URI, ils n’agissent souvent pas comme eux. Le schéma "go :" a plus en commun avec le schéma indépendant de la localisation "news" qu’avec tout autre schéma d’URI.

Table des Matières

1. Objectifs 1

2. Terminologie 2

3. Règles de syntaxe 2

3.1 Syntaxe générale 2

3.2 Grammaire de l’ABNF 2

3.3 Cas particuliers et valeurs par défaut 2

4. Indépendance au transport 3

5. Exemples 3

6. Considérations sur la sécurité 3

7. Considérations relatives à l’IANA 4

Références 4

Appendice A. Gabarit d’enregistrement 4

Adresse de l’auteur 4

Déclaration complète de droits de reproduction 4

Les deux objectifs de l’URI [RFC2396] CNRP [RFC3367] sont d’identifier à la fois un enregistrement de nom courant spécifique chez un serveur spécifique et d’identifier une interrogation éventuellement dynamique ou un point d’entrée dans le processus d’interrogation. Comme CNRP exige que l’identifiant soit un terme d’interrogation central, ces deux cas peuvent être généralisés en spécifiant simplement une interrogation qui contienne seulement l’identifiant de l’élément.

À première vue, il semblerait un exercise assez simple de canoniser l’interrogation codée en XML et de l’insérer ensuite dans la portion interrogation de l’URL. Le problème est que, à cause des règles de codage, toute interrogation complexe à distance va rapidement pulvériser les limitations de longueur d’URI. La solution suggérée est de fournir une syntaxe d’interrogation simplifiée qui soit un sous ensemble de ce qui est disponible via le XML.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

L’URI CNRP se présente sous deux formes. La première forme est pour parler à un serveur spécifique. La seconde forme est pour exprimer une interrogation qui est destinée à être envoyée à plusieurs services CNRP différents. Les deux exemples suivants ne servent qu’à des fins pédagogiques. La grammaire ABNF complète du paragraphe 3.2 est la seule définition de syntaxe qui fasse autorité.

Voici l’ABNF [RFC2234] complet (certaines valeurs sont incluses par référence à la [RFC2396]) :

hex = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f"

Dans le cas où l’URI CNRP ne contient que la production du serveur, l’URI identifie alors un certain serveur CNRP, et non une interrogation particulière qui serait à faire. Un client peut supposer que ce serveur va au moins répondre à la demande 'servicequery' (interrogation de service).

Si l’élément 'serveur' n’a pas de valeur, sa valeur DOIT alors être supposée être "localhost" (hôte local).

L’accès de transport HTTP bien connu de CNRP est 1096. Si la portion valeur d’accès de la production du serveur n’est pas spécifiée, alors l’accès 1096 DEVRAIT être utilisé si le client n’a pas connaissance à l’avance d’autres accès ou transports que le service pourrait prendre en charge.

Les valeurs de nom courant, de paramètres d’interrogation, et de valeurs de paramètres doivent être codées en utilisant le schéma de codage UTF-8 [Unicode], et tout octet qui n’est pas de l’ensemble des caractères permis selon la grammaire ci-dessus DOIT plutôt être représenté par un "%" suivi par deux caractères de l’ensemble de caractères <hex> ci-dessus. Les deux caractères donnent la représentation hexadécimale de cet octet.

Comme établi dans la spécification du protocole CNRP [RFC3367], CNRP peut être exprimé sur plusieurs protocoles de transport avec HTTP de mise en œuvre obligatoire. Dans le cas où un client tenterait de résoudre un URI CNRP et qu’il ne sache rien du service référencé dans cet URI, il DEVRAIT alors utiliser HTTP sur l’accès CNRP par défaut (1096).

Cet exemple montre une interrogation générale sur le nom courant "Mercedes Benz". L’intention est que l’interrogation puisse être conditionnée par défaut par tout client et envoyée au service, ou à plusieurs d’entre eux, que le client est configuré à interroger.

Cet exemple montre une interrogation générale sur le nom courant "Mercedes Benz" qui est envoyée au serveur qui fonctionne sur l’hôte local.

Cet exemple montre une interrogation sur le nom courant "Mercedes Benz" dans la zone géographique "US-ga" qui devrait être envoyée au serveur qui se trouve à cnrp.foo.com.

Cet exemple comporte un caractère UTF-8 codé en utilisant l’échappement hexadécimal. La valeur codée est un u-umlaut (un 'u' avec un tréma). Cette simple interrogation est envoyée au serveur qui se trouve à cnrp.foo.org sans paramètre.

Ici, seul un identifiant est donné, ce qui signifie que cet exemple pointe directement sur un enregistrement de nom courant particulier sur un certain serveur. Cet exemple se trouverait probablement dans un lien sur un certain type de page de la Toile.

En plus des considérations sur la sécurité inhérentes à CNRP lui-même (voir la Section Considérations sur la sécurité de la [RFC3367]) le mécanisme d’URI peut aussi être utilisé pour restituer un URI qui identifie un autre site en incluant juste l’identifiant et non le nom courant qui lui est lié. C’est-à-dire que l’usager peut penser qu’on lui montre l’URI actuellement transposé en le nom courant "BMW" mais dans le cas où seul l’identifiant est utilié, le nom courant réel ne fait pas partie de l’URI, ce qui rend donc possible d’utiliser un URI CNRP sans savoir à quel nom courant il se réfère.

Il est demandé à l’IANA d’enregistrer le gabarit d’enregistrement d’URL qui se trouve à l’Appendice A conformément à la [RFC2717].

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

[RFC2396] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998. (Obsolète, voir RFC3986)

[RFC2717] R. Petke, I. King, "Procédures d'enregistrement des noms de schéma d'URL", novembre 1999. (Obsolète, voir RFC4395) (BCP0035))

[Unicode] The Unicode Consortium, "The Unicode Standard, Version 2.0: Appendix A.2", ISBN 0-201-48345-9, janvier 1988.

Considérations d’interopérabilité : Aucune qui ne soit spécifiée dans la [RFC3367]

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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.

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

Groupe de travail Réseau	M. Mealling, VeriSign, Inc.
Request for Comments : 3368
Catégorie : En cours de normalisation	août 2002
Traduction Claude Brière de L’Isle