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

D. Thaler, éd., Microsoft

Request for Comments : 7595

T. Hansen, AT&T Laboratories

BCP : 35

T. Hardie, Google

RFC rendue obsolète : 4395


Catégorie : Bonnes pratiques actuelles

juin 2015

ISSN : 2070-1721

Traduction Claude Brière de L’Isle



Lignes directrices et procédures d'enregistrement pour les schémas d'URI



Résumé

Le présent document met à jour les lignes directrices et les recommandations, ainsi que le processus d'enregistrement par l'IANA, pour la définition des schémas d'identifiants de ressource universels (URI, Unform Resource Identifier). Il rend obsolète la RFC 4395.


Statut de ce mémoire

Le présent mémoire documente les bonnes pratiques actuelles de l'Internet.


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 subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Plus d’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, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc7595


Notice de droits de reproduction

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


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


Table des Matières

1. Introduction

1.1 URI et IRI

2. Terminologie

3. Exigences pour les définitions de schéma permanent

3.1 Utilité démontrable, nouvelle, de long terme

3.2 Compatibilité syntaxique

3.3 Bien défini

3.4 Définition du fonctionnement

3.5 Contexte d'utilisation

3.6 Internationalisation et codage de caractères

3.7 Considérations claires de sécurité et confidentialité

3.8 Considérations de schéma de nommage

3.9 Considérations d'interopérabilité

4. Lignes directrices pour l'enregistrement provisoire de schémas d'URI

5. Lignes directrices pour l'enregistrement de schéma d'URI historique

6. Lignes directrices pour l'utilisation de schéma d'URI privé

7. Procédure d'enregistrement de schéma d'URI

7.1 Généralités

7.2 Procédures d'enregistrement

7.3 Contrôle des changements

7.4 Modèle d'enregistrement de schéma d'URI

8. Schéma d'URI "exemple"

8.1 Demande d'enregistrement du schéma d'URI "exemple"

9. Considérations relatives à l'IANA

10. Considérations sur la sécurité

11. Références

11.1 Références normatives

11.2 Références pour information

Remerciements

Contributeurs

Adresse des auteurs


1. Introduction


L'élément de protocole "identifiant de ressource universel" (URI, Uniform Resource Identifier) et sa syntaxe générique sont définis par la [RFC3986]. Chaque URI commence par un nom de schéma, comme défini au paragraphe 3.1 de la RFC3986, qui se réfère à une spécification pour les identifiants au sein de ce schéma. La syntaxe d'URI fournit un système fédérateur et extensible de désignation, où la spécification de chaque schéma peut restreindre la syntaxe et définir la sémantique des identifiants qui utilisent ce schéma.


Le présent document rend obsolète la [RFC4395], qui rendait obsolètes les [RFC2717] et [RFC2718]. Des documents récents ont utilisé le terme "URI" pour tous les identifiants de ressource, évitant le terme "URL" et réservant explicitement le terme "URN" pour les URI qui utilisent le nom de schéma "urn" [RFC2141]. Les "espaces de noms" URN [RFC3406] sont spécifiques du schéma "urn" et ne sont explicitement par couverts par la présente spécification.


Le présent document met à jour les directives pour la définition de nouveaux schémas, à prendre en considération par ceux qui définissent, enregistrent, ou évaluent ces définitions. De plus, le présent document met à jour le processus et le mécanisme des schémas d'enregistrement au sein du registre des schémas d'URI de l'IANA. Il y a un seul espace de noms pour les schémas enregistrés. L'intention du registre est :

o de fournir un point central de découverte pour les noms de schémas d'URI établis et une localisation facile des documents de définition des schémas ;

o d'empêcher des utilisations séparées du même nom de schéma ;

o d'aider ceux qui proposent de nouveaux noms de schéma à discerner les tendances et conventions établies et d'éviter des noms qui pourraient être confondus avec ceux existants ; et

o d'encourager l'enregistrement en mettant les barrières à l'enregistrement à un faible niveau.


1.1 URI et IRI

Comme ils étaient définis à l'origine, les URI permettaient seulement un répertoire de caractères limité choisi dans l'US-ASCII. Un identifiant de ressource internationalisé (IRI, Internationalized Resource Identifier) défini pas la [RFC3987], étend la syntaxe d'URI pour permettre des caractères provenant d'un répertoire beaucoup plus large pour s'accommoder des identifiants de ressource des différentes langues du monde. La [RFC3987] définit aussi une transposition entre URI et IRI. Les IRI utilisent les mêmes noms de schéma que les URI. Donc, il n'y a pas de registre indépendant ou de processus d'enregistrement séparé pour les schémas d'IRI : le registre des schémas d'URI est utilisé pour les URI et les IRI. Ceux qui souhaitent décrire des identifiants de ressource qui sont utiles comme IRI devraient définir la syntaxe d'URI correspondante et noter que l'usage de l'IRI suit les règles et transformations définies dans la [RFC3987].


2. Terminologie


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


Le présent document fait une distinction entre une "spécification de schéma", qui est un document définissant la syntaxe et la sémantique d'un schéma, et une "demande d'enregistrement de schéma", qui est le formulaire complet soumis à l'IANA. Le terme "définition de schéma" se réfère de façon générique à la syntaxe et la sémantique d'un schéma et est normalement documenté dans une spécification de schéma.


3. Exigences pour les définitions de schéma permanent


La présente section présente les nouveaux schémas. La conformité à ces lignes directrices est EXIGÉE pour l'enregistrement des schémas "permanents". Le statut de "permanent" est approprié, mais ne se limite pas, à l'utilisation dans les normes. Pour les schémas d'URI définis ou référencés normativement par les documents sur la voie de la normalisation de l'IETF, le statut d'enregistrement "permanent" est EXIGÉ.


La [RFC3986] définit la syntaxe globale des URI comme :


URI = schéma ":" partie-hiérarchique [ "?" interrogation ] [ "#" fragment ]


Une définition de schéma ne peut pas outrepasser la syntaxe globale des URI. Par exemple, cela signifie que les identifiants de fragment ne peuvent pas être réutilisés en dehors des restrictions de syntaxe générique et que les identifiants de fragment ne sont pas spécifiques d'un schéma. Une définition de schéma doit spécifier le nom de schéma et la syntaxe de la partie spécifique du schéma, qui est précisée comme suit :


URI = schéma ":" partie-spécifique-de-schéma [ "#" fragment ]


partie-spécifique-de-schéma = partie-hiérarchique [ "?" interrogation ]


3.1 Utilité démontrable, nouvelle, de long terme

En général, l'utilisation et le déploiement de nouveaux schémas dans l'infrastructure de l'Internet peuvent être coûteux ; certaines parties du traitement d'URI dépendent souvent du schéma. Introduire un nouveau schéma peut exiger un logiciel supplémentaire non seulement pour le logiciel client et les agents d'utilisateur mais aussi dans des parties supplémentaires de l'infrastructure réseau (passerelles, mandataires, mémoires tampon) [WebArch]. Comme les noms de schéma partagent un seul espace de noms mondial, il est souhaitable d'éviter des conflits sur l'utilisation de noms de schéma courts, faciles à mémoriser. Les nouveaux schémas devraient avoir leur utilité pour la communauté de l'Internet au delà de celle dont disposent les schémas déjà enregistrés. La spécification de schéma DEVRAIT discuter de l'utilité du schéma à enregistrer.


3.2 Compatibilité syntaxique

La [RFC3986] définit la syntaxe générique pour tous les schémas d'URI, ainsi que la syntaxe des composants d'URI communs qui sont utilisés par de nombreux schémas d'URI pour définir les identifiants hiérarchiques. La [RFC3987] étendait cette syntaxe générique pour couvrir les IRI. Toutes les spécifications de schéma DOIVENT définir leur propre syntaxe de la <partie-spécifique-de-schéma> d'URI. Il faut veiller à s'assurer que toutes les chaînes correspondant à la syntaxe spécifique de leur schéma vont aussi correspondre à la grammaire de <URI-absolu> décrite dans la [RFC3986].


Les nouveaux schémas DEVRAIENT réutiliser les composants d'URI communs de la [RFC3986] pour la définition des schémas hiérarchiques de désignation. Si il a de fortes raisons pour qu'un schéma n'utilise pas la syntaxe hiérarchique, la définition du nouveau schéma DEVRAIT alors suivre la syntaxe de schémas similaires enregistrés précédemment.


Les schémas qui ne sont pas destinés à être utilisés avec des URI relatifs DEVRAIENT éviter d'utiliser le caractère barre oblique "/" afin d'éviter un traitement non voulu, comme la résolution de "." et.." (segments de points).


Les schémas DEVRAIENT éviter une utilisation inappropriée de "//". L'utilisation des doubles barres obliques dans la première partie d'un URI n'est un indicateur de style que ce qui suit est un URI : les doubles barres obliques sont destinées à être utilisées SEULEMENT lorsque la syntaxe de la <partie-spécifique-du-schéma> contient une structure hiérarchique. Dans les URI qui relèvent de tels schémas, l'utilisation des doubles barres obliques indique que ce qui suit est l'élément hiérarchique supérieur pour une autorité de désignation (le paragraphe 3.2 de la RFC3986 contient plus de détails). Les schémas qui ne contiennent pas une structure hiérarchique conforme dans leur <partie-spécifique-du-schéma> NE DEVRAIENT PAS utiliser les doubles barres obliques à la suite de la chaîne "<scheme>:".


Les nouveaux schémas DEVRAIENT définir clairement le rôle des caractères réservés (voir le paragraphe 2.2 de la [RFC3986]) dans les URI du schéma a définir. La syntaxe du nouveau schéma devrait être claire sur quels caractères "réservés" du jeu de caractères sont utilisés comme délimiteurs au sein des URI du nouveau schéma, et quand ces caractères doivent être esquivés, par rapport à quand ils peuvent être utilisés sans esquive.


3.3 Bien défini

Bien que, en pratique, les URI puissent être ou non définis comme localisateurs, une définition de schéma DOIT, par elle-même être claire sur la façon dont elle est supposée fonctionner. Les schémas qui ne sont pas destinés à être utilisés comme localisateurs DEVRAIENT décrire comment la ressource identifiée peut être déterminée ou accédée par le logiciel qui obtient un URI de ce schéma.


Pour les schémas qui fonctionnent comme des localisateurs, il est important que le mécanisme de localisation de ressource soit clairement défini. Cela peut signifier des choses différentes selon la nature du schéma.


Dans de nombreux cas, les nouveaux schémas sont définis comme des moyens de faire la traduction entre d'autres espaces de noms ou protocoles et le cadre général des URI. Par exemple, le schéma "ftp" traduit dans le protocole FTP tandis que le schéma "mid" traduit en un identifiant Message-ID d'un message électronique. Pour de tels schémas, la description de la transposition DEVRAIT être complète et en détails suffisants pour que la transposition soit claire dans les deux directions : comment transposer un URI en identifiant ou un ensemble d'actions de protocole ou un nom dans l'espace de noms cible, et comment les valeurs légales dans l'espace de noms de base, ou les interactions de protocole légales, sont représentées dans un URI valide. Voir au paragraphe 3.6 les lignes directrices sur le codages des chaînes ou séquences d'octets au sein de séquences de caractères valides dans un URI. Si toutes les valeurs ou interactions de protocole légales de la norme de base ne peuvent pas être représentées en utilisant le schéma, la définition DEVRAIT être claire sur quel sous ensemble et permis et pourquoi.


3.4 Définition du fonctionnement

Au titre de la définition de la façon dont un URI identifie une ressource, une définition de schéma DEVRAIT définir l'ensemble d'opérations applicables qui peuvent être effectuées sur une ressource en utilisant l'URI comme identifiant. Les méthodes HTTP en sont le modèle ; une ressource HTTP peut être traitée par une méthode GET, POST, PUT, et un certain nombre d'autres disponibles par le protocole HTTP. La définition de schéma DEVRAIT décrire toutes les opérations bien définies sur l'identifiant de ressource et ce qu'elles sont supposées faire.


Certains schémas ne rentrent pas dans le cadre du paradigme "d'accès à l'information" des URI. Par exemple, "telnet" fournit des informations de localisation pour initier un flux bidirectionnel de données à un hôte distant ; la seule opération définie est d'initier la connexion. Dans tous les cas, les opérations appropriées pour un schéma DEVRAIENT être documentées.


Note : Il est parfaitement valide de dire que "aucune opération à part GET n'est définie pour cet URI". Il est aussi valide de dire que "il y a seulement une opération définie pour cet URI, et elle ne ressemble pas beaucoup à GET". L'important est que ce qui est défini sur ce schéma soit décrit.


Les définitions de schéma DEVRAIENT définir une opération "par défaut" pour quand un URI est invoqué (ou "déréférencé") par une application. Par exemple, une opération commune "par défaut" est aujourd'hui de lancer une application associée au nom du schéma et de la laisser utiliser les autres composants de l'URI comme entrées pour faire quelque chose. L'invocation par défaut, ou déréférencement, d'un URI DEVRAIT être "sûre" dans le sens décrit au paragraphe 3.4 de [WebArch] ; c'est-à-dire, qu'effectuer une telle invocation ne devrait entraîner aucune obligation supplémentaire en le faisant.


3.5 Contexte d'utilisation

En général, les URI sont utilisés au sein d'une large gamme de protocoles et applications. Par exemple, les URI sont couramment utilisés au sein de documents hypertext comme références à d'autres ressources. Dans certains cas, un schéma est destiné à être utilisé au sein d'un ensemble différent, spécifique de protocoles ou applications. S'il en est ainsi, les définitions de schéma DEVRAIENT décrire l'utilisation prévue et inclure des références à la documentation qui définit les applications et/ou protocoles cités. Cela ne retire pas le besoin de documentation sur les applications et/ou protocoles pour exposer les schémas d'URI qui en relèvent.


3.6 Internationalisation et codage de caractères

Lors de la description de schémas dans lesquels (certains des) les éléments de l'URI sont des représentations réelles de texte lisible par l'homme, il faut veiller à ne pas introduire une variété inutile des façons dont les caractères sont codés en octets puis en caractères d'URI ; voir la [RFC3987] et le paragraphe 2.5 (en particulier le dernier paragraphe) de la [RFC3986] pour des lignes directrices. Si les URI d'un schéma contiennent des champs de texte, la définition de schéma DOIT décrire les façons dont les caractères sont codés et toutes les questions de compatibilité avec les IRI de ce schéma.


La spécification de schéma DEVRAIT être aussi restrictive que possible à l'égard des caractères permis dans l'URI parce que certains caractères peuvent créer plusieurs problèmes de sécurité différents (voir, par exemple, la [RFC4690]).


Les séquences de caractères codés en pourcentage sont automatiquement incluses par définition pour les caractères donnés dans les productions d'IRI. Cela signifie que si on veut restreindre les formes d'URI codées en pourcentage d'une certaine manière, on doit restreindre les formes Unicode qui y conduiraient. Dans la plupart des cas, il est conseillé de définir le caractère réel permis dans une production d'IRI afin de permettre la définition "pct-encoded" du paragraphe 2.1 de la [RFC3986] aux mêmes endroits et d'ajouter un texte qui limite les échappements en pourcentage à ceux qui peuvent être créés en convertissant des séquences valides de caractères UTF-8 en codage en pourcentage.


3.7 Considérations claires de sécurité et confidentialité

Les définitions de schémas DOIVENT être accompagnées d'une analyse claire des implications pour la sécurité et la confidentialité pour les systèmes qui utilisent le schéma ; ceci suit la pratique des sections de Considérations sur la sécurité au sein des enregistrements de l'IANA [RFC5226].


En particulier, la Section 7 de la [RFC3986] décrit les considérations générales pour la sécurité pour les URI tandis que la [RFC3987] donne celles pour les IRI. La définition d'un schéma individuel devrait noter lesquelles s'appliquent au schéma spécifié, en plus de tout souci plus spécifique du schéma. Par exemple, si la partie spécifique du schéma pose des problèmes de confidentialité, cela devrait être documenté.


3.8 Considérations de schéma de nommage

Le paragraphe 3.1 de la RFC3986 définit la syntaxe d'un nom de schéma d'URI ; cette syntaxe reste la même pour les IRI. Les nouveaux enregistrements de schéma DOIVENT suivre cette syntaxe, qui permet seulement un répertoire limité de caractères (tiré de l'US-ASCII). Bien que la syntaxe pour le nom de schéma dans les URI soit insensible à la casse, le nom de schéma lui-même DOIT être enregistré en utilisant des lettres minuscules.


Les noms de schéma DEVRAIENT être courts mais aussi suffisamment descriptifs et distinctifs pour éviter les problèmes.


Les schémas NE DEVRAIT PAS utiliser des noms ou autres symboles qui pourraient causer des problèmes avec les droits d'utilisation du nom dans les spécifications de l'IETF et les protocoles de l'Internet. Par exemple, faire attention aux marques commerciales et aux noms de marques de services. (Voir au paragraphe 3.4 de la [RFC5378]).


Les schémas NE DEVRAIENT PAS utiliser des noms qui sont soit d'utilisation très générale, soit associés dans la communauté à une autre application ou protocole. Les schémas NE DEVRAIT PAS aussi utiliser les noms qui sont, soit trop généraux, soit de portée grandiose (par exemple, qui font allusion à leur nature "universelle" ou "standard").


Un nom de schéma n'est pas un "protocole". Cependant, comme un nom de service tel que défini à la Section 5 de la [RFC6335], il identifie souvent un protocole ou application particulier. Si un nom de schéma a une correspondance biunivoque avec un nom de service, leur nom DEVRAIT alors être le même.


Certaines organisations désirent leur propre espace de noms pour les noms de schéma d'URI à usage privé (voir la Section 6). En faisant ainsi, il est important de prévenir les collisions et de rendre possible l'identification du possesseur d'un schéma d'utilisation privée. Pour atteindre ces deux objectifs, de telles organisations DEVRAIENT utiliser un préfixe fondé sur leur nom de domaine, exprimé en ordre inverse. Par exemple, un nom de schéma d'URI de "com.exemple.monchose" pourrait être utilisé par l'organisation qui possède le nom de domaine "exemple.com". Il faut cependant faire attention si l'organisation perdait ultérieurement le nom de domaine incorporé dans son nom de schémas, car les enregistrements de noms de domaine ne sont pas permanents. Pour associer le nom de schéma d'utilisation privée avec l'organisation d'origine, le schéma d'utilisation privée peut être enregistré en utilisant la procédure d'enregistrement de la Section 7.


De plus, pour prévenir les collisions avec les noms de schéma d'utilisation privée, les nouveaux enregistrements de noms de schémas NE DOIVENT PAS contenir un "." sauf si ils sont en fait construits à partir d'un nom de domaine inversé.


3.9 Considérations d'interopérabilité

Si la personne ou groupe qui enregistre le schéma est avertie de tout détail concernant le schéma qui pourrait avoir un impact sur l'interopérabilité, cela devrait être identifié ; par exemple, des méthodes de codage protégées ou non courantes, ou une incompatibilité avec les types ou versions d'un protocole sous-jacent.


4. Lignes directrices pour l'enregistrement provisoire de schémas d'URI


Des enregistrements "provisoires" peuvent être utilisés pour des schémas qui ne font pas partie d'une norme mais sont destinés (ou observés comme utilisés) à une utilisation qui n'est pas limitée à un environnement privé au sein d'une seule organisation. L'enregistrement "provisoire" peut aussi être utilisé comme étape intermédiaire sur la voie d'un enregistrement "permanent", par exemple avant que la spécification de schéma soit finalisée comme norme.


Pour un enregistrement "provisoire", les règles suivantes s'appliquent :

o Le nom de schéma doit satisfaire les exigences syntaxiques du paragraphe 3.8.

o Il ne doit pas y avoir déjà une entrée avec le même nom de schéma. Dans le cas, malheureux, où il y aurait plusieurs utilisations du même nom de schéma, l'expert désigné devra approuver une demande de modification d'une entrée existante pour noter l'utilisation différente.

o Les informations de contact qui identifient la personne qui fournit l'enregistrement doivent être incluses Les schémas précédemment non enregistrés dont on découvre l'utilisation peuvent être enregistrés par des tiers (même si il n'agissent pas au nom de ceux qui ont créé le schéma). Dans ce cas, celui qui enregistre et le créateur du schéma DEVRAIENT être identifiés.

o Si aucune spécification permanente, stable, n'est incluse pour la définition de schéma, des raisons crédibles pour ne pas en fournir DEVRAIENT être données.

o La définition de schéma DEVRAIT inclure de claires considérations sur la sécurité (paragraphe 3.7) ou expliquer pourquoi une analyse de sécurité complète n'est pas disponible (par exemple, dans un enregistrement de schéma par un tiers).

o Si la définition de schéma ne satisfait pas aux lignes directrices établies à la Section 3, les différences et raisons DEVRAIENT être notées.


5. Lignes directrices pour l'enregistrement de schéma d'URI historique


Dans certaines circonstances, il est approprié de noter un schéma qui a été utilisé ou enregistré mais qui pour une raison quelconque n'est plus actuellement utilisé ou dont l'utilisation est déconseillée. Dans ce cas, il est possible qu'un individu demande que le schéma d'URI soit enregistré (pour un nouvel enregistrement ou comme mise à jour d'un enregistrement existant) comme "historique". Tout schéma qui n'est plus d'utilisation courante PEUT être désigné comme '"historique" ; l'enregistrement DEVRAIT contenir l'indication que le schéma était précédemment défini ou documenté.


6. Lignes directrices pour l'utilisation de schéma d'URI privé


Des schémas non enregistrés peuvent causer des problèmes si leur utilisation n'est pas limitée à un environnement privé au sein d'une seule organisation car l'utilisation pourrait s'échapper au delà de l'environnement clos. Même au sein d'un environnement clos, d'autres utilisations du même nom de schéma peuvent entrer en collision avec elle. À ce titre, un espace de noms unique DOIT être utilisé et l'enregistrement "provisoire" est fortement conseillé (sauf si le nom de schéma est construit à partir d'un nom de domaine) comme expliqué au paragraphe 3.8.


7. Procédure d'enregistrement de schéma d'URI

7.1 Généralités

La politique de l'IANA (en utilisant les termes définis dans la [RFC5226]) pour l'enregistrement "provisoire" étaient antérieurement la révision par un expert ; le présent document change la politique en "premier arrivé, premier servi". La politique pour les enregistrements "permanents" et "historiques" continue d'être la révision par un expert.


La procédure d'enregistrement est destinée à être très légère pour les enregistrements non contentieux. Pour la plupart, on s'attend à ce que le bon sens des soumettants et des réviseurs, guidés par ces procédures, réalise un consensus acceptable et utile pour la communauté.


Dans des cas exceptionnels, où la négociation entre les parties ne peut arriver à un consensus, l'arbitre final de toute contestation d'enregistrement sera l'IESG.


Si la normalisation est prévue, le groupe de travail ou les individus concernés sont avisés de soumettre une demande d'enregistrement "permanent" précoce plutôt que d'attendre que le processus de normalisation ait achevé son cours. L'IANA la passera à l'expert désigné qui pourra recommander un enregistrement "provisoire" jusqu'à ce que la spécification soit approuvée comme norme. Cela donnera une opportunité d'avoir des réactions pendant le développement et la révision de la spécification sont encore actifs, et alors que le ou les soumettants sont encore en position de répondre à toutes les questions qui pourraient être soulevées. Si et lorsque la spécification est approuvée comme norme, les soumettants devraient soumettre une demande de changement du statut de l'enregistrement en "permanent".


Le rôle de l'expert désigné dans la procédure pour les enregistrements "permanents" décrite ici est destiné à s'assurer que le processus normal de revue ouverte a été bien suivi et de soulever les questions éventuelles sur de plus larges implications des propositions d'utilisations et déploiements des URI. Rien dans la procédure n'autorise l'expert désigné à outrepasser le consensus correctement réalisé à l'IETF ou dans le group de travail.


7.2 Procédures d'enregistrement

Quelqu'un qui souhaite enregistrer un nouveau schéma DOIT :


1. Vérifier dans le registre des schémas d'identifiants de ressource universels (URI) de l'IANA pour voir si il y a déjà une entrée pour le nom désiré. Si il y a déjà une entrée pour le nom, choisir un nom de schéma différent ou mettre à jour la spécification du schéma existant.


2. Préparer une demande d'enregistrement de schéma en utilisant le modèle spécifié au paragraphe 7.4. La demande d'enregistrement de schéma peut être contenue dans un projet Internet, soumise seule, ou au titre d'une autre spécification de protocole stable à disposition permanente. La demande d'enregistrement de schéma peut aussi être soumise sous une autre forme (au titre d'un autre document ou comme un document autonome) mais la demande d'enregistrement de schéma sera traitée comme une "Contribution IETF" selon les lignes directrices de la [RFC5378].


3. Si la demande d'enregistrement est pour un enregistrement "permanent" (ou, facultativement, pour tout autre enregistrement si désiré) :

1. Revoir les exigences de la Section 3.

2. Envoyer une copie de la demande d'enregistrement de schéma ou un pointeur sur le document contenant la demande (avec une référence spécifique à la section que demande l'enregistrement de schéma) à la liste de diffusion uri-review@ietf.org, en demandant la revue, et également, la demande de revue sur les autres listes de diffusion appropriées. Par exemple, la discussion générale des problèmes syntaxiques d'URI peut être examinée sur uri@w3.org ; les schémas pour un protocole réseau peuvent être examinés sur une liste de diffusion pour ce protocole. Permettre un délai raisonnable pour la discussion et les commentaires. Quatre semaines est raisonnable pour une demande d'enregistrement "permanent".

3. Répondre aux commentaires de revue et faire les révisions à l'enregistrement proposé comme nécessaire pour l'aligner sur les lignes directrices du présent document.

4. Soumettre (éventuellement mise à jour) la demande d'enregistrement de schéma (ou le pointeur sur le document qui la contient) à l'IANA à iana@iana.org.


À réception d'une demande d'enregistrement de schéma, les étapes suivantes DOIVENT être respectées :

1. L'IANA vérifie que la demande est complète ; si nécessaire, si des sections de la demande d'enregistrement de schéma manquent ou si des citations ne sont pas correctes, l'IANA va rejeter la demande d'enregistrement. Un déposant peut resoumettre une demande corrigée si il le désire.

2. Si la demande est pour un enregistrement "provisoire" et si aucune entrée n'existe déjà dans le registre actuel pour le même nom, l'IANA ajoute l'enregistrement au registre selon la politique du premier arrivé, premier servi.

3. Autrement, l'IANA entre la demande d'enregistrement dans le registre de l'IANA avec le statut de "Revue en cours", et le reste de cette section s'applique.

4. L'IANA demande une revue par expert de la demande d'enregistrement par rapport aux lignes directrices correspondantes du présent document.

5. L'expert désigné va évaluer la demande par rapport aux critères du statut demandé.

6. Dans le cas d'une demande d'enregistrement "permanent", l'expert désigné peut :

* Accepter la spécification du schéma pour enregistrement "permanent".

* Suggérer plutôt un enregistrement "provisoire".

* Demander la révision par l'IETF et l'approbation de l'IESG ; et entre temps suggérer un enregistrement "provisoire".

* Demander une revue ou discussion supplémentaire si nécessaire.

7. Si une entrée existe déjà pour le même nom, l'expert désigné va déterminer si la demande devrait être rejetée ou si l'entrée existante devrait être modifiée pour noter l'autre utilisation. Ce processus de résolution de conflit s'applique sans considération du statut demandé ou du statut de l'entrée existante.

8. Une fois que l'expert désigné a approuvé l'enregistrement pour un certain statut, l'IANA met à jour l'enregistrement pour indiquer le statut approuvé. Si l'expert désigné rejette l'enregistrement, la demande "Revue en cours" est retirée du registre.


Qu'elle soit fondée sur une demande explicite ou sur une initiative indépendante, l'expert désigné ou l'IESG peuvent demander la mise à niveau d'un enregistrement "provisoire" en "permanent". Dans ce cas, l'IANA va mettre à jour le statut de l'entrée correspondante. Normalement, ceci ne va se produire que si l'utilisation est considérée comme standard (pas nécessairement de l'IETF).


7.3 Contrôle des changements

Les enregistrements peuvent être mis à jour dans le registre par les mêmes mécanisme qu'exigé pour un enregistrement initial. Dans les cas où la définition originale du schéma est contenue dans un document approuvé par l'IESG, la mise à jour de la spécification exige aussi l'approbation de l'IESG.


Les enregistrements "provisoires" peuvent être mis à jour par le déposant originel ou par toute personne désignée par lui. De plus, l'IESG peut réallouer la responsabilité d'un schéma d'enregistrement "provisoire" ou peut demander des changements spécifiques à un enregistrement de schéma. Cela va permettre que des changements soient faits à des schémas où le déposant originel n'est plus joignable, ou ne veut pas, ou est dans l'incapacité, de faire les changements.


La transition du statut de "provisoire" à celui de "permanent" peut être demandée et approuvée de la même manière que pour un nouvel enregistrement "permanent". La transition du statut de "permanent" à celui de "historique exige l'approbation de l'IESG. La transition de "provisoire" à "historique" peut être demandée par quiconque est autorisé à mettre à jour l'enregistrement "provisoire".


7.4 Modèle d'enregistrement de schéma d'URI

Ce modèle décrit les champs qui DOIVENT être servis dans une demande d'enregistrement de schéma pour convenir à un ajout dans le registre :


Nom du schéma : voir les lignes directrices au paragraphe 3.8.

Statut : ceci reflète le statut demandé et doit être "Permanent", "Provisoire", ou 'Historique".

Applications/protocoles qui utilisent ce nom de schéma : voir au paragraphe 3.5.

Contact (incluant les informations de contact) : personne à contacter pour plus d'informations.

Contrôleur des changements : organisation ou personne (souvent l'auteur) incluant les informations de contact, autorisé à changer cela.

Références : Incluent la citation complète de tous les documents référencés. Les demandes d'enregistrement de schéma pour les enregistrements "provisoires" peuvent être inclus dans un projet Internet ; lorsque le document arrive à expiration ou est approuvé pour publication comme RFC, l'enregistrement sera mis à jour. Une spécification de schéma n'est exigée que pour en enregistrement "permanent".


La version précédente de la présente spécification exigeait les champs supplémentaires suivants dans une demande d'enregistrement de schéma. Ces champs ne font plus partie du modèle. Par contre les réponses appartiennent à la spécification du schéma.


Syntaxe du schéma : voir les lignes directrices au paragraphe 3.2.

Sémantique du schéma : voir les lignes directrices aux paragraphes 3.3 et 3.4.

Considérations de codage : voir les lignes directrices aux paragraphes 3.3 et 3.6.

Considérations d'interopérabilité : voir les lignes directrices au paragraphe 3.9.

Considérations de sécurité : voir les lignes directrices au paragraphe 3.7.


8. Schéma d'URI "exemple"


On a besoin d'un nom de schéma qui puisse être utilisé pour les exemples dans la documentation sans crainte de conflit avec des schémas réels actuels ou futurs. Le schéma "exemple" est enregistré ici à cette fin comme schéma "permanent".


Le schéma "exemple" est spécifié comme suit :


Syntaxe de schéma : la gamme entière de syntaxe admissible spécifiée dans la [RFC3986] est permise pour les URI "exemple". De même, la gamme entière de la syntaxe admissible spécifiée dans la [RFC3987] est admise pour les IRI "exemple". Par exemple, <exemple:foo>, <exemple:/foo>, et <exemple://foo> sont tous valides.


Sémantique du schéma : les URI dans le schéma "exemple" sont à utiliser uniquement pour les besoins de documentation. L'utilisation des URI "exemple" n'est pas autorisée comme localisateurs, identifier une ressource, ou spécifier un ensemble particulier d'opérations.


Considérations de codage : voir les lignes directrices au paragraphe 2.5 de la [RFC3986].


Considérations d'interopérabilité : Aucune.


Considérations de sécurité : Aucune.


8.1 Demande d'enregistrement du schéma d'URI "exemple"

Nom de schéma : exemple

Statut: permanent

Applications/protocoles qui utilisent ce nom de schéma : un URI "exemple" est à utiliser seulement pour les besoins de documentation. Il NE DOIT être utilisé pour aucun protocole.

Contact : non disponible

Contrôleur des changements : IETF

Références : Section 8 du présent document (RFC7595).


9. Considérations relatives à l'IANA


Précédemment, le registre des "schémas d'URL" a été remplacé par le registre des "schémas d'identifiant de ressource universel (URI)". Le processus était fondé sur la "revue par expert" [RFC5226] avec une relecture initiale (facultative) par la liste de diffusion.


Le modèle mis à jour a un champ supplémentaire pour le statut du schéma, et les procédures pour entrer un nouveau nom de schéma ont été augmentées. La Section 7 établit le processus pour l'enregistrement de nouveau schéma.


L'IANA a fait ce qui suit :

o mise à jour du registre des schémas d'URI pour pointer sur le présent document,

o combiné les sous registres "schémas d'URI permanents", "schémas d'URI provisoires", et "schémas d'URI historiques" en un seul registre commun avec une colonne supplémentaire "Statut" qui contient le statut ("permanent", "provisoire", "historique", ou "revue en cours") et une colonne "Notes" supplémentaire qui est normalement vide mais peut contenir des notes approuvées par l'expert désigné,

o ajouté le schéma d'URI "exemple" au registre (voir le modèle d'enregistrement du paragraphe 8.1).


10. Considérations sur la sécurité


Toutes les valeurs enregistrées sont supposées contenir des considérations claires sur la sécurité comme exposé au paragraphe 3.7. Cependant, les informations concernant de possibles vulnérabilités de la sécurité d'un protocole peuvent changer dans le temps. Par conséquent, les prétentions sur les propriétés de sécurité d'un schéma enregistré peuvent changer aussi. Lorsque de nouvelles vulnérabilités sont découvertes, les informations sur elles peuvent devoir être jointes à la documentation existante, de sorte que les utilisateurs ne soient pas abusés sur les vraies propriétés de sécurité d'un schéma enregistré.


11. Références

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


[RFC2141] R. Moats, "Syntaxe des URN", mai 1997.


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


[RFC5226] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434)


[RFC5378] S. Bradner et autres, "Droits que les contributeurs fournissent à l'IETF Trust", novembre 2008. (BCP0078) (Remplace RFC3978, RFC4748, MàJ RFC2026)


[RFC6335] M. Cotton et autres, "Procédures de l’autorité d’allocation des numéros de l’Internet (IANA) pour la gestion du registre des numéros d’accès aux noms de service et protocoles de transport", août 2011. (MàJ les RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595) (BCP0165)


11.2 Références pour information

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


[RFC2718] L. Masinter, H. Alvestrand, D. Zigmond et R. Petke, "Lignes directrices pour les nouveaux schémas d'URL", novembre 1999. (Obsolète, voir RFC4395) (Information)


[RFC3406] L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom, "Mécanismes de définition d'espace de noms de noms de ressource uniforme (URN)", octobre 2002. (BCP0066)


[RFC3864] G. Klyne, M. Nottingham, J. Mogul, "Procédures d'enregistrement pour les champs d'en-tête de message", septembre 2004. (BCP0090)


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


[RFC4395] T. Hansen et autres, "Lignes directrices et procédures d'enregistrement pour les nouveaux schémas d'URI", février 2006. (Remplace RFC2717, RFC2718) (BCP0115)


[RFC4690] J. Klensin et autres, "Révisons et recommandations pour les noms de domaines internationalisés (IDN)", septembre 2006. (Information)


[WebArch] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", Recommandation W3C, décembre 2004, < http://www.w3.org/TR/webarch/ >.


Remerciements


Merci à Mark Nottingham et Graham Klyne et aux autres membres de la liste de diffusion apps-discuss@ietf.org pour leurs commentaires sur le document.


Un grand merci à Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, et aux autres membres de la liste de diffusion uri@w3.org pour leurs commentaires sur les premières versions de ce projet de document.


Des parties du document se fondent sur les [RFC2717], [RFC2718] et [RFC3864]. Certaines des idées sur l'utilisation des URI ont été tirées de "Architecture of the World Wide Web" [WebArch].


Contributeurs


Larry Masinter était un des auteurs du document duquel le présent travail est dérivé, et a continué comme auteur de cette version à travers le groupe de travail et la périodes d'évaluation de l'IESG. Ses nombreuses contributions méritent notre reconnaissance.


Adresse des auteurs


Dave Thaler (editor)

Tony Hansen

Ted Hardie

Microsoft

AT&T Laboratories

Google

One Microsoft Way

200 Laurel Ave.

téléphone : +1 408 628 5864

Redmond, WA 98052

Middletown, NJ 07748

mél : ted.ietf@gmail.com

United States

United States


téléphone : +1 425 703 8835

mél : tony+urireg@maillennium.att.com


mél : dthaler@microsoft.com