Procédure d'enregistrement d'étiquette de caractéristique de support

Statut de ce mémoire

Le présent document spécifie les bonnes pratiques actuelle de l'Internet pour la communauté de l'Internet, et appelle à de discussions et des suggestions pour son amélioration. La diffusion du présent mémoire n'est soumise à aucune restriction.

Notice de cpyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

Résumé

Les applications Internet récentes, telles que la Toile mondiale, relient entre elles une grande diversité de formats de données, de plates-formes client et serveur, et de communautés. Cela a créé un besoin de descriptions de caractéristiques des supports et de mécanismes de négociation afin d'identifier et réconcilier la forme de l'information aux capacités et préférences des parties impliquées.

Une identification extensible des caractéristiques de support et des mécanismes de négociation exige un vocabulaire commun afin d'identifier positivement les caractéristiques de support. Un processus d'enregistrement et d'autorité pour les caractéristiques de support est défini avec l'intention de faire partager ce vocabulaire par les parties à la communication. De plus, une arborescence d'URI est définie pour permettre le partage des définitions de caractéristiques de support sans enregistrement.

Le présent document définit une procédure d'enregistrement qui utilise l'Autoristé d'allocation des numéros de l'Internet (IANA) comme registraire central des vocabulaires de caractéristiques de support.

Prière d'envoyer les commentaires au groupe de travail CONNEG à <ietf- medfree@imc.org>. Les discussions du groupe de travail sont archivées à <URL: http://www.imc.org/ietf-medfree/>.

Table des Matières

1. Introduction

2. Définitions d'étiquette de caractéristique de support

2.1 Objet de l'étiquette de caractéristique de support

2.2 Syntaxe d'étiquette de caractéristique de support

2.3 Valeurs d'étiquette de caractéristique de support

2.4 Identifiants ASN.1 pour les étiquettes de caractéristique de support

3. Enregistrement d'étiquette de caractéristique de support

3.1 Arborescences d'enregistrement

3.2 Localisation de la liste des étiquettes de caractéristiques enregistrées

3.3 Procédures de l'IANA pour l'enregistrement des étiquettes de caractéristiques

3.4 Modèle d'enregistrement

4. Considérations pour la sécurité

5. Remerciements 7

6. Références

7. Adresse des auteurs

8. Déclaration complète de droits de reproduction

1. Introduction

Les applications récentes de l'Internet, telles que la Toile mondiale, relient ensemble une grande diversité de formats de données, de plates-formes client et serveur, et de communautés. Cela a créé un besoin d'avoir des descriptions de caractéristiques des supports et des mécanimes de négociation pour identifier et réconcilier la forme des informations aux capacités et les préférences des parties impliquées.

Des mécanismes extensibles d'identification et de négociation des caractéristiques des supports exigent un vocabulaire commun pour identifier positivement les caractéristiques de support. Un processus et une autorité d'enregistrement pour les caractéristiques de support sont définis avec l'intention de faire partager ce vocabulaire par les parties à la communication. De plus, une arborescence d'URI est établie pour permettre le partage des définitions de caractéristiques de support sans enregistrement.

Le présent document définit une procédure d'enregistrement qui utilise l'Autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority) comme registraire central du vocabulaire de caractéristique de support.

Le présent document utilise les termes DOIT, NE DOIT PAS, DEVRAIT, NE DEVRAIT PAS et PEUT conforméùent à l'usage décrit dans la [RFC2119].

2. Définitions d'étiquette de caractéristique de support

2.1 Objet de l'étiquette de caractéristique de support

L'étiquette de caractéristique de support représente une caractéristique individuelle et simple qui se rapporte à des capacités ou propriétés du support associées à la ressource à laquelle elles sont appliquées. Des exemples de telles caractéristiques sont :

* la profondeur de couleur de l'écran sur lequel quelque chose doit s'afficher,

* le type de papier disponible dans une imprimante,

* la prise en charge de la caractéristique de "tableau de dimension flottant 5",

* les fontes qui sont disponibles chez le receveur,

* la capacité à afficher le contenu graphique.

Chaque étiquette de caractéristique de support identifie une seule caractéristique. Les valeurs associées à une étiquette spécifique doivent utiliser le type de données défini pour cette étiquette. La liste des types de données admises est présentée ci-dessous, au paragraphe 2.3.

Des exemples d'étiquettes de caractéristique de support avec des valeurs sont :

* la largeur d'un affichage en pixels par centimètre représentée par une valeur d'entier,

* une fonte disponible chez un receveur, choisie dans une liste qui les énumère,

* la version d'un protocole composée d'entiers "i.j.k", définis soit par une valeur dans une liste énumérative, soit par une transposition définie pour rendre la valeur isomorphe à un sous-ensemble d'entiers (par exemple, i*100 + j*10 +k, en supposant j ≤ 9 et k ≤ 9).

D'autres exemples d'étiquettes de caractéristique de support sont définies en détail dans la [RFC2534].

Des collections de caractéristiques peuvent être composées en utilisant un certain nombre d'étiquettes de caractéristique individuelle [RFC2533]. La composition de collections de caractéristiques est décrite dans la [RFC2533]. Des exemples de collections de caractéristiques exigeant plusieurs étiquettes de caractéristique de support sont :

* l'ensemble de toutes les fontes utilisées par un document,

* la largeur et la hauteur d'un affichage,

* la combinaison d'une profondeur de couleur et de la résolution que peut prendre en charge un affichage.

Ce registre présuppose la disponibilité du registre des types de support MIME, et les types de support MIME NE DOIVENT PAS être réenregistrés comme étiquettes de caractéristique de support. Les étiquettes de caractéristique de support qui sont utilisées actuellement par les protocoles ou applications individuels PEUVENT être enregistrés dans ce registre si ils pourraient être appliqués en-dehors de leur domaine actuel.

L'espace de nom des étiquettes de caractéristique de support n'est pas lié à un protocole de transport ou à un mécanisme d'échange de capacités particulier. Le registre est cependant limité aux caractéristiques qui expriment une capacité ou préférence en rapport avec la façon dont le contenu est présenté. Les étiquettes de caractéristique qui se rapportent à d'autres axes de négociation ne sont pas appropriées pour ce registre. Les mécanismes d'échange de capacités peuvent, bien sûr, être utilisés pour exprimer diverses capacités ou préférences.

2.2 Syntaxe d'étiquette de caractéristique de support

Une étiquette de caractéristique de support est une chaîne consistant en un ou plusieurs des caractères US-ASCII suivants : lettres majuscules, lettres minuscules, chiffres, deux-points ":", barre oblique "/", point "." pour cent "%", et tiret "-". Les étiquettes de caractéristiques sont insensibles à la casse. Les points sont compris comme impliquant potentiellement une hiérarchie ; une caractéristique peut comporter des sous-types en la décrivant comme un "arbre.caractéristique.sous-caractéristique" et en indiquant cela dans l'enregistrement. Les étiquettes devraient commencer par un caractère alphabétique.

En ABNF [RFC2234], cela peut être représenté par :

étiquette-de-caractéristique = ALPHA *( ALPHA / CHIFFRE / ":" / "/" / "." / "-" / "%" )

Les enregistrants devraient veiller à éviter de créer des étiquettes qui pourraient entrer en conflit avec la création de nouveaux arbres d'enregistrement ; en général, cela signifie d'éviter les étiquettes qui commencent par un caractère alphabétique suivi d'un point. Les arbres d'enregistrement actuels sont décrits à la section 3 ci-dessous.

2.3 Valeurs d'étiquette de caractéristique de support

Le registre va initialement prendre en charge l'utilisation des types de données suivantes comme valeurs d'étiquettes :

- des entiers signés

- des nombres rationnels

- des jetons, avec des relations d'égalité

- des jetons, avec des relations d'ordre définies

- des chaînes, avec des relations d'égalité standard (octet par octet)

- des chaînes, avec des relations d'égalité et/ou de comparaison définies.

"Jeton" signifie ici le type de données jeton tel que défini dans la [RFC2068], qui peut être résumé par :

jeton = 1*<tout CHAR sauf les CTL ou les tspecials>

tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HT

Au moment de l'enregistrement, chaque étiquette doit être associée à un seul type de données. Si ce type de données implique une comparaison ou un ordre défini, l'enregistrant doit définir l'ordre ou la comparaison. Pour les jetons d'ordre, cela peut être l'énumération complète des jetons et leur ordre ou par référence à un mécanisme de rangement. Pour les comparaisons définies, une description complète des règles de comparaison doit être fournie ou incluse par référence.

Les étiquettes de caractéristique de support relatives à des caractéristiques spatiales ou temporelles doivent être enregistrées par une seule unité canonique. Il est fortement préféré que les unités soient dans le système SI ; lorsque la pratique courante a défini des unités dans d'autres systèmes (comme les pixels par pouce) une méthode de conversion en unités SI doit être fournie. Les méthodes de conversion devraient inclure une règle d'arrondi définie.

2.4 Identifiants ASN.1 pour les étiquettes de caractéristique de support

Certains protocoles utilisent des identifiants ASN.1 plutôt que des représentations lisibles par l'homme pour les échanges de capacités. Pour permettre aux deux systèmes d'interopérer, les enregistrants peuvent fournir un identifiant ASN.1 ou demander que l'IANA alloue un identifiant ASN.1 durant l'enregistrement. Ces identifiants ne sont pas exigés pour l'enregistrement, mais peuvent aider ceux qui construisent des passerelles ou autres systèmes inter protocoles. Noter que les identifiants ASN.1 alloués par l'IANA seront traités comme des jetons, et non comme des éléments d'après lesquels des identifiants sous délégués pourraient être créés ou déduits.

3. Enregistrement d'étiquette de caractéristique de support

Les étiquettes de caractéristique de support peuvent être enregistrées dans plusieurs arborescences d'enregistrement différentes, avec des exigences différentes comme expliqué plus loin. Le vocabulaire pour ces exigences est tiré de la [RFC2434]. En général, une proposition d'enregistrement d'étiquette de caractéristique est diffusée et révisée d'une façon appropriée à l'arborescence impliquée. L'étiquette de caractéristique est alors enregistrée si la proposition est acceptée.

La révision d'une étiquette de caractéristique dans l'arbre des URI n'est pas exigée.

3.1 Arborescences d'enregistrement

Les paragraphes qui suivent définissent les "arborescencesé d'enregistrement", distinguées par l'utilisation de noms articulés (par exemple, les noms de la forme "arbre.nom-de-caractéristique").

3.1.1 Arborescence de l'IETF

L'arborescence de l'IETF est destinée aux étiquettes de caractéristique de support d'intérêt général pour la communauté de l'Internet, et les propositions de ces étiquettes doivent satisfaire aux politiques de "consensus de l'IETF" décrites dans la [RFC2434].

L'enregistrement dans l'arborescence de l'IETF exige l'approbation par l'IESG et la publication de la spécification de l'étiquette de caractéristique comme RFC. Les soumissions d'enregistrement d'étiquette de caractéristique dans l'arborescence de l'IETF peut avoir pour origine tout groupe de travail de l'IETF ou une soumission individuelle auprès de l'IESG.

Les étiquettes de caractéristiques dans l'arborescence de l'IETF ont normalement des noms qui ne sont pas explicitement articulés, c'est-à-dire qu'ils ne contiennent pas de caractère point (".").

3.1.2 Arborescence mondiale

Les étiquettes dans l'arborescence mondiale seront distinguées par l'articulation "g." en tête. Une organisation peut proposer soit une désignation indicative de la caractéristique, (par exemple, "g.blinktags") soit une désignation articulée incluant le nom de l'organisation (par exemple, "g.organisation.blinktags"). Les organisations qui ont enregistré des types de supports sous l'arborescence de fabricant MIME devraient utiliser le même nom d'organisation pour les étiquettes de caractéristique de support si elles proposent une désignation articulée. L'acceptation de la désignation proposée est à la discrétion de l'IANA. Si l'IANA estime qu'une désignation doit être précisée, elle peut demander une nouvelle proposition à l'organisation demanderesse ou coordonner autrement le développement d'une désignation appropriée.

Les enregistrements d'étiquettes de caractéristiques dans l'arborescence mondiale doivent satisfaire aux politiques de "révision par des experts" décrites dans la [RFC2434]. Dans ce cas, un expert désigné va revoir l'étiquette proposée, et consulter les membres d'une liste de diffusion en rapport. Un enregistrement peut être proposé pour l'arborescence mondiale par toute personne qui a besoin de permettre la communication sur une capacité ou préférence particulière.

3.1.3 Arborescence d'URI

Une étiquette de caractéristique peut être définie comme un URI en utilisant l'ensemble de caractères restreint défini ci-dessus. Les étiquettes de caractéristique dans l'arborescence d'URI sont identifiées par l'articulation "u." en tête. L'articulation u. en tête est suivie par un URI [RFC1630] qui se conforme aux limitations de caractères spécifiées dans ce document. L'auteur de l'URI est supposé être l'autorité d'enregistrement à l'égard des caractéristiques définies et décrites par le contenu de l'URI. Ces étiquettes sont considérées comme non enregistrées pour les besoins du présent document.

3.1.4 Arborescences d'enregistrement supplémentaires

De temps en temps et selon les besoins de la communauté, l'IANA peut, sur avis et avec le consentement de l'IESG, créer de nouvelles arborescences d'enregistrement de niveau supérieur. Ces arborescences peuvent être créées pour un enregistrement externe et une gestion par (par exemple) des organismes permanents bien connus, comme des sociétés scientifiques pour des types de caractéristiques de supports spécifiques des sciences qu'ils concernent. L'établissement de ces nouvelles arborescences sera annoncée par la publication d'une RFC approuvée par l'IESG.

3.2 Localisation de la liste des étiquettes de caractéristiques enregistrées

Les enregistrements d'étiquette de caractéristique seront envoyés au répertoire FTP anonyme : "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/" et toutes les étiquettes de caractéristiques enregistrées seront inscrites sur la liste de la RFC produite périodiquement des "Numéros alloués" [actuellement le STD 2, RFC1700]. La description de l'étiquette de caractéristique et le matériel de support peut aussi être publié comme RFC d'information en l'envoyant à "rfc-editor@rfc-editor.org".

3.3 Procédures de l'IANA pour l'enregistrement des étiquettes de caractéristiques

L'IANA n'enregistrera les étiquettes de caractéristiques dans l'arborescence de l'IETF qu'en réponse à une communication de l'IESG étalissant qu'un enregistrement donné a été approuvé.

Les étiquettes mondiales seront enregistrées par l'IANA après examen par un expert désigné. Cet examen va servir à s'assurer que l'étiquette satisfait aux exigences techniques de sa spécification.

3.4 Modèle d'enregistrement

À : media-feature-tags@apps.ietf.org (Liste de diffusion des étiquettes de caractéristique de support)

Objet : Enregistrement de l'étiquette de caractéristique de support XXXX

| Les instructions sont précédées de "|". Ceretains champs sont facultatifs.

Nom de l'étiquette de caractéristique de support :

Identifiant ASN.1 associé à l'étiquettede caractéristique : [facultatif]

| Pour que l'IANA alloue un identifiant ASN.1, utiliser la valeur "Nouvelle allocation par l'IANA" ici.

Résumé des caractéristiques de support indiquées par cette étiquette de caractéristiques :

| Inclure un bref résumé ou description (pas plus de 4 lignes).

| Exemples :

| "Utilise la caractéristique xyzzy de la façon indiquée par ..."

| "La prise en charge de l'affichage des couleurs est indiquée par ..."

| "Nombre de couleurs dans une palette qui peuvent être définies ..."

Valeurs appropriées pour un usage avec cette étiquette de caractéristique:

[ ] 1. L'étiquette de caractéristique est booléenne et peut avoir des valeurs de VRAI ou FAUX. Une valeur de VRAI indique une capacité disponible. Une valeur de FAUX indique que la capacité n'est pas disponible.

| Si vous souhaitez indiquer des possibilités mutuellement exclusives qui ne peuvent pas être exprimées comme la disponibilité ou l'absence d'une capacité, utiliser une liste à deux jetons plutôt qu'une valeur booléenne.

[ ] 2. La caractéristique a une valeur numérique ou énumérée associée.

Pour le cas 2 : Indiquer le type de données de la valeur :

[ ] 2a. Entier signé

[ ] 2b. Nombre rationnel

[ ] 2c. Jeton (relation d'égalité)

[ ] 2d. Jeton (ordonné)

[ ] 2e. Chaîne (relation d'égalité)

[ ] 2f. Chaîne (comparaison définie)

|IMPORTANT : Un seul des types de données ci-dessus doit être choisi.

(Seulement pour le cas 2) Une description détaillée de la signification de la valeur de la caractéristique, et le format et la signification des valeurs de l'étiquette de caractéristique pour les résultats de l'autre solution.

| Si vous avez choisi 2d vous devez fournir le mécanisme de classement ou une énumération complète et ordonnée des

| valeurs possibles. Si vous avez choisi 2f, vous devez fournir une définition de la comparaison. Les définitions par

| référence incluse doivent être des spécifications stables et directement disponibles :

| Si le nombre de résultats possibles est petit, vous pouvez énumerer les identifiants des différents résultats et décrire leur

| signification.

| Si il y a une gamme numérique utile limitée de résultat (2b, 2c), indiquer la gamme.

| Les identifiants des résultats possibles pourraient aussi ^étre décrits par référence à un autre registre de l'IANA, par

| exemple, les tailles de papier par la MIB d'imprimante.

L'étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocolzs, services, ou mécanismes de négociation suivants : [facultatif]

| Pour les applications, spécifier aussi le numéro de la première version qui va utilise l'étiquette, si c'estapplicable.

Exemples d'utilisations typiques : [facultatif]

Normes ou documents en rapport : [facultatif]

Considérations particulières d'utilisation dans les applications individuelles, protocoles, services, ou mécanismes de négocation : [facultatif]

Considérations d'interopérabilité : [facultatif]

Considérations pour la sécurité :

Problèmes de confidentialité, en rapport avec l'exposition d'informations personnelles :

Problèmes de déni de service en rapport avec les conséquences de la pécification de valeurs incorrectes :

Autres :

Informations supplémentaires : [facultatif]

Mots clés : [facultatif

Étiquettes de caractéristique en rapport : [facultatif]

Types de supports ou formats de données en rapport : [facultatif]

Étiquettes de balisage en rapport : [facultatif]

Noms & adresses de messagerie des personnes à contacter pour des informations complémentaires :

Usage de destination :

| une des valeurs de COMMUN, USAGE LIMITÉ ou OBSOLETE

Auteur/Contrôleur des modifications :

Délai de publication demandé à l'IANA : [facultatif]

| Un délai ne peut être demandé pour un placement final dans les arborescences mondiales ou de l'IETF qu'avec un

| maximum de deux mois. Les organisations|qui demandent un enregistrement avec un délai de publication devraient noter

| que cela ne retarde que la publication officielle de l'étiquette et n'empêche pas que les informations la concernant soient

| divulguées par les membres de la liste de diffusion pertinente.

Autres informations : [facultatif]

| Toute autre information que l'auteur estime interessante peut être ajoutée ici.

4. Considérations pour la sécurité

Les mécanismes de négociation révèlent des informations sur une partie aux autres parties. Cela peut soulever des problèmes de confidentialité, et peut permettre à une personne malveillante de faire de meilleures hypothèses sur la présences de failles spécifiques dans la sécurité.

5. Remerciements

Les détails de la procédure d'enregistrement dans le présent document ont été directement adaptés de la [RFC2048]. Beaucoup du texte de la section 3 a été directement copié de cette source.

L'idée de création d'un vocabulaire des zones de caractéristiques de support, conservées dans un registre central ouvert, est née dans les discussions sur l'extension des mécanismes de négociation de la [RFC2295] dans le groupe de travail HTTP de l'IETF.

Les auteurs souhaitent remercier Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, et Martin Duerst pour leurs contributions aux discussions sur l'enregistrement d'étiquette de caractéristique de support.

6. Références

[RFC2048] N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-89)

[RFC2533] G. Klyne, "Syntaxe de description des ensembles de caractéristiques des supports", mars 1999. (MàJ par RFC2738, RFC2938) (P.S.)

[RFC2295] K. Holtman, A. Mutz, "Négociation de contenu transparent dans HTTP", mars 1998. (Expérimentale)

[RFC2534] L. Masinter et autres, "Caractéristiques de support pour l'affichage, l'impression et la télécopie", mars 1999. (

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

[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Protocole de transfert Hypertext -- HTTP/1.1", janvier 1997. (Obsolète, voir RFC2616) (P.S.)

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

[RFC1630] T. Berners-Lee, "Identifiants de ressource universels dans la Toile mondiale ; syntaxe unificatrice pour l'expression des noms et adresses des objets du réseau utilisés sur la Toile mondiale", juin 1994. (Information)

7. Adresse des auteurs

Koen Holtman	Andrew H. Mutz	Ted Hardie
Technische Universiteit Eindhoven	Hewlett-Packard Company	Equinix
Postbus 513	11000 Wolfe Rd. 42UO	901 Marshall Street
Kamer HG 6.57	Cupertino CA 95014	Redwood City, CA 94063
5600 MB Eindhoven	USA	USA
The Netherlands	fax : +1 408 447 4439	mél : hardie@equinix.com
mél : koen@win.tue.nl	mél : andy_mutz@hp.com

8. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes de l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation à un objet particulier.