Lisez-moi S.V.P. 

W3C

Adresses IRI étendues existantes pour l'identification des ressources XML

Note de groupe de travail du W3C du 3 novembre 2008

Cette version :
http://www.w3.org/TR/2008/NOTE-leiri-20081103/
Dernière version :
http://www.w3.org/TR/leiri/
Version précédente :
Rédacteurs :
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>
Richard Tobin, University of Edinburgh <richard@inf.ed.ac.uk>
Norman Walsh, Mark Logic Corporation <norman.walsh@marklogic.com>

Ce document est également disponibles dans les formats non normatifs suivants : XML.


Résumé

Pour des raisons historiques, certains formats ont admis des variantes d'adresses IRI dont la syntaxe est moins restrictive, par exemple les identificateurs de système XML et les adresses de type anyURI XML Schema du W3C. Ce document fournit la définition et le nom — adresse LEIRI (Legacy Extended IRI) — de ces variantes pour une consultation rapide. Il faut utiliser ces variantes avec précaution ; elles nécessitent un autre traitement avant d'être complètement interchangeables en tant qu'adresses IRI. Les nouveaux protocoles et formats ne devraient pas utiliser d'adresses IRI étendues existantes (Legacy Extended IRIs).

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On trouvera la liste des publications courantes du W3C et la dernière révision de ce document technique à l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ce document est une note de groupe de travail du W3C. Il a été développé par le groupe de travail XML Core, sous l'égide de l'activité XML du domaine Ubiquitous Web du W3C.

La publication en tant que note de groupe de travail n'implique pas l'approbation des membres du W3C. C'est une version de travail qui peut être mise à jour, remplacée ou rendue obsolète par d'autres documents à tout instant. Il n'est pas approprié de citer ce document comme étant autre chose qu'un travail en cours.

Veuillez envoyer les commentaires à propos de ce document à xml-editor@w3.org (archives).

Ce document est fondé étroitement sur une documentation tirée de [IRI-bis], en particulier les sections 2.2 ABNF des références IRI et des adresses IRI et 7 Adresses IRI étendues existantes, incluses ici avec la permission de leurs auteurs. Il est destiné à fournir la base d'une référence normative unique pour beaucoup de standards liés à XML ou HTML en avance de la publication finale de [IRI-bis] en tant que document RFC. Lorsqu'adviendra la publication, cette spécification sera republiée afin de la référencer, au lieu des extraits donnés plus loin.

Ce document a été produit par un groupe œuvrant sous couvert de la politique des brevets du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevets effectuées en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour divulguer un brevet. Toute personne qui aurait connaissance réelle d'un brevet qu'elle estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique des brevets du W3C.

Table des matières

Annexe

A Références


1 Introduction

Pour des raisons historiques, certains formats ont admis des variantes d'adresses IRI [RFC3987] dont la syntaxe est moins restrictive, par exemple les identificateurs de système XML et les adresses de type anyURI XML Schema du W3C. Ce document fournit la définition et le nom — adresse LEIRI (Legacy Extended IRI) — de ces variantes pour une consultation rapide. Il faut utiliser ces variantes avec précaution ; elles nécessitent un autre traitement avant d'être complètement interchangeables en tant qu'adresses IRI. Les nouveaux protocoles et formats ne devraient pas utiliser d'adresses IRI étendues existantes (Legacy Extended IRIs). Les dispositions dans ce document s'appliquent également aux références IRI étendues existantes (Legacy Extended IRI references).

2 Notation

Dans ce document, les caractères sont désignés par un préfixe « U+ » suivi de quatre ou six chiffres hexadécimaux.

Les mots-clés doit, ne doit pas, obligatoire, devra, ne devra pas, devrait, ne devrait pas, recommandé et optionnel doivent s'interpréter selon le document [RFC2119].

3 Syntaxe des adresses LEIRI

La syntaxe des adresses IRI étendues existantes (adresses LEIRI) et des références LEIRI est la même que celle des adresses IRI et des références IRI, hormis la redéfinition de la production ucschar. La syntaxe de cette production ABNF est décrite dans le document [RFC5234]. Les nombres des caractères proviennent du jeu universel de caractères (JUC), ou jeu UCS (Universal Character Set), sans impliquer de quelconque codage binaire réel. Les terminaux dans les productions ABNF sont des caractères et non des octets (bytes).

Pour la cohérence avec le document [RFC3987] traitant des adresses IRI, un logiciel compatible LEIRI générique ne devrait pas vérifier la conformité des adresses LEIRI avec cette syntaxe.

Certaines productions sont ambiguës. L'algorithme du « premier trouvé l'emporte » — appelé également algorithme « avare » (greedy) — s'applique. Pour les détails, cf. [RFC3986].

Productions changées par rapport au RFC3986
[1]    LEIRI    ::=    scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]
[2]    ihier-part    ::=    "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-rootless
/ ipath-empty
[3]    LEIRI-reference    ::=    LEIRI / irelative-ref
[4]    absolute-LEIRI    ::=    scheme ":" ihier-part [ "?" iquery ]
[5]    irelative-ref    ::=    irelative-part [ "?" iquery ] [ "#" ifragment ]
[6]    irelative-part    ::=    "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-noscheme
/ ipath-empty
[7]    iauthority    ::=    [ iuserinfo "@" ] ihost [ ":" port ]
[8]    iuserinfo    ::=    *( iunreserved / pct-encoded / sub-delims / ":" )
[9]    ihost    ::=    IP-literal / IPv4address / ireg-name
[10]    ireg-name    ::=    *( iunreserved / pct-encoded / sub-delims )
[11]    ipath    ::=    ipath-abempty /* commence par « / » ou est vide */
/ ipath-absolute /* commence par « / » mais pas « // » */
/ ipath-noscheme /* commence par un segment sans caractère deux-points */
/ ipath-rootless /* commence par un segment */
/ ipath-empty /* zéro caractère */
[12]    ipath-abempty    ::=    *( "/" isegment )
[13]    ipath-absolute    ::=    "/" [ isegment-nz *( "/" isegment ) ]
[14]    ipath-noscheme    ::=    isegment-nz-nc *( "/" isegment )
[15]    ipath-rootless    ::=    isegment-nz *( "/" isegment )
[16]    ipath-empty    ::=    0<ipchar>
[17]    isegment    ::=    *ipchar
[18]    isegment-nz    ::=    1*ipchar
[19]    isegment-nz-nc    ::=    1*( iunreserved / pct-encoded / sub-delims / "@" )
/* segment de longueur non nulle sans caractère deux-points « : » */
[20]    ipchar    ::=    iunreserved / pct-encoded / sub-delims / ":"
/ "@"
[21]    iquery    ::=    *( ipchar / iprivate / "/" / "?" )
[22]    ifragment    ::=    *( ipchar / "/" / "?" )
[23]    iunreserved    ::=    ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
[24]    iprivate    ::=    %xE000-F8FF / %xE0000-E0FFF / %xF0000-FFFFD
/ %x100000-10FFFD
Productions inchangées par rapport au RFC3986
[25]    scheme    ::=    ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
[26]    port    ::=    *DIGIT
[27]    IP-literal    ::=    "[" ( IPv6address / IPvFuture ) "]"
[28]    IPvFuture    ::=    "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
[29]    IPv6address    ::=    6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
[30]    h16    ::=    1*4HEXDIG
[31]    ls32    ::=    ( h16 ":" h16 ) / IPv4address
[32]    IPv4address    ::=    dec-octet "." dec-octet "." dec-octet "." dec-octet
[33]    dec-octet    ::=    DIGIT /* 0-9 */
/ %x31-39 DIGIT /* 10-99 */
/ "1" 2DIGIT /* 100-199 */
/ "2" %x30-34 DIGIT /* 200-249 */
/ "25" %x30-35 /* 250-255 */
[34]    pct-encoded    ::=    "%" HEXDIG HEXDIG
[35]    unreserved    ::=    ALPHA / DIGIT / "-" / "." / "_" / "~"
[36]    reserved    ::=    gen-delims / sub-delims
[37]    gen-delims    ::=    ":" / "/" / "?" / "#" / "[" / "]" / "@"
[38]    sub-delims    ::=    "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Production ucschar modifiée
[39]    ucschar    ::=    " " / "<" / ">" / '"' / "{" / "}" / "|"
/ "\" / "^" / "`" / %x0-1F / %x7F-D7FF
/ %xE000-FFFD / %x10000-10FFFF

La restriction portant sur les caractères de formatage bidirectionnels dans la section 4.1 de [RFC3987] est levée. La production iprivate devient redondante.

Les formats qui utilisent des adresses LEIRI peuvent restreindre encore les caractères qui y sont admis, soit implicitement du fait que le format en tant que tel n'admet pas certains caractères, soit explicitement. Un exemple de caractère non admis implicitement serait celui du caractère NUL (U+0000). En revanche, tous les caractères admis dans les adresses IRI doivent encore l'être.

4 Conversion des adresses LEIRI en adresses IRI

Pour convertir une adresse (ou une référence) LEIRI en une adresse (ou une référence) IRI, chaque caractère admis dans une adresse (ou une référence) LEIRI mais pas dans une adresse (ou une référence) IRI — cf. la section 5 Caractères admis dans les adresses LEIRI mais pas les adresses IRI —, doit recevoir un codage en pourcentage (percent-encoded) en suivant les étapes suivantes :

  1. Convertir le caractère en une séquence d'un ou plusieurs octets en utilisant UTF-8 [RFC3629] ;

  2. Convertir chaque octet selon la forme %HH, où HH est la notation hexadécimale de la valeur de l'octet. Notez que ce mécanisme de codage en pourcentage est identique à celui de la section 2.1 de [RFC3986]. Pour limiter la variabilité, la notation hexadécimale devrait employer des lettres en majuscules ;

  3. Remplacer le caractère d'origine par la séquence de caractères obtenue (c'est-à-dire une séquence de triplets %HH).

La conversion d'une adresse LEIRI en une adresse IRI ou URI doit seulement être entreprise si absolument nécessaire et aussi tard que possible dans une chaîne de traitement. En particulier, ni le processus de conversion d'une adresse LEIRI relative en une adresse absolue, ni le processus de transmission d'une adresse LEIRI à un processus ou une composante logicielle chargés de la résoudre ne devrait générer un codage en pourcentage.

5 Caractères admis dans les adresses LEIRI mais pas les adresses IRI

Cette section fournit une liste des groupes de caractères et de points de code (code points) admis dans les adresses LEIRI mais pas dans les adresses IRI, ou sinon uniquement dans la partie interrogation (query part). Pour chaque groupe de caractères, nous donnons également des conseils d'utilisation pour ces caractères, en insistant sur les raisons de ne pas les employer.

Caractère espace (U+0020)

Certains formats et applications utilisent le caractère espace comme délimiteur (delimiter), par exemple pour les éléments d'une liste. L'annexe C du document [RFC3986] signale également qu'il faudra peut-être ajouter des caractères blancs (whitespace) pour l'affichage ou l'impression des adresses URI longues ; c'est la même chose pour les adresses IRI longues. Cela veut dire que des espaces peuvent disparaître ou que les adresses LEIRI soient interprétées comme deux (ou plus) adresses IRI distinctes.

Caractères délimiteurs « < » (U+003C), « > » (U+003E) et « " » (U+0022)

L'annexe C du document [RFC3986] suggère l'emploi de guillemets doubles ("http://example.com/") et de chevrons (<http://example.com/>) comme délimiteurs pour les adresses URI dans du texte ordinaire (plain text). Ces conventions courantes s'appliquent également aux adresses IRI. Les adresses LEIRI qui utiliseront ces caractères seront tronquées au mauvais endroit.

Caractères à risques (unwise characters) « \ » (U+005C), « ^ » (U+005E), « ` » (U+0060), « { » (U+007B), « | » (U+007C) et « } » (U+007D)

Ces caractères avaient été exclus à l'origine des adresses URI parce que leurs points de code respectifs étaient attribués à des caractères graphiques différents dans quelques codages 7-bit ou 8-bit. Malgré le passage à Unicode, quelques uns de ces caractères sont toujours affichés différemment à l'occasion sur certains systèmes, par exemple U+005C comme symbole yen japonais. Également, le fait que ces caractères ne soient pas employés dans les adresses URI ou IRI en a encouragé l'utilisation ailleurs dans des contextes pouvant inclure des adresses URI ou IRI. Si une adresse LEIRI avec un tel caractère était utilisée dans un tel contexte, elle serait interprétée de façon parcellaire (piecemeal).

Caractères de contrôle (caractères de controle C0, caractères de contrôle DEL et C1, U+0000 - U+001F U+007F - U+009F)

Il n'y a aucun moyen fiable de transmettre ces caractères sauf potentiellement dans une forme électronique. Et quand bien même, certaines composantes logicielles pourraient filtrer silencieusement certains d'entre eux ou interrompre entièrement le traitement en les rencontrant. Ces caractères peuvent affecter l'affichage du texte de manière subtile, inaperçue, ou de manière exagérée, globale et irréversible selon les matériels et les logiciels concernés. L'utilisation de ces caractères peut permettre à des utilisateurs malveillants de manipuler l'affichage d'une adresse LEIRI et son contexte.

Caractères de formatage bidirectionnel (U+200E, U+200F, U+202A-202E)

Ces caractères affectent l'ordre d'affichage des caractères. Les adresses LEIRI contenant ces caractères ne peuvent pas être reconvertis (converted back) dans une forme électronique (ordre logique) sans ambiguïté. Ces caractères peuvent permettre à des utilisateurs malveillants de manipuler l'affichage d'une adresse LEIRI et son contexte.

Caractères spéciaux (U+FFF0-FFFD)

Ces points de code fournissent des fonctionnalités au-delà de l'utile dans une adresse LEIRI, par exemple identification de l'ordre des octets, annotation et remplacements des caractères et objets inconnus. Leur utilisation et interprétation dans une adresse LEIRI n'ont pas de raison d'être et peuvent conduire à des variations d'affichage gênantes.

Points de code d'utilisation privée (U+E000-F8FF, U+F0000-FFFFD, U+100000-10FFFD)

L'affichage et l'interprétation de ces points de code sont par définition indéterminés hors d'un accord privé. Ces points de code ne conviennent donc pas à une utilisation sur l'Internet. Ils ne sont pas interopérables et peuvent avoir des effets imprévisibles.

Étiquettes (U+E0000-E0FFF)

Ces caractères offent un moyen d'inclure des étiquettes de langue dans un texte ordinaire Unicode. Ils ne conviennent pas aux adresses LEIRI car l'information de langue dans les identificateurs ne peut pas être entrée, transmise (par exemple, sur un support visuel tel que le papier) ou reconnue de façon fiable.

Non-caractères (U+FDD0-FDEF, U+1FFFE-1FFFF, U+2FFFE-2FFFF, U+3FFFE-3FFFF, U+4FFFE-4FFFF, U+5FFFE-5FFFF, U+6FFFE-6FFFF, U+7FFFE-7FFFF, U+8FFFE-8FFFF, U+9FFFE-9FFFF, U+AFFFE-AFFFF, U+BFFFE-BFFFF, U+CFFFE-CFFFF, U+DFFFE-DFFFF, U+EFFFE-EFFFF, U+FFFFE-FFFFF, U+10FFFE-10FFFF)

Ces points de code sont définis comme étant des non-caractères. Les applications peuvent en utiliser quelques uns en interne mais ne sont pas préparées pour les échanger.

Pour référence, nous listons également ici les points de code et unités de code (code units), qui ne sont même pas permis dans les adresses LEIRI :

Unités de code de substitution (U+D800-U+DFFF)

Celles-ci ne représentent pas des points de code Unicode.

A Références

RFC2119
Bradner, S., Mots-clés à utiliser dans les documents RFC pour indiquer les niveaux d'exigence, BCP 14, RFC 2119, IETF, mars 1997. Disponible en ligne à http://tools.ietf.org/html/bcp14 et http://tools.ietf.org/html/rfc2119.
RFC5234
Crocker, D. et P. Overell, rédacteurs, Forme BNF augmentée pour les spécifications de syntaxe : ABNF, RFC 5234/STD 68, IETF, janvier 2008. Disponible en ligne à http://tools.ietf.org/html/rfc5234.
RFC3629
Yergeau, F., UTF-8 — Un format de transformation de ISO 10646, STD 63, RFC 3629, IETF, novmebre 2003. Disponible en ligne à http://tools.ietf.org/html/rfc3629.
RFC3986
Berners-Lee, T., R. Fielding et L. Masinter, Identificateur de ressource uniforme (URI) — Syntaxe générique, STD 66, RFC 3986, IETF, janvier 2005. Disponible en ligne à http://tools.ietf.org/html/rfc3986.
RFC3987
Identificateurs de ressource internationalisés (IRI), RFC 3987, Dürst, M. et M. Suignard, rédacteurs. IETF, 2005. Disponible en ligne à http://tools.ietf.org/html/rfc3987.
IRI-bis
Identificateurs de ressource internationalisés (IRI), draft-duerst-iri-bis-04, Dürst, M. et M. Suignard, rédacteurs. IETF, 2008. Disponible en ligne à http://tools.ietf.org/html/draft-duerst-iri-bis-04.