Registre XML de l’IETF

Statut de ce mémoire

Le présent document spécifie les bonnes pratiques actuelles de l’Internet pour la communauté de l’Internet, et appelle à la discussion et à des suggestions d’améliorations. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

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

Résumé

Le présent document décrit un registre tenu par l’IANA pour les normes de l’IETF qui utilisent des éléments en rapport avec le langage de balisage extensible (XML, Extensible Markup Language) tels que les espaces de noms (Namespaces), les déclarations de type de document (DTD, Document Type Declaration), les schémas, et les schémas de cadre de description de ressource (RDF, Resource Description Framework).

1. Introduction

Ces dernières années, le langage de balisage extensible (XML, Extensible Markup Language) [REC-xml] est devenu une méthode largement utilisée pour le balisage des données. Plusieurs groupes de travail de l’IETF ont produit des normes qui établissent des définitions de type de document (DTD, Document Type Definitions) XML, des espaces de noms XML [REC-xml-names], et des schémas XML [REC-xmlschema- 1]. Chacune de ces technologies utilise des identifiants de ressource universels (URI, Uniform Resource Identifier) [RFC2396] et d’autres identifiants standard pour identifier les divers composants.

Par exemple, alors que la pratique dans certaines normes qui utilisent les définitions de type de document (DTD) est de délaisser l’utilisation des identifiants PUBLIC en faveur des identifiants SYSTEM "bien connus", cela s’est révélé apporter plus de problèmes que d’avantages de tenter de normaliser les identifiants SYSTEM. Le résultat est que plusieurs normes de l’IETF ont simplement créé des URI non résolubles afin de simplement identifier mais non résoudre le DTD pour certains documents XML.

Le présent document cherche à normaliser et améliorer ces pratiques en créant un registre tenu par l’IANA des identifiants d’éléments XML afin que les auteurs de document et leurs mises en œuvre aient un site bien tenu et d’autorité pour leurs éléments XML. Au titre de la présente norme, l’IANA assurera la maintenance :

o de la représentation publique du document,

o de l’URI pour les éléments si il en est fourni un au moment de l’enregistrement,

o d’un registre des identifiants publics comme URI.

Dans le cas où le déposant de l’enregistrement ne demande pas un URI particulier, l’IANA va allouer un nom de ressource universel (URN, Uniform Resource Name) qui suit la [RFC3553].

2. Terminologie

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

3. Documents enregistrables

3.1 URI alloués/enregistrée

Tous les éléments (excepté les identifiants PUBLIC) dans ce registre vont exiger un URI pour être enregistrés. Si le déclarant souhaite qu’un URI soit alloué, alors un URN de la forme

urn:ietf:params:xml:<classe>:<id>

sera alloué où <classe> est le type du document à enregistrer (voir ci-dessous). <id> est un identifiant unique généré par l’IANA sur la base de tout moyen qu’elle estime nécessaire pour maintenir l’unicité et la persistance.

Note : afin qu’un URN de ce type soit alloué, l’élément à enregistrer DOIT être passé par le processus de consensus de l’IETF. Fondamentalement, cela signifie qu’il doit être documenté dans une RFC. Le gabarit d’enregistrement d’URN de la [RFC3553] se trouve à la Section 6.

L’IANA va aussi tenir à disposition un serveur de fichiers via au moins HTTP et FTP qui contienne tous les éléments enregistrés dans un espace de fichiers accessible publiquement de la même façon que tous les éléments enregistrés de l’IANA sont disponibles via http://www.iana.org/assignments/. Bien que la structure de répertoire de ce serveur soit de la responsabilité de l’IANA, il est suggéré que les fichiers soient organisés par <classe> et que les fichiers individuels aient comme nom de fichier leur identifiant <id>.

Les mises en œuvre ne devraient pas appuyer leurs programmes sur l’idée de la disponibilité de ces ressources ni sur la stabilité de la structure du répertoire. Il est explicitement reconnu que certains outils logiciels tentent de télécharger les DTD, les schémas, etc., 'au vol' et que les développeurs devraient comprendre quand cela peut se faire et quand il ne faut pas référencer les ressources réseau de l’IANA comme un "répertoire de téléchargement de schémas". C’est la raison pour laquelle l’IANA ne va pas enregistrer ou fournir des identifiants SYSTEM.

3.2 Classes enregistrables

La liste des types d’éléments XML qui peuvent être enregistrés auprès de l’IANA est :

publicid – un document XML qui contient une déclaration DOCTYPE ou toute autre référence externe peut identifier cette référence via à la fois un identifiant PUBLIC et un identifiant SYSTEM. L’identifiant SYSTEM sont des informations spécifiques du système qui permettent au gestionnaire de l’entité d’un système XML de localiser le fichier, la position en mémoire, ou de pointer au sein d’un fichier l’endroit où on peut trouver l’entité. On notera qu’un identifiant système pourrait être une invocation d’un programme qui contrôle l’accès à une entité à identifier. Donc, ce ne sont pas des éléments enregistrés. Dans de nombreux cas, les identifiants SYSTEM sont aussi des URI. Cependant, dans ce cas, l’URI n’est quand même utilisé que pour des informations spécifiques du système. Dans le cas où un identifiant PUBLIC est aussi un URI, il est possible que l’identifiant SYSTEM contienne le même URI, mais ce comportement n’est pas recommandé si on ne connaît pas bien les effets collatéraux et les éventuelles dommages inacceptables qu’ils pourraient causer.

Un identifiant PUBLIC est un nom qui est destiné à être signifiant à travers les systèmes et des environnements d’utilisateurs différents. Normalement, ce sera un nom qui a un possesseur enregistré qui lui est associé, de sorte que l’unicité des identifiants publics soit garantie et qu’il n’y ait pas deux entités qui aient le même identifiant public. En pratique, les identifiants PUBLIC sont normalement des identifiants publics formels de la norme [ISO.8879] mais ils ne se restreignent pas juste à cet ensemble. Comme il est dit dans la [RFC3151] : "Toute chaîne qui consiste seulement en caractères de l’identifiant public (définis par la production 13 du langage de balisage extensible (XML) 1.0 seconde édition) est un identifiant public légal."

Donc, il est légal qu’un identifiant PUBLIC soit un URN si il adhère aux restrictions de jeu de caractères.

Donc, l’identifiant enregistré avec un DTD est son identifiant PUBLIC. La seule restriction étant qu’il doit adhérer aux restrictions de jeu de caractère. Dans le cas où le déclarant n’en fournit pas, l’IANA en allouera un de la forme 'urn:ietf:params:xml:pi:<id>'. Les déclarants sont invités à étudier la [RFC3151] comme méthode recommandée pour forger un URN qui puisse aussi être représenté comme un FPI.

ns -- Les espaces de noms XML [W3C.REC-xml-names] sont désignés par un URI. Ils n’ont pas de représentation réelle, analysable par la machine. Donc, le document enregistré sera soit la spécification, soit une référence à cette spécification. Dans le cas où un URI n’est pas fourni par le déclarant, l’IANA allouera un URN de la forme 'urn:ietf:params:xml:ns:<id> qui sera le nom de l’espace de noms XML.

schema – Les schémas XML [REC-xmlschema-1] sont aussi identifiés par un URI mais leur contenu est analysable par la machine. Les documents enregistrés par l’IANA seront le fichier Schema XML. L’URN qu’alloue l’IANA peut être utilisé comme URI pour le schéma et est de la forme 'urn:ietf:params:xml:schema:<id>'.

rdfschema -- Le format de description de ressource (RDF, Resource Description Format) [CR-rdf-schema] est une mise en série XML d’un modèle de données fondé sur le graphe connecté utilisé pour l’expression des métadonnées. Le RDF utilise les schémas pour que RDF exprime la grammaire des relations entre les URI. Cette grammaire est identifiée par les URI. L’URN alloué par l’IANA peut être utilisé comme URI identifiant et est de la forme 'urn:ietf:params:xml:rdfschema:<id>'.

4. Procédures d’enregistrement

Jusqu’à ce que l’IANA demande ou mette en œuvre un processus automatique d’enregistrement de ces éléments, toutes les spécifications doivent faire entrer cette demande dans la section Considérations relatives à l’IANA de leurs documents respectifs. Cette demande doit être sous la forme du gabarit suivant :

URI

L’URI ou l’identifiant PUBLIC qui identifie le composant XML. Si le déclarant demande que l’IANA alloue un URI, ce champ devrait alors être spécifié comme "prière d’allouer".

Contact du déclarant

Individu/organisation qui est le contact d’enregistrement pour le composant à enregistrer. Idéalement, ce sera le nom et les informations pertinentes du contact physique et de réseau. Dans le cas de normes développées par l’IETF, le déclarant sera l’IESG.

XML

C’est l’XML exact à mémoriser dans le registre. Sauf si le début et la fin du fichier sont évidents, le document devrait utiliser le texte "DEBUT" pour marquer le début du fichier et "FIN" pour marquer la fin du fichier. L’IANA insèrera tout texte entre ces deux chaînes (moins toute coupure de page et formatage de RFC inséré par l’éditeur des RFC) dans le fichier conservé dans le répertoire.

5. Considérations pour la sécurité

Les informations conservées par l’IANA seront d’autorité et seront la cible d’attaques. Dans certains cas, comme un schéma XML et les DTD, le contenu conservé par l’IANA peut être entré directement dans un logiciel. Donc, un soin supplémentaire devrait être apporté par l’IANA à maintenir les précautions de sécurité requises pour une localisation de référence importante pour l’Internet.

Au delà de ce problème, il n’y a pas d’autre considération pour la sécurité qui ne soit pas déjà couverte par les autres registres de l’IANA.

6. Considérations relatives à l’IANA

Le présent document cherche à créer un assez grand registre dont l’IANA (sous la direction de l’IESG) sera principalement responsable. La quantité d’efforts requise pour tenir ce registré n’est pas insignifiante et les politiques et procédures entourant tout processus d’approbation ne sont pas triviales. Le registre est fondé sur le principe du premier arrivé, premier servi, mais une spécification est exigée. Quand l’IETF aura un peu plus d’expérience de ce registre, ces politiques pourraient changer.

La [RFC3553] spécifie que tout nouveau registre doit avoir un nom, à allouer sous l’espace de noms 'urn:ietf:params' et doit spécifier la structure de cet espace sous la forme d’un gabarit. L’IANA a créé et entretiendra ce nouveau sous espace de noms :

Registry-name: xml

Spécification : le présent document contient la spécification du registre. L’espace de noms est organisé avec un sous espace de noms qui est <id>.

Répertoire : à allouer conformément aux lignes directrices définies ci-dessus.

Valeur d’indice : le nom de classe.

7. Références normatives

[ISO.8879] Organisation Internationale de normalisation, "Traitement de l’information – Systèmes de texte et de bureau – Langage standard de balisage généralisé (SGML)", Norme internationale ISO 8879, 1986.

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

[RFC3151] N. Walsh, J. Cowan, P. Grosso, "Espace de nom d'URN pour les identifiants publics", août 2001. (Information)

[RFC3553] M. Mealling et autres, "Sous-espace de noms d'URN de l'IETF pour les paramètres de protocole enregistrés", juin 2003. (BCP0073)

[CR-rdf-schema] Brickley, D. and R. Guha, "Resource Description Framework (RDF) Schema Specification 1.0", W3C CR-rdf-schema, mars 2000, <http://www.w3.org/TR/2000/CR-rdf-schema-20000327>.

[REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, octobre 2000, < http://www.w3.org/TR/REC-xml >.

[REC-xml-names] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, janvier 1999, <http://www.w3.org/TR/REC-xml-names >.

[REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, mai 2001, < http://www.w3.org/TR/xmlschema-1/ >.

8. Déclaration de 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 le BCP 11. 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 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.

9. Adresse de l’auteur

Michael Mealling

VeriSign, Inc.

Mountain View, CA

USA

mél : michael@verisignlabs.com

URI : http://www.research.verisignlabs.com

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

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

Le présent document et les traductions qui en sont faites 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 soit 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éfinis dans les processus de normes pour 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 a un objet particulier.

Remerciement

Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.