Internet, le 8 janvier 2008,
Ce document qui est une traduction du document RFC 4646 de l'IETF (Internet Engineering Task Force)
peut comporter des erreurs ou en introduire de nouvelles. Seul le document original à ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt fait référence.
La traduction est disponible sous licence Creative Commons
(http://creativecommons.org/licenses/by/2.0/fr/)
Traduit par Jean-Jacques Solari et relu par Claude Briere de l'Isle.
Network Working Group A. Phillips, rédacteur Document RFC : 4646 (errata) Yahoo! Inc. Document BCP : 47 M. Davis, rédacteur Remplace : 3066 Google Catégorie : Best Current Practice Septembre 2006
Ce document recueille les pratiques exemplaires Internet courantes de la communauté Internet, et il appelle le débat et des suggestions d'amélioration. La distribution de ce mémoire est libre.
Copyright (C) The Internet Society (2006).
Ce document décrit la structure, le contenu, la construction et la sémantique des étiquettes de langues à utiliser lorsque l'on veut indiquer la langue employée dans un objet d'information. Il décrit également comment enregistrer les valeurs des étiquettes de langues et créer des extensions définies par l'utilisateur pour des échanges privés. Ce document, couplé au document RFC 4647, remplace le document RFC 3066, lequel remplaçait le document RFC 1766.
Depuis toujours, les êtres humains sur la planète utilisent nombre de langues. Il y a beaucoup de raisons à vouloir identifier la langue utilisée lors d'une présentation ou d'une demande d'informations.
Il est souvent nécessaire d'identifier les préférences de langues de l'utilisateur afin d'appliquer un traitement approprié. Par exemple, les préférences de langues de l'utilisateur dans un navigateur Web peuvent être utilisées pour sélectionner les pages Web adéquates. Les préférences de langues peuvent aussi servir à sélectionner des outils (tels que des dictionnaires) pour aider au traitement et à la compréhension d'un contenu dans des langues différentes.
En outre, la connaissance de la langue particulière utilisée par un bloc de contenu d'information peut se révéler utile ou même nécessaire pour certains types de traitement, par exemple, une correction orthographique, une synthèse vocale, une transcription en braille ou des rendus d'impression de haute qualité.
Un moyen d'indiquer la langue utilisée est l'étiquetage du contenu d'information avec un identificateur ou une balise (tag). Ces balises peuvent être utilisées pour indiquer les préférences d'utilisateur lors de la sélection d'un contenu d'information ou pour étiqueter d'autres attributs du contenu et des ressources associées.
Les balises peuvent aussi servir à indiquer des attributs de langues supplémentaires du contenu. Par exemple, fournir des informations spécifiques à propos du dialecte, du système d'écriture ou de l'orthographe utilisés dans un document ou dans une ressource peut permettre à l'utilisateur d'obtenir des renseignements dans une forme compréhensible, ou qui sont importantes pour le traitement ou le rendu du contenu donné dans une forme ou un style appropriés.
Ce document décrit un mécanisme avec identificateur particulier (l'étiquette de langue) et une fonction d'enregistrement des valeurs à utiliser pour former les étiquettes. Il définit également un mécanisme de valeurs d'utilisation privée et d'extension future.
Ce document, couplé au [RFC4647], remplace le [RFC3066], lequel remplaçait le [RFC1766]. Pour une liste des changements dans ce document, cf. la section 8.
Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « PEUT » et « OPTIONNEL » dans ce document doivent s'interpréter comme décrit dans le [RFC2119].
Les étiquettes de langues (language tags) aident à identifier les langues, qu'elles soient parlées, écrites, par signes (signed) ou signalées autrement, pour des besoins de communication. Cela inclut les langues construites et artificielles mais exclut les langues dont la destination principale n'est pas la communication humaine, tels que les langages de programmation.
L'étiquette de langue comprend une ou plusieurs parties, appelées sous-étiquettes (subtags). Chaque sous-étiquette se compose d'une séquence de caractères alphanumériques. Les sous-étiquettes sont distinguées et séparées les unes des autres par un TRAIT D'UNION (« - », ABNF [RFC4234] %x2D). Une étiquette de langue se compose d'une sous-étiquette de langue primaire (primary language subtag) et d'une série (éventuellement vide) de sous-étiquettes secondaires, chacune affinant ou rétrécissant le champ de langues identifié par l'étiquette globale.
En général, chaque type de sous-étiquette se distingue par sa longueur, sa position dans l'étiquette et son contenu : les sous-étiquettes sont uniquement reconnaissables par ces caractéristiques. La seule exception est une liste fixe d'étiquettes exonérées (grandfathered tags) enregistrées sous le document RFC 3066 [RFC3066]. Cela permet de construire un analyseur capable d'extraire et d'affecter une information sémantique aux sous-étiquettes, même si les valeurs spécifiques des sous-étiquettes ne sont pas reconnues. L'analyseur n'a donc pas besoin d'avoir une copie à jour (ou même d'en avoir une) du registre de sous-étiquettes pour effectuer la plupart des opérations de recherche et comparaison.
La syntaxe de l'étiquette de langue en ABNF [RFC4234] est la suivante :
Language-Tag = langtag
/ privateuse ; étiquette d'utilisation privée
/ grandfathered ; enregistrements exonérés
langtag = (language
["-" script]
["-" region]
*("-" variant)
*("-" extension)
["-" privateuse])
language = (2*3ALPHA [ extlang ]) ; code ISO 639 le plus court
/ 4ALPHA ; réservé pour une utilisation future
/ 5*8ALPHA ; sous-étiquette de langue enregistrée
extlang = *3("-" 3ALPHA) ; réservé pour une utilisation future
script = 4ALPHA ; code ISO 15924
region = 2ALPHA ; code ISO 3166
/ 3DIGIT ; code UN M.49
variant = 5*8alphanum ; variantes enregistrées
/ (DIGIT 3alphanum)
extension = singleton 1*("-" (2*8alphanum))
singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Lettres seules : x/X est réservé pour une utilisation privée
privateuse = ("x"/"X") 1*("-" (1*8alphanum))
grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum))
; enregistrement exonéré
; Remarque : i est le seul singleton
; à commencer une étiquette exonérée
alphanum = (ALPHA / DIGIT) ; lettres et nombres
Figure n° 1 : Syntaxe ABNF de l'étiquette de langue
Remarque : La syntaxe ABNF de 'variant' comporte une subtilité qui est que les variantes commençant par un chiffre PEUVENT faire quatre caractères de long, tandis que celles commençant par une lettre DOIVENT faire au moins cinq caractères.
Toutes les sous-étiquettes ont une longueur maximale de huit caractères, et les caractères blancs (whitespace) ne sont pas permis dans une étiquette de langue. Pour des exemples d'étiquettes de langues, cf. l'annexe B.
Bien que le document [RFC4234] fasse référence à des octets, notez que les étiquettes de langues décrites dans ce document sont des séquences de caractères pris dans le répertoire US-ASCII [ISO646]. On PEUT utiliser des étiquettes de langues dans des documents et applications avec d'autres codages, tant que ceux-ci englobent le répertoire US-ASCII. Un exemple en serait un document XML utilisant le codage UTF-16LE [RFC2781] d'[Unicode].
Les étiquettes et leurs sous-étiquettes, y compris celles d'utilisation privée et d'extensions, sont insensibles à la casse : il existe des convention de capitalisation de certaines sous-étiquettes, mais on NE DOIT PAS les interpréter comme ayant une signification.
Par exemple :
En revanche, pour les étiquettes définies dans ce document, les lettres US-ASCII dans l'intervalle de 'A' à 'Z' sont équivalentes et directement associées à leurs pendants US-ASCII en minuscules dans l'intervalle de 'a' à 'z'. Ainsi, l'étiquette "mn-Cyrl-MN" n'est pas différente de "MN-cYRL-mn" ni de "mN-cYrL-Mn" (ou toute autre combinaison), et chaque variante comporte la même signification : il s'agit ici du mongol en écriture cyrillique tel qu'utilisé en Mongolie.
Quoique les distinctions de casse n'ont pas de signification dans les étiquettes de langues, la cohérence du formatage et de la présentation des étiquettes aidera les utilisateurs. Il est RECOMMANDÉ d'utiliser le format d'étiquettes et sous-étiquettes du registre. Dans ce format, toutes les sous-étiquettes de deux lettres non en position initiale sont en majuscules, toutes les sous-étiquettes de quatre lettres non en position initiale ont leur première lettre en majuscule, et toutes les autres sous-étiquettes sont en minuscules.
L'espace de noms des étiquettes de langues et leurs sous-étiquettes est administré par l'IANA (Internet Assigned Numbers Authority) [RFC2860], conformément aux règles de la seciton 5 de ce document. Le registre des sous-étiquettes de langues (Language Subtag Registry) conservé par l'IANA est l'origine des sous-étiquettes valides : les autres normes référencées dans cette section donnent les sources originales de ce registre.
La terminologie dans cette section :
Les définitions dans cette section s'appliquent aux diverses sous-étiquettes composant les étiquettes de langues définies dans la section 2.2.8 de ce document.
Les étiquettes de langues sont conçues de sorte que chaque type de sous-étiquette ait une longueur et des restrictions de contenu uniques. Cela permet d'identifier le type de sous-étiquette, même si le contenu de la sous-étiquette en question n'est pas reconnu. Les étiquettes peuvent être analysées et traitées sans référence aux dernières versions des normes sous-jacentes ou au registre IANA, ce qui simplifie la gestion des exceptions associée lors de l'analyse des étiquettes.
Les sous-étiquettes dans le registre IANA, non issues d'une norme sous-jacente, peuvent seulement apparaître à des positions spécifiques dans l'étiquette. Spécifiquement, elles ne peuvent apparaître que comme sous-étiquettes d'une langue primaire ou comme sous-étiquettes de variantes.
Notez que les séquences de sous-étiquettes d'utilisation privée et d'extensions DOIVENT apparaître à la fin de la séquence de sous-étiquettes et NE DOIVENT PAS s'intercaler avec des sous-étiquettes définies ailleurs dans ce document.
Les sous-étiquettes d'une seule lettre et d'un seul chiffre sont réservées pour une utilisation actuelle ou future. Les utilisations actuelles comprennent :
La sous-étiquette d'une seule lettre 'i' est utilisée par quelques étiquettes exonérées, telle que "i-enochian", où elle apparaît toujours en première position et ne peut se confondre avec une extension.
La sous-étiquette de langue primaire (primary language subtag) est la première de l'étiquette de langue (à l'exception des étiquettes d'utilisation privée et de certaines étiquettes exonérées) et elle ne peut être omise. Voici les règles qui s'appliquent à la sous-étiquette de langue primaire :
Au moment de la création de ce document, il n'existait pas d'exemples de telles sous-étiquettes et les enregistrements futurs de ce genre seront caducs (deprecated) : l'enregistrement des langues primaires est fortement RECOMMANDÉ avec la norme ISO 639, et les propositions rejetées par ISO 639/RA seront examinées de près avant un enregistrement auprès de l'IANA.
Remarque : Pour les langues qui ont à la fois un code de deux lettres ISO 639-1 et un code de trois lettres ISO 639-2, seul le code de deux lettres ISO 639-1 est défini dans le registre IANA.
Remarque : Pour les langues qui n'ont pas de code de deux lettres ISO 639-1 et pour lesquelles les codes ISO 639-2/T (terminologiques) et ISO 639-2/B (bibliographiques) diffèrent, le code terminologique est défini dans le registre IANA. À la création de ce document, toutes les langues qui avaient les deux types de codes de trois lettres étaient aussi affectées d'un code de deux lettres ; il n'est pas prévu d'autres affectations de cette nature.
Remarque : Afin d'éviter les problèmes de choix des versions et des sous-étiquettes comme ceux rencontrés lors de la transition entre les documents RFC 1766 et RFC 3066, ainsi que de choix de la nature canonique des sous-étiquettes définies par ce document, le comité consultatif mixte de l'instance d'enregistrement ISO 639 (ISO 639/RA-JAC) a ajouté ce commentaire dans [iso639.prin] :
« Un code de langue déjà dans ISO 639-2 au boint de bloquer ISO 639-1 ne devra pas être ajouté ensuite à ISO 639-1. Ceci pour assurer une cohérence d'utilisation dans le temps, puisque les utilisateurs sont conviés, dans les applications Internet, à utiliser le code de trois lettres si celui de deux lettres de la langue n'est pas disponible ».
Afin d'éviter une instabilité dans la forme canonique des étiquettes, si un code de deux lettres est ajouté à ISO 639-1 pour une langue dont il existe déjà un code de trois lettres dans ISO 639-2, le code de deux lettres NE DOIT PAS être enregistré. Cf. la section 3.4.
Par exemple, si un contenu est étiqueté 'haw' (hawaïen), langue qui actuellement n'a pas pas de code de deux lettres, l'étiquette ne serait pas invalidée si ISO 639-1 devait lui affecter un code de deux lettres par la suite.
Par exemple, l'un des enregistrements IANA exonérés est "i-enochian". La sous-étiquette 'enochian' pourrait être inscrite dans le registre IANA comme sous-étiquette de langue primaire (en supposant qu'ISO 639 n'enregistre pas cette langue d'abord), rendant valides des étiquettes telles que "enochian-AQ" et "enochian-Latn".
Voici les règles qui s'appliquent aux sous-étiquettes de langues étendues (extended language subtags) :
Les enregistrements de sous-étiquettes de langues étendues, une fois dans le registre, DOIVENT contenir exactement un seul champ 'Prefix' indiquant une sous-étiquette ou séquence de sous-étiquettes de langues appropriées, qui DOIT toujours apparaître en préfixe de la sous-étiquette de langue étendue.
Exemple : Dans une révision ou une mise à jour futures de ce document, l'étiquette "zh-gan" (enregistré sous le RFC 3066) pourrait devenir une étiquette non exonérée valide (c'est-à-dire non redondante), où la sous-étiquette 'gan' représenterait le dialecte chinois 'Gan'.
Les sous-étiquettes d'écritures (script subtags) servent à indiquer l'écriture ou les variation du système d'écriture qui distinguent les formes écrites d'une langue ou ses dialectes. Voici les règles qui s'appliquent aux sous-étiquettes d'écritures :
Exemple : L'étiquette "sr-Latn" représente du serbe en écriture latine.
Les sous-étiquettes de régions (region subtags) servent à indiquer les variations linguistiques associées ou appropriées à un pays, un territoire ou une région spécifiques. Typiquement, on utilise une sous-étiquette de région pour indiquer les dialectes ou usages régionaux, ou les conventions d'écriture spécifiques d'une région. On peut aussi utiliser une sous-étiquette de région pour indiquer que le contenu est exprimé adéquatement pour une utilisation à travers une région, par exemple, un contenu espagnol adapté pour l'Amérique latine.
Voici les règles qui s'appliquent aux sous-étiquettes de régions :
Le code "de-CH" représente l'allemand ('de') tel qu'utilisé en Suisse ('CH').
Le code "sr-Latn-CS" représente le serbe ('sr') en écriture latine ('Latn'), tel qu'utilisé en Serbie et dans le Montenegro ('CS').
Le code "es-419" représente l'espagnol ('es') approprié pour la région Amérique latine et Caraïbes définie par les Nations-Unies ('419').
Les sous-étiquettes de variantes (variant subtags) servent à indiquer les variations reconnues facultatives qui définissent une langue ou ses dialectes non couverts par d'autres sous-étiquettes disponibles. Voici les règles qui s'appliquent aux sous-étiquettes de variantes :
Les enregistrements de sous-étiquettes de variantes dans le registre des sous-étiquettes de langues PEUVENT inclure un champ 'Prefix' (ou plusieurs), lequel indique l'étiquette de langue qui ferait un préfixe acceptable (avec d'autres sous-étiquettes si besoin) pour former une étiquette de langue avec la variante. Par exemple, la sous-étiquette 'nedis' a un champ 'Prefix' de "sl", qui convient pour former des étiquettes de langues telles que "sl-nedis" et "sl-IT-nedis", mais pas pour des étiquettes telles que "zh-nedis" ou "it-IT-nedis".
Le code "sl-nedis" représente le dialecte de Natisone ou Nadiza slovène.
Le code "de-CH-1996" représente l'allemand tel qu'utilisé en Suisse et écrit après la réforme de l'orthographe entamée en 1996 après J.C.
La plupart des variantes partageant un préfixe s'excluent mutuellement. Par exemple, les variations orthographiques allemandes '1996' et '1901' NE DEVRAIENT PAS être utilisées dans la même étiquette, car elles représentent des dates de réformes orthographiques différentes. Une variante utilisable en combinaison significative avec une autre variante DEVRAIT inclure un champ 'Prefix' listant cette autre variante dans son enregistrement. Par exemple, si on créait une autre variante de l'allemand 'example', dont l'utilisation avec '1996' a un sens, alors 'example' devrait inclure deux champs 'Prefix' : "de" et "de-1996".
Les extensions fournissent un mécanisme d'extension des étiquettes de langues pour une utilisation dans des applications variées. Cf. la section 3.7. Voici les règles qui s'appliquent aux sous-étiquettes d'extensions (extension subtags) :
Par exemple, si le singleton préfixe 'r' et les sous-étiquettes présentées étaient définies, alors l'étiquette suivante constituerait un exemple valide : "en-Latn-GB-boont-r-extended-sequence-x-private".
Les sous-étiquettes d'utilisation privée (private use subtags) servent à indiquer les distinctions de langue importantes dans un contexte donné de gré à gré. Voici les règles qui s'appliquent aux sous-étiquettes d'utilisation privée :
Par exemple, les utilisateurs utilisant les codes de la publication Ethnologue de SIL International pour identifier la langue pourraient convenir de l'échange d'étiquettes telle que "az-Arab-x-AZE-derbend". Cet exemple contient deux sous-étiquettes d'utilisation privée : la première est 'AZE' et la seconde 'derbend'.
Les étiquettes de langues existantes enregistrées auprès de l'IANA, issues des documents RFC 1766 et/ou RFC 3066, restent valides. Ces étiquettes resteront dans le registre dans les enregistrements exonérés (type "grandfathered") ou bien redondants (type "redundant"). Les étiquettes exonérées contiennent une ou plusieurs sous-étiquettes non définies dans le registre des sous-étiquettes de langues (cf. la section 3). Les étiquettes redondantes sont entièrement constituées par les sous-étiquettes définies précédemment et dont l'enregistrement indépendant est rendu caduc par ce document. Pour plus d'informations, cf. la section 3.8.
Il importe de remarquer que toutes les étiquettes de langues formées selon les directives de ce document étaient soit des étiquettes bien formées légales, soit aurait pu être enregistrées sous le document RFC 3066.
Les mises en œuvre doivent parfois décrire leurs capacités par rapport aux règles et pratiques décrites dans ce document. Ce document décrit deux catégories de mises en œuvre conformes : les processeurs de bonne forme (well-formed processors) et les processeurs de validation (validating processors). Les revendications de conformité DEVRAIENT explicitement mentionner l'une de ces définitions.
Une mise en œuvre qui prétend vérifier la bonne forme des étiquettes de langues DOIT :
On préconise vivement que les processeurs de bonne forme mettent en œuvre les règles de canonisation contenues dans la setion 4.4.
Une mise en œuvre qui prétend être validante DOIT :
Cette section définit le registre des sous-étiquettes de langues et les procédures de conservation et de mise à jour qui y sont associées, ainsi qu'un registre pour les extensions d'étiquettes de langues (cf. la section 3.7).
Le registre des sous-étiquettes de langues contient une liste exhaustive de toutes les sous-étiquettes valides dans les étiquettes de langues. Cela donne aux développeurs une méthode simple et fiable pour valider les étiquettes de langues. Le registre des sous-étiquettes de langues sera tenu de façon à ce qu'il soit possible de valider toutes les sous-étiquettes, sauf celles d'extensions, qui apparaissent dans une étiquette de langue sous les conditions de ce document ou ses révisions ou successeurs. En outre, la significations des diverses sous-étiquettes sera univoque et stable dans le temps. (La signification des sous-étiquettes d'utilisation privée n'est évidemment pas définie par le registre IANA).
Le registre des sous-étiquettes de langues IANA (le registre) consiste en un fichier texte lisible par une machine dans le format décrit dans cette section, plus les copies des fiches d'enregistrement approuvées conformément au processus décrit dans la section 3.5. Les fiches d'enregistrement existantes des étiquettes exonérées et redondantes issues du document RFC 3066 seront conservées comme partie du registre RFC 3066 obsolète. Il ne sera pas créé de fiches d'enregistrement pour les sous-étiquettes initiales restantes.
Le registre est dans le format de texte décrit ci-dessous. Ce format se fonde sur le format record-jar décrit dans [record-jar].
Chaque ligne de texte est limitée à 72 caractères, tous les caractères blancs compris. Les enregistrements sont séparés par des lignes contenant uniquement la séquence "%%" (%x25.25).
Chaque champ peut être vu comme une seule ligne logique de caractères ASCII, comprenant un nom de champ (field-name) et un corps de champ (field-body) séparés par un caractère DEUX-POINTS (%x3A). Par commodité, la partie corps de cette entité conceptuelle peut être scindée en plusieurs lignes, ce qu'on appelle le « pliage » (folding). Le format du registre est décrit par la définition ABNF suivante (selon le [RFC4234]) :
registry = record *("%%" CRLF record)
record = 1*( field-name *SP ":" *SP field-body CRLF )
field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
field-body = *(ASCCHAR/LWSP)
ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note : PERLUÈTE = %x26
UNICHAR = "&#x" 2*6HEXDIG ";"
Figure n° 2 : Définition ABNF du format du registre
La séquence '..' (%x2E.2E) dans un corps de champ signifie un intervalle de valeurs. Cet intervalle représente toutes les sous-étiquettes de même longueur en ordre alphabétique ou numérique dans l'intervalle, en incluant les valeurs mentionnées explicitement. Par exemple, 'a..c' signifie les valeurs 'a', 'b' et 'c', et '11..13' les valeurs '11', '12' et '13'.
Les caractères hors du répertoire US-ASCII [ISO646], ainsi que le caractère PERLUÈTE ("&", %x26), présents dans corps de champ, sont représentés par des références de caractères numériques en notation hexadécimale dans le style utilisé par [XML10] (cf. http://www.w3.org/TR/REC-xml/#dt-charref). Elles se composent d'une séquence "&#x" (%x26.23.78), suivie de la représentation hexadécimale du point de code du caractère dans [ISO10646], suivie d'un point-virgule de fermeture (%x3B). Par exemple, on représenterait le SYMBOLE EURO, U+20AC, par la séquence "€". Notez que la notation hexadécimale PEUT avoir entre deux et six chiffres.
Tous les champs dont le corps de champ contient une valeur de date utilisent le format de date complète défini dans [RFC3339]. Par exemple, "2004-06-28" représente le 28 juin 2004 dans le calendrier grégorien.
Le premier enregistrement dans le fichier contient le seul champ dont le nom de champ est 'File-Date' (cf. la figure n° 3). La valeur de champ de cet enregistrement contient la date de dernière modification de la copie du registre, permettant de comparer des versions différentes du registre. Le registre du site Web de l'IANA est le plus récent. Les versions avec une date antérieure à celle-ci ne sont pas à jour.
File-Date: 2004-06-28 %%
Figure n° 3 : Exemple d'enregistrement File-Date
Les enregistrements suivants représentent les sous-étiquettes dans le registre. Dans un enregistrement, chaque champ ne DOIT apparaître qu'une seule fois au plus, sauf indication contraire ci-dessous. Chaque enregistrement DOIT contenir les champs suivants :
Les champs 'Subtag' ou 'Tag' DOIVENT utiliser des lettres minuscules pour former la sous-étiquette ou l'étiquette, sauf dans deux cas. Les sous-étiquettes dont le champ 'Type' vaut 'script' (autrement dit, les sous-étiquettes définies par ISO 15924) DOIVENT avoir une capitalisation initiale. Les sous-étiquettes dont le champ 'Type' vaut 'region' (autrement dit, les sous-étiquettes définies par ISO 3166) DOIVENT être en majuscules. Ces exceptions reflètent l'utilisation de la casse dans les normes concernées.
Le champ 'Description' qui PEUT apparaître plus d'une fois contient une description de l'étiquette ou de la sous-étiquette dans l'enregistrement. Un des champs 'Description' au moins DOIT être écrit ou transcrit en écriture latine ; le même champ ou les autres PEUVENT aussi inclure une description dans une écriture non latine. Le champ 'Description' sert à des besoins d'identification et on NE DEVRAIT PAS l'utiliser pour représenter le nom natif réel de la langue ou de la variation, ou l'utiliser dans une langue particulière. La plupart des descriptions sont issues directement des normes d'origine telles qu'ISO 639 ou ISO 3166.
Remarque : Les descriptions dans les entrées du registre correspondant à des codes ISO 639, ISO 15924, ISO 3166 ou UN M.49 servent uniquement à indiquer la significaiton de cet identificateur comme défini dans la norme d'origine au moment de son ajout au registre. La description ne remplace pas le contenu de la norme d'origine en question. Les descriptions ne constituent pas les noms localisés en anglais des sous-étiquettes. La localisation ou la traduction des descriptions d'étiquettes ou sous-étiquettes de langues ne sont pas traitées par ce document.
Chaque enregistrement PEUT également contenir les champs suivants :
Le champ 'Deprecated' PEUT être ajouté à n'importe quel enregistrement via le processus de mise à jour décrit dans la section 3.3, ou via le processus d'enregistrement décrit dans la section 3.5. Habituellement, l'ajout d'un champ 'Deprecated' est le fait d'un organisme de normalisation, tel ISO 3166, qui supprime un code. Dans quelques cas historiques, il n'aurait pas été possible de reconstruire la date de caducité originale. Pour ces cas, la date apparaissant dans le registre est approximative. Quoique valides dans les étiquettes de langues, les sous-étiquettes et étiquettes avec un champ 'Deprecated' sont caduques et les processeurs de validation NE DEVRAIENT PAS générer ces sous-étiquettes. Notez qu'un enregistrement contenant un champ 'Deprecated', sans champ 'Preferred-Value' correspondant, n'a aucune mise en correspondance de remplacement.
Le champ 'Preferred-Value' contient une correspondance entre l'enregistrement dans lequel il apparaît et une autre étiquette ou sous-étiquette. La valeur de ce champ est fortement RECOMMANDÉE comme meilleur choix pour représenter la valeur de cet enregistrement lors de la sélection d'une étiquette de langue. Ces valeurs forment trois groupes :
Les enregistrements contenant un champ 'Preferred-Value' DOIVENT aussi avoir un champ 'Deprecated'. Celui-ci contient une date de caducité. Un processeur d'étiquettes de langues peut ainsi utiliser le registre pour construire l'ensemble des étiquettes de langues valides non caduques à une date donnée. En outre, pour toute étiquette donnée, le processeur peut construire l'ensemble des étiquettes de langues valides correspondant à cette étiquette pour toutes les dates jusqu'à la date du registre. La possibilité de réaliser ces correspondances PEUT profiter aux applications qui comparent, sélectionnent ou filtrent le contenu d'après ses étiquettes de langues.
Notez que les correspondances 'Preferred-Value' dans les enregistrements de type 'region' ne représentent pas parfois exactement la même signification que la valeur originale. Les raisons de changer un code de pays sont nombreuses, et l'effet produit sur la formation des étiquettes de langues dépendra de la nature du changement en question.
En particulier, le champ 'Preferred-Value' n'implique pas le rétiquettage du contenu utilisant la sous-étiquette affectée.
Le champ 'Preferred-Value' NE DOIT PAS être modifié une fois créé dans le registre. Le champ PEUT être ajouté aux enregistrements de types "grandfathered" ou "region" conformément aux règles de la section 3.3. En revanche, le champ NE DOIT PAS être ajouté à un enregistrement préexistant dans le registre.
Le champ 'Preferred-Value' dans les enregistrements de types "grandfathered" ou "redundant" contient des étiquettes de langues entières dont l'utilisation à la place de la valeur de l'enregistrement est fortement RECOMMANDÉE. Dans beaucoup de cas, les correspondances ont été créées par la mise en caducité des étiquettes dans la période précédant l'adoption de ce document. Par exemple, l'étiquette "no-nyn" est devenue caduque en faveur du code de langue 'nn' défini par ISO 639-1.
Les enregistrements de type 'variant' PEUVENT avoir plusieurs champs de type 'Prefix'. Les champs supplémentaires de ce type PEUVENT être ajouté à un enregistrement 'variant' via le processus d'enregistrement.
Les enregistrements de type 'extlang' DOIVENT avoir exactement un seul champ 'Prefix'.
La valeur du champ 'Prefix' est constituée d'une étiquette de langue dont l'utilisation des sous-étiquettes est appropriée avec cette sous-étiquette. Par exemple, la sous-étiquette de variante '1996' a un champ 'Prefix' valant "de". Cela signifie que les étiquettes commençant par la séquence "de-" sont appropriées avec cette sous-étiquette, ainsi "de-Latg-1996" et "de-CH-1996" sont toutes deux acceptables, tandis que "fr-1996" est un choix impropre.
Un champ de type 'Prefix' NE DOIT PAS être supprimé d'un enregistrement. La valeur de ce type de champ NE DOIT PAS être modifiée.
Le champ 'Comments' PEUT apparaître plus d'une fois dans un enregistrement. Ce champ PEUT être inséré ou changé via le processus d'enregistrement et sa stabilité n'est pas garantie. Le contenu de ce champ n'est pas règlementé, hormis le besoin d'enregistrer l'information, la recevabilité de la requête, et les limitations du format pratique raisonnable.
Le champ 'Suppress-Script' ne DOIT apparaître que dans les enregistrements dont la valeur du champ 'Type' est 'language'. Ce champ NE DOIT PAS apparaître plus d'une fois par enregistrement. Ce champ indique l'écriture utilisée pour la grande majorité des documents de la langue donnée, qui n'ajoute donc pas d'information distinctive à l'étiquette de langue. Il renforce la compatibilité entre les étiquettes de langues générées selon les règles de ce document et les étiquettes de langues et processeurs ou consommateurs d'étiquettes fondés sur le RFC 3066. Par exemple, presque tous les document islandais sont en écriture latine, la sous-étiquette 'Latn' est donc redondante dans l'étiquette "is-Latn".
Le vérificateur des sous-étiquettes de langues (Language Subtag Reviewer) est nommé par l'IESG (Internet Engineering Steering Group) pour une durée indéterminée, sous réserve de renvoi ou de remplacement à la discrétion de l'IESG. Le vérificateur des sous-étiquettes modère la liste de diffusion ietf-languages, répond aux demandes d'enregistrement et effectue les autres tâches de mise à jour du registre décrites dans la section 3.3. Seul le vérificateur est autorisé à changer, mettre à jour ou ajouter des enregistrements au registre des sous-étiquettes de langues (Language Subtag Registry).
La compétence ou les décisions du vérificateur des sous-étiquettes de langues PEUVENT être pourvues en appel auprès de l'IESG aux mêmes conditions que pour les autres décisions de l'IETF (cf. le [RFC2026]). L'IESG peut annuler ou infirmer la décision du vérificateur, donner des conseils ou prendre d'autres mesures appropriées.
Pour l'entretien du registre, au fur et à mesure de l'affectation ou de l'annulation des codes par les normes ISO 639, ISO 15924, ISO 3166 et UN M.49, le vérificateur des sous-étiquettes de langues DOIT évaluer chaque changement, déterminer s'il y a des conflits avec des entrées préexistantes du registre et soumettre les informations à l'IANA pour incorporation au registre. Si un changement doit avoir lieu et que le vérificateur ne remplit pas ses devoirs dans les meilleurs délais, alors un tiers intéressé PEUT appliquer la procédure dans la section 3.5 pour faire la mise à jour appropriée dans le registre.
Remarque : Les entrées redondantes et exonérées constituent ensemble la liste complète des étiquettes enregistrées sous le [RFC3066]. Les étiquettes redondantes sont celles qu'on peut désormais former en utilisant les sous-étiquettes définies dans le registre selon les règles de la section 2.2. Les entrées exonérées sont celles jamais légales pour ces mêmes dispositions.
L'ensemble des étiquettes redondantes et exonérées est permanent et stable : on NE DOIT PAS ajouter de nouvelles entrées à cette section et on NE DOIT PAS supprimer les entrées existantes. On PEUT convertir les enregistrements de type 'grandfathered' en 'redundant' (cf. l'article 12 dans la section 3.6 pour des précisions). Le processus décisionnel d'exonération initiale des étiquettes puis de leur mise en redondance est décrit dans le document [RFC4645].
Les étiquettes RFC 3066 caduques avant l'adoption de ce document font partie de la liste des étiquettes exonérées, et leurs sous-étiquettes constituantes n'ont pas été incluses comme variantes enregistrées (quoiqu'elles restent éligibles à l'enregistrement). Par exemple, l'étiquette "art-lojban" a été mise caduque en faveur de la sous-étiquette de langue 'jbo'.
Le vérificateur des sous-étiquettes de langues DOIT s'assurer que les nouvelles sous-étiquettes satisfont aux exigences dans la section 4.1, ou soumettre une autre sous-étiquette appropriée comme cela y est décrit. Pour un changement dans le registre ou bien un nouvel ajout, le vérificateur DOIT préparer l'enregistrement entier, en incluant tous les champs, et le transmettre à l'IANA pour insertion dans le registre. Chaque enregistrement à modifier ou à insérer DOIT être transmis dans un message séparé.
Si un enregistrement représente une nouvelle sous-étiquette qui n'existe pas dans le registre courant, alors le sujet du message DOIT contenir le mot "INSERT". Si l'enregistrement représente un changement d'une sous-étiquette existante, alors le sujet du message DOIT contenir le mot "MODIFY". Le message DOIT contenir l'enregistrement de la sous-étiquette à insérer ou à modifier et le nouvel enregistrement 'File-Date'. Voici un exemple du contenu d'un message :
LANGUAGE SUBTAG MODIFICATION
File-Date: 2005-01-02
%%
Type: variant
Subtag: nedis
Description: Natisone dialect
Description: Nadiza dialect
Added: 2003-10-09
Prefix: sl
Comments: This is a comment shown
as an example.
%%
Figure n° 4 : Exemple de fiche de modification d'une sous-étiquette
À chaque fois qu'une entrée est créée ou modifiée dans le registre, l'enregistrement 'File-Date' au début du registre est mis à jour pour refléter la date de modification la plus récente au format de date complète ("full-date") [RFC3339].
Avant de transmettre un nouvel enregistrement à l'IANA, le vérificateur des sous-étiquettes de langues DOIT s'assurer que les valeurs dans le champ 'Subtag' aient la bonne casse, conformément à la description dans la section 3.1.
La stabilité des entrées et leur signification dans le registre est cruciale pour la stabilité à long terme des étiquettes de langues. Les règles dans cette section garantissent que la signification d'une étiquette de langue spécifique sera stable dans le temps et ne changera pas.
Ces règles traitent spécifiquement de la façon dont les changements des codes (y compris l'annulation et la mise en caducité des codes) suivis par ISO 639, ISO 15924, ISO 3166 et UN M.49 sont reflétés dans le registre des sous-étiquettes de langues IANA. Les affectations dans le registre des sous-étiquettes IANA DOIVENT respecter les règles de stabilité suivantes :
On PEUT utiliser le processus d'enregistrement pour ajouter des commentaires à propos de l'annulation du code par l'instance concernée.
Exemple :
Le code de région 'TL' était affecté au pays « Timor-Leste »,
remplaçant le code 'TP' (qui était affecté au « Timor Oriental »
lorsque qu'il était sous administration du Portugal).
La sous-étiquette 'TP' reste valide dans les étiquettes de
langues, mais son enregistrement contient un champ
'Preferred-Value' de 'TL' et son champ 'Deprecated' contient
la date où le nouveau code a été affecté ('2004-07-06').
Remarque : L'instance de conservation/enregistrement (MA/RA) ISO 639 a adopté une politique de stabilité similaire.
La forme de la sous-étiquette de variante est à la discrétion du vérificateur et DOIT être conforme aux autres restrictions sur les sous-étiquettes de variantes dans ce document.
Quiconque souhaite utiliser une sous-étiquette non présente à cette date dans le registre des sous-étiquettes de langues IANA DOIT appliquer la procédure indiquée ici.
Seules les sous-étiquettes de type 'language' et 'variant' seront admises pour un enregistrement indépendant de nouvelles sous-étiquettes. Le traitement des sous-étiquettes, nécessaire pour garder le registre synchronisé avec les normes ISO 639, ISO 15924, ISO 3166 et UN M.49 dans les limites définies par ce document, est décrit dans la section 3.3. Les dispositions de stabilité sont décrites dans la section 3.4.
Cette procédure PEUT aussi être utilisée pour enregistrer ou altérer les informations des champs 'Description', 'Comments', 'Deprecated' ou 'Prefix' dans l'enregistrement d'une sous-étiquette, comme décrit dans la section 3.4. Les changements ne sont pas permis sur tous les autres champs du registre IANA.
L'enregistrement d'une nouvelle sous-étiquette ou la demande de modification sur une étiquette ou une sous-étiquette existante commence par le renseignement du formulaire reproduit ci-dessous par le demandeur. Notez que les rubriques ne sont pas limitées en taille afin que la requête puisse décrire correctement l'enregistrement. Les champs dans la section « Record Requested » DEVRAIENT respecter les conditions dans la section 3.1.
LANGUAGE SUBTAG REGISTRATION FORM
1. Name of requester:
2. E-mail address of requester:
3. Record Requested:
Type:
Subtag:
Description:
Prefix:
Preferred-Value:
Deprecated:
Suppress-Script:
Comments:
4. Intended meaning of the subtag:
5. Reference to published description
of the language (book or article):
6. Any other relevant information:
Figure n° 5 : Le formulaire d'enregistrement d'une sous-étiquette de langue
Le formulaire d'enregistrement d'une sous-étiquette DOIT être envoyé à <ietf-languages@iana.org> pour une période d'examen de deux semaines avant sa soumission à l'IANA. (Cette liste est ouverte et on peut y adhérer en faisant une demande à <ietf-languages-request@iana.org>).
Les sous-étiquettes de variantes sont habituellement enregistrées en vue d'une utilisation avec un ensemble particulier d'étiquettes de langues. Par exemple, la sous-étiquette 'rozaj' est destinée à une utilisation avec des étiquettes de langues commençant par la sous-étiquette de langue primaire "sl", puisque le dialecte de Resia est un dialecte slovène. La sous-étiquette 'rozaj' serait donc appropriée dans des étiquettes telles que "sl-Latn-rozaj" ou "sl-IT-rozaj". Cette information est stockée dans le champ 'Prefix' dans le registre. Les demandes d'enregistrement de variantes DEVRAIENT inclure au moins un champ 'Prefix' dans le formulaire d'enregistrement.
Les sous-étiquettes de langues étendues sont réservées pour une normalisation future. Ces sous-étiquettes devront OBLIGATOIREMENT inclure un seul champ 'Prefix' exactement une fois admises à l'enregistrement.
Le champ 'Prefix' d'une sous-étiquette enregistrée donnée existe dans le registre IANA comme un guide d'utilisation. D'autres préfixes PEUVENT être ajoutés en remplissant un formulaire d'enregistrement supplémentaire. Dans ce formulaire, le champ « Any other relevant information: » DOIT indiquer qu'il s'agit de l'ajout d'un préfixe.
Les demandes pour ajouter un préfixe à une sous-étiquette de variante impliquant une signification sémantique différente seront probablement rejetées. Par exemple, une demande pour ajouter le préfixe "de" à la sous-étiquette 'nedis' afin que l'étiquette "de-nedis" représente un certain dialecte allemand serait rejetée. La sous-étiquette 'nedis' représente un dialecte slovène particulier et le nouvel enregistrement changerait la signification sémantique attribuée à la sous-étiquette. À la place, on DEVRAIT proposer une sous-étiquette séparée.
Le champ 'Description' DOIT contenir une description écrite ou transcrite en écriture latine de l'étiquette à enregistrer ; il PEUT aussi inclure une description dans une écriture non latine. Les caractères non-ASCII DOIVENT être formatés (escaped) en utilisant la syntaxe décrite dans la section 3.1. Le champ 'Description' sert dans un but d'identification et ne représente pas forcément le nom natif réel de la langue ou de la variation, ni n'est dans une langue particulière.
Bien que la stabilité du champ 'Description' même ne soit pas garantie, et que des corrections d'erreurs PUISSENT être entreprises de temps en temps, les tentatives de traductions ou de transcriptions des entrées dans le registre même seront probablement mal vues par la communauté ou rejetées directement, car les changements de cette nature ont un impact sur les dispositions de la section 3.4.
Après expiration de la période de deux semaines, le vérificateur des sous-étiquettes de langues soit transmet l'enregistrement à insérer ou à modifier a iana@iana.org, conformément à la procédure décrite dans la section 3.3, soit rejette la demande à cause d'objections majeures soulevées sur la liste ou de problèmes avec les contraintes dans ce document (qui DOIVENT être explicitement mentionnés). Le vérificateur PEUT également prolonger la période d'examen de deux semaines renouvelables pour permettre un approfondissement des débats. Le vérificateur DOIT annoncer sur la liste si l'enregistrement est accepté, rejeté ou étendu à l'issue de chaque période de deux semaines.
Notez que le vérificateur des sous-étiquettes de langues PEUT émettre des objections sur la liste s'il le désire. L'important est que l'objection DOIVE être publique.
Le demandeur est libre de modifier une application rejetée en ajoutant des informations supplémentaires et de la soumettre à nouveau ; cela relance la période de deux semaines pour des commentaires.
Les décisions prises par le vérificateur des sous-étiquettes de langues PEUVENT faire l'objet d'un appel auprès de l'IESG [RFC2028] aux mêmes conditions que les autres décisions IETF [RFC2026].
Tous les formulaires d'enregistrement approuvés sont disponibles en ligne dans le répertoire http://www.iana.org/numbers.html à la rubrique « Language Tags ».
Les mises à jour ou les changements des enregistrements existants suivent la même procédure que pour les nouveaux enregistrements. Le vérificateur des sous-étiquettes de langues détermine s'il y a consensus pour mettre à jour l'enregistrement à l'issue de la période d'examen de deux semaines ; normalement, les objections du demandeur initial auront un poids supplémentaire dans la formation de ce consensus.
Les enregistrements sont permanents et stables. Une fois enregistrées, les sous-étiquettes ne peuvent plus être supprimées du registre et restent un moyen valide pour indiquer une langue ou une variante spécifiques.
Remarque : Le but du champ 'Description' dans le formulaire d'enregistrement est d'aider les personnes à vérifier si une langue est enregistrée ou à quelle langue ou variation de langue se rapportent une sous-étiquette. Dans la plupart des cas, une référence à une grammaire ou un dictionnaire officiels de cette langue sera utile ; s'il n'en existe pas, d'autres travaux réputés décrivant cette langue ou dans cette langue PEUVENT être appropriés. Le vérificateur des sous-étiquettes de langues détermine ce qui constitue une documentation de référence suffisante. Cette condition n'est pas destinée à exclure des langues ou dialectes particuliers à cause du nombre des locuteurs ou de l'absence d'une orthographe officielle. Les langues minoritaires seront considérées équitablement sur leurs propres mérites.
Les possibilités d'enregistrement de sous-étiquettes ou d'informations au sujet de sous-étiquettes comprennent :
Les sous-étiquettes proposées à l'enregistrement, qui entraînerait la totalité ou une partie d'une étiquette exonérée à devenir redondante mais dont la signification contredit ou altère la signification de l'étiquette exonérée, DOIVENT être rejetées.
Ce document laisse le processus d'enregistrement, décrit dans la section 3.5, décider des sous-étiquettes ou des changements aux sous-étiquettes qui sont appropriés (ou non).
Remarque : Les sous-étiquettes de langues primaires de quatre caractères sont réservées dans l'éventualité d'un ajout futur de codes de quatre lettres dans la famille des normes ISO 639.
La norme ISO 639 définit une instance de conservation pour les ajouts et les changements dans la liste des langues dans ISO 639. Cet organisme est le suivant :
International Information Centre for Terminology (Infoterm)La norme ISO 639-2 définit une instance de conservation pour les ajouts et les changements dans la liste des langues dans ISO 639-2. Cet organisme est le suivant :
Library of CongressL'instance de conservation de la norme ISO 3166 (codes de pays) est la suivante :
ISO 3166 Maintenance AgencyL'instance d'enregistrement pour la norme ISO 15924 (codes d'écritures) est la suivante :
Unicode Consortium Box 391476La division Statistique du secrétariat des Nations-Unis tient un codage statistique normalisé des pays et zones (Standard Country or Area Codes for Statistical Use), et on peut la joindre à :
Statistical Services BranchLes sous-étiquettes d'extensions sont celles introduites par des sous-étiquettes d'un seul caractère (singletons) sauf 'x'. Elles sont réservées à la génération d'identificateurs contenant un composant de langue et sont compatibles avec les applications interprétant les étiquettes de langues.
La structure et la forme des extensions sont définies par ce document afin de pouvoir créer des mises en œuvre qui soient compatibles avec des applications futures utilisant des singletons. En outre, la définition d'un mécanisme de suivi des singletons donnera une stabilité à ce document en réduisant la nécessité probable des révisions et mises à jour futures.
Les sous-étiquettes d'un seul caractère sont affectées par l'IANA en suivant la politique de consensus IETF définie par le [RFC2434]. Cette politique impose le développement d'un document RFC, qui DEVRA définir le nom, l'objectif, les processus et les procédures de conservation des sous-étiquettes. L'instance de conservtion et d'enregistrement, y compris le nom, l'adresse électronique de contact, l'adresse de la liste de diffusion et l'adresse URL du registre, DOIVENT être clairement indiqués dans le RFC. Le document RFC DOIT indiquer ou inclure chaque point suivant :
L'IANA tiendra un registre des sous-étiquettes d'un seul caractère (singleton) allouées. Ce registre DOIT utiliser le format record-jar décrit par la définition ABNF dans la section 3.1. Dès publication d'une extension en tant que document RFC, l'instance de conservation définie dans le RFC DOIT envoyer ce formulaire d'enregistrement à l'adresse iesg@ietf.org, qui DOIT transmettre la demande à iana@iana.org. L'instance de conservation de l'extension DOIT maintenir l'exactitude de l'enregistrement en envoyant une copie complète mise à jour de l'enregistrement à l'adresse iana@iana.org avec pour objet du message « LANGUAGE TAG EXTENSION UPDATE », à chaque fois que le contenu change. Seuls les champs 'Comments', 'Contact_Email', 'Mailing_List' et 'URL' PEUVENT être modifiés lors de ces mises à jour.
Le manquement à suivre cet enregistrement, à suivre le registre correspondant ou à satisfaire aux autres conditions imposées par cette section du document PEUT faire l'objet d'un appel auprès de l'IESG [RFC2028] aux mêmes conditions que les autres décisions de l'IETF (cf. le [RFC2026]) et PEUT aboutir à ce que l'IESG retire ou réaffecte le suivi de l'extension à l'instance.
%% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %%
Figure n° 6 : Format des enregistrements dans le registre des extensions d'étiquettes de langues
Le champ 'Identifier' contient la sous-étiquette d'un seul caractère (singleton) affectée à l'extension. Le projet Internet (Internet-Draft) soumis pour définir l'extension DEVRAIT indiquer quelle lettre ou quel chiffre utiliser, même si l'IESG PEUT changer l'affectation lors de l'approbation du RFC.
Le champ 'Description' contient le nom et la description de l'extension.
Le champ 'Comments' est OPTIONNEL et PEUT contenir une description élargie de l'extension.
Le champ 'Added' contient la date de publication du RFC dans le format "full-date" défini dans le [RFC3339]. Par exemple, 2004-06-28 représente le 28 juin 2004 dans le calendrier grégorien.
Le champ 'RFC' contient le numéro RFC affecté à l'extension.
Le champ 'Authority' contient le nom de l'instance de conservation de l'extension.
Le champ 'Contact_Email' contient l'adresse électronique où contacter l'instance de conservation.
Le champ 'Mailing_List' contient l'adresse URL ou l'adresse électronique d'adhésion à la liste de diffusion utilisée par l'instance de conservation.
Le champ 'URL' contient l'adresse URL du registre de cette extension.
La question de savoir si un projet Internet satisfait aux conditions précédentes et la décision de concéder ou de retenir cette autorité sont l'apanage exclusif de l'IESG et sont soumises au processus normal d'examen et d'appels associé au processus RFC.
Nous mettons vivement en garde les créateurs d'extensions du fait que beaucoup de processeurs (dont la plupart des processeurs de bonne forme) ne reconnaîtront pas de relations spéciales ou de signification inhérente à l'ordre des sous-étiquettes d'extensions. Les créateurs d'extensions DEVRAIENT éviter les relations de sous-étiquettes ou les mécanismes de canonisation qui interfèrent avec les restrictions de correspondance ou de longueur existant parfois dans les protocoles courants où l'extension est utilisée. En particulier, les applications PEUVENT tronquer les sous-étiquettes au cours d'une comparaison (matching) ou d'un garnissage (fitting) dans un espace limité, et il est donc RECOMMANDÉ de placer les informations les plus importantes dans les sous-étiquettes les plus significatives (le plus à gauche) et que la spécification traite gracieusement les sous-étiquettes tronquées.
Lorsqu'on doit utiliser une étiquette de langue dans un protocole connu spécifique, il est RECOMMANDÉ de ne pas placer d'extensions non reconnues par ce protocole dans l'étiquette de langue. En outre, notez que certains protocoles PEUVENT imposer des limites supérieures à la longueur des chaînes utilisées pour stocker ou transporter l'étiquette de langue.
Dès l'adoption de ce document, il est nécessaire d'avoir une version initiale du registre des sous-étiquettes de langues (Language Tag Registry) contenant les diverses sous-étiquettes valides au départ dans les étiquettes de langues. Cette collection de sous-étiquettes, accompagnée d'une description du processus utilisé pour la créer, est décrite par le [RFC4645]. L'IANA DEVRA publier la version initiale du registre décrite par ce document d'après le contenu du [RFC4645]. Une fois celle-ci publiée par l'IANA, les procédures de maintenance, les règles et les processus d'enregistrement dans ce document entreront en vigueur pour les nouveaux enregistrements ou les mises à jour.
Les enregistrements en cours de traitement selon les règles définies dans le [RFC3066] lors de l'adoption de ce document PEUVENT être menés à terme sous les anciennes règles, à la discrétion du vérificateur des sous-étiquettes de langues (comme décrit dans le [RFC3066]). Le vérificateur existant DEVRA faire office de vérificateur des sous-étiquettes de langues en attendant que l'IESG en nomme officiellement un.
Tous les nouveaux enregistrements soumis à l'aide des formulaires ou du format RFC 3066 après l'adoption de ce document et la publication du registre par l'IANA DOIVENT être rejetés.
Une version initiale du registre des extensions des étiquettes de langues (Language Tag Extensions Registry) décrit dans la section 3.7 est également nécessaire. Le registre des extensions DEVRA être initialisé avec un seul enregistrement contenant un seul champ de type 'File-Date' comme paramètre fictif pour les futures affectations.
Cette section décrit comment utiliser les informations dans le registre avec la syntaxe d'étiquette pour choisir, former et traiter les étiquettes de langues.
Nous sommes parfois confronté au choix entre plusieurs étiquettes possibles pour le même ensemble de texte.
L'interopérabilité s'exerce mieux lorsque chacun utilise la même étiquette de langue pour représenter la même langue. Si une application a des exigences qui rendent inapplicables les règles décrites ici, alors elle risque d'être dommageable pour l'interopérabilité. Il est fortement RECOMMANDÉ aux utilisateurs de ne pas définir leurs propres règles pour le choix des étiquettes de langues.
On ne DEVRAIT utiliser des sous-étiquettes que si elles ajoutent des informations distinctives utiles ; les sous-étiquettes superflues interfèrent avec la signification, la compréhension et le traitement des étiquettes de langues. En particulier, les utilisateurs et les développeurs DEVRAIENT suivre les champs 'Prefix' et 'Suppress-Script' dans le registre (défini dans la section 3.1) : ces champs fournissent des indications pour les cas où l'on DEVRAIT (ou NE DEVRAIT PAS) utiliser de sous-étiquettes supplémentaires spécifiques dans une étiquette de langue.
En note particulière, beaucoup d'applications peuvent tirer avantage de l'utilisation des sous-étiquettes d'écritures dans les étiquettes de langues tant que cette utilisation est logique pour un contexte donné. Les sous-étiquettes d'écritures n'étaient pas définies formellement dans le RFC 3066 et leur utilisation peut affecter la comparaison et l'identification des sous-étiquettes dans les mises en œuvre RFC 3066, car celles-ci apparaissent entre les sous-étiquettes de langue primaire et de région. Par exemple, si un utilisateur demande un contenu dans une mise en œuvre de la section 2.5 du [RFC3066] en utilisant l'étendue de langue "en-US", le contenu étiqueté "en-Latn-US" ne correspondra pas à la requête. De ce fait, il importe de savoir quand utiliser les sous-étiquettes d'écritures de façon coutumière et quand ne pas les utiliser. Dans le registre, le champ 'Suppress-Script' permet d'assurer une meilleure compatibilité entre les étiquettes de langues générées conformément aux règles dans ce document et les étiquettes de langues et processeurs ou consommateurs d'étiquettes fondés sur le RFC 3066, en définissant les cas où les utilisateurs NE DEVRAIENT PAS inclure une sous-étiquette d'écriture avec une sous-étiquette de langue primaire particulière.
Les sous-étiquettes de langues étendues (type 'extlang' dans le registre, cf. la section 3.1) apparaissent également entre les sous-étiquettes de langue primaire et de région, et sont réservées pour une normalisation future. Les applications bénéficieront peut-être de leur utilisation judicieuse dans la formation des étiquettes de langues dans le futur. Les mêmes recommandations d'utilisation que pour les sous-étiquettes d'écritures s'appliquent.
Les normes, protocoles et applications, qui référencent ce document normativement mais appliquent des règles différentes de celles données dans cette section, DOIVENT indiquer en quoi la procédure varie de celle décrite ici.
Le choix des sous-étiquettes utilisées pour former une étiquette de langue DEVRAIT être guidé par les règles suivantes :
Par exemple, la sous-étiquette 'de' devrait suffire pour l'étiquetage d'un courrier électronique écrit en allemand, tandis que "de-CH-1996" est, probablement, inutilement précis pour cette tâche.
Par exemple, la sous-étiquette 'Latn' ne devrait pas être utilisée avec la langue primaire 'en', puisque pratiquement tous les documents anglais sont en écriture latine et que cela n'ajoute aucune information distinctive. Par contre, si un document était écrit en anglais mélangeant l'écriture latine à une autre écriture telle que le braille ('Brai'), il serait alors approprié d'indiquer les deux écritures pour aider à la sélection du contenu, telle que l'application d'une feuille de style.
Par exemple, utiliser 'he' pour l'hébreu de préférence à 'iw'.
Par exemple, ne pas utiliser "de-DE-1901-1901".
Afin d'assurer la cohérence de la rétrocompatibilité, ce document contient plusieurs dispositions pour tenir compte d'une instabilité potentielle dans les normes utilisées pour définir les sous-étiquettes composant les étiquettes de langues. Ces dispositions impliquent qu'aucune étiquette de langue créée sous les règles de ce document ne devienne obsolète.
La relation entre l'étiquette et l'information à laquelle celle-ci est liée est définie par le contexte où l'étiquette apparaît. En conséquence, cette section donne seulement des exemples possibles de son utilisation.
Les étiquettes de langues sont apparentées lorsqu'elles contiennent une séquence de sous-étiquettes semblables. Par exemple, si une étiquette de langue B contient l'étiquette de langue A comme préfixe, alors B est plus étroite ou plus spécifique que A. Ainsi, l'étiquette "zh-Hant-TW" est plus spécifique que "zh-Hant".
Cette parenté n'est pas assurée dans tous les cas : spécifiquement, les langues qui commencent par la même séquence de sous-étiquettes ne sont pas garanties mutuellement intelligibles, quoiqu'elles puissent l'être. Par exemple, l'étiquette "az" partage un préfixe avec les deux étiquettes "az-Latn" (azéri en écriture latine) et "az-Cyrl" (azéri en écriture cyrillique). Une personne peut lire couramment dans une écriture et pas dans l'autre, même si le texte est identique. Un contenu étiqueté "az" est très probablement écrit juste dans une seule écriture et peut donc ne pas être intelligible pour un lecteur familier de l'autre écriture.
Le document [RFC3066] n'indiquait aucune limite supérieure à la taille des étiquettes de langues. Bien que le RFC 3066 définissait la sémantique de sous-étiquettes particulières de telle façon que la plupart des étiquettes de langues étaient composées de sous-étiquettes de langues et de régions avec une longueur totale combinée jusqu'à six caractères, des étiquettes enregistrées plus grandes étaient non seulement possibles mais l'étaient en réalité.
Ni la syntaxe d'étiquette de langue ni les autres exigences dans ce document n'imposent une limite supérieure fixe au nombre de sous-étiquettes dans une étiquette de langue (et donc une limite supérieure à la taille d'une étiquette). La syntaxe d'étiquette de langue suggère, selon la langue spécifique, qu'il est parfois nécessaire à certaines applications d'avoir plus de sous-étiquettes (et donc une étiquette plus longue) pour identifier complètement la langue ; ainsi, il est possible d'imaginer des séquences de sous-étiquettes longues ou complexes.
Quelques applications et protocoles sont forcés d'allouer des tailles de mémoire tampon limitées (fixed buffer sizes) ou sinon de limiter la longueur des étiquettes de langues. Une mise en œuvre ou une spécification conformes PEUVENT refuser de stocker les étiquettes de langues excédant une longueur définie. Cette limitation DEVRAIT être clairement documentée, et la documentation DEVRAIT indiquer ce qui arrive aux étiquettes trop longues (par exemple, la génération d'une valeur d'erreur ou une troncature de l'étiquette de langue). Un protocole qui autorise la troncature des étiquettes à une limite arbitraire, sans l'indiquer, peut nuire énormément en changeant la signification des étiquettes de manière substantielle.
En pratique, les étiquettes de la plupart des langues ont besoin de peu de sous-étiquettes et n'approcheront pas les limitations de mémoires tampon raisonnablement dimensionnés, cf. la section 4.1.
Quelques spécifications et protocoles ont des limites à la longueur d'une étiquette mais n'ont pas une limitation de longueur fixe. Par exemple, le [RFC2231] n'a aucune limitation de longueur explicite : la longueur disponible pour l'étiquette de langue est contrainte par celle des autres composants d'en-tête (tel que le nom du jeu de caractères (charset)) couplée à la limite de 76 caractères dans le [RFC2047]. Ainsi, la « limite » pourrait être de 50 caractères ou plus, mais potentiellement être très inférieure.
Les facteurs d'affectation d'une limite de tampon sont les suivants :
L'illustration suivante montre d'où vient la recommandation de 42 caractères. La combinaison des sous-étiquettes de langues et de langues étendues a été choisie pour une compatibilité future. Jusqu'à 15 caractères, cette combinaison est plus longue que la sous-étiquette de langue primaire la plus longue possible (8 caractères) :
language = 3 (ISO 639-2; ISO 639-1 impose 2) extlang1 = 4 (chaque sous-étiquette suivante inclut un '-') extlang2 = 4 (improbable : nécessite préfixe="language-extlang1") extlang3 = 4 (extrêmement improbable) script = 5 (si non supprimé : cf. la section 4.1) region = 4 (UN M.49 ; ISO 3166 impose 3) variant1 = 9 (DOIT avoir language comme préfixe) variant2 = 9 (DOIT avoir language-variant1 comme préfixe) total = 42 caractères
Figure n° 7 : Déduction de la limite de la longueur de langue
La troncature d'une étiquette de langue altère la signification de l'étiquette, et elle DEVRAIT donc être évitée. Toutefois, la troncature des étiquettes de langues est parfois nécessaire à cause d'espaces de tampons limités. Ces troncatures NE DOIVENT PAS autoriser le découpage d'une sous-étiquette en son milieu ou la formation d'étiquettes invalides (par exemple, l'une se terminant par un caractère trait d'union « - »).
Cela implique que les applications ou protocoles qui tronquent les étiquettes DOIVENT le faire graduellement, en supprimant les sous-étiquettes en même temps que le trait d'union « - » qui les précède, en commençant à droite de l'étiquette de langue, jusqu'à ce que l'étiquette soit suffisamment courte pour le tampon en question. Si l'étiquette finale se termine par une sous-étiquette d'un seul caractère, celle-ci et le trait d'union précédent DOIVENT aussi être supprimés. Par exemple :
Étiquette à tronquer : zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 1. zh-Latn-CN-variant1-a-extend1-x-wadegile 2. zh-Latn-CN-variant1-a-extend1 3. zh-Latn-CN-variant1 4. zh-Latn-CN 5. zh-Latn 6. zh
Figure n° 8 : Exemple de troncature d'étiquette
Comme parfois plusieurs processus utilisent une étiquette de langue particulière, les étiquettes de langues DEVRAIENT toujours être créées ou générées dans une forme canonique.
Une étiquette de langue est dans une forme canonique si :
Remarque : Dans de rares cas, la valeur associée aura également une indication 'Preferred-Value'.
Exemple : L'étiquette de langue "en-A-aaa-B-ccc-bbb-x-xyz" est dans une forme canonique, tandis que "en-B-ccc-bbb-A-aaa-X-xyz" est bien formée mais pas dans une forme canonique.
Exemple : L'étiquette de langue "en-BU" (anglais utilisé en Birmanie) n'est pas canonique parce que la sous-étiquette 'BU' a une correspondance canonique vers 'MM' (Myanmar), même si l'étiquette "en-BU" reste valide.
La canonisation des étiquettes de langues n'implique rien en ce qui concerne l'utilisation de lettres majuscules ou minuscules pour le traitement ou la comparaison des sous-étiquettes (comme décrit dans la section 2.1). Toutes les comparaisons DOIVENT être effectuées indépendamment de la casse.
Lors de la canonisation des étiquettes de langues, les processeurs PEUVENT régulariser la casse des sous-étiquettes (ce processus est OPTIONNEL), en reprenant la casse utilisée dans le registre. Notez que cela revient aux règles de capitalisation suivantes : mettre en majuscules toutes les sous-étiquettes de deux lettres non initiales ; mettre en majuscule l'initiale de toutes les sous-étiquettes de quatre lettres non initiales ; mettre en minuscules tout le reste.
Remarque : Le changement de casse (case folding) des lettres ASCII dans certains lieux (locales), si on n'y prend pas garde, produit parfois des valeurs de caractères non-ASCII. Le fichier de la base de données de caractères Unicode "SpecialCasing.txt" définit les cas particuliers connus pour poser des problèmes de ce genre. En particulier, la majuscule de la lettre 'i' (U+0069) en turc et en azéri a pour code U+0130 (LETTRE MAJUSCULE LATINE I POINT EN CHEF). Les développeurs DEVRAIENT indiquer une manipulation de casse indépendante du lieu pour assurer que le changement de casse des sous-étiquettes ne produise pas cette valeur, qui est illégale dans les étiquettes de langues. Par exemple, si on devait mettre en majuscules la sous-étiquette de région 'in' en utilisant les règles de lieu turques, on obtiendrait la séquence U+0130 U+004E au lieu du 'IN' prévu.
Remarque : Si le champ 'Deprecated' apparaît dans un enregistrement du registre sans être accompagné d'un champ 'Preferred-Value', alors cette étiquette, ou sous-étiquette, est caduque sans remplacement. Les processeurs de validation NE DEVRAIENT PAS générer d'étiquettes incluant ces valeurs, même si les valeurs sont canoniques lorsqu'elles apparaissent dans une étiquette de langue.
Une extension DOIT définir les relations existant entre les diverses sous-étiquettes dans l'extension et donc PEUT définir un schéma de canonisation alternatif pour les sous-étiquettes de l'extension. Les extensions PEUVENT définir comment interpréter l'ordre des sous-étiquettes dans l'extension. Par exemple, une extension pourrait définir que ses sous-étiquettes sont dans un ordre canonique lorsqu'elles sont placées dans l'ordre ASCII, c'est-à-dire "en-a-aaa-bbb-ccc" au lieu de "en-a-ccc-bbb-aaa". Une autre extension pourrait définir que l'ordre des sous-étiquettes influence leur signification sémantique (de sorte que "en-b-ccc-bbb-aaa" ait une valeur différente de "en-b-aaa-bbb-ccc"). Quoiqu'il en soit, les spécifications d'extensions DEVRAIENT être conçues en respect des processus typiques décrit dans la section 3.7.
Les sous-étiquettes d'utilisation privée, comme toutes les autres sous-étiquettes, DOIVENT respecter les contraintes de format et de contenu dans la définition ABNF. Les sous-étiquettes d'utilisation privée n'ont aucune signification en dehors de l'accord de gré à gré entre les parties prévoyant d'utiliser ou d'échanger des étiquettes de langues qui les emploient. Les mêmes sous-étiquettes PEUVENT être utilisées avec une signification différente dans un accord de gré à gré séparé. On NE DEVRAIT PAS les utiliser lorsqu'il existe des alternatives et on NE DEVRAIT PAS les utiliser dans un contenu ou dans des protocoles d'utilisation générale.
Les sous-étiquettes d'utilisation privée sont tout simplement inexploitables pour l'échange d'informations sans un accord préalable. La valeur et la signification sémantique des sous-étiquettes d'utilisation privée et des sous-étiquettes utilisées au sein de telles étiquettes de langues ne sont pas définies par ce document.
Les sous-étiquettes définies dans le registre IANA comme ayant une utilisation privée spécifique sont porteuses de plus d'informations qu'une simple sous-étiquette d'utilisation privée préfixée par la sous-étiquette singleton 'x'. Ces informations supplémentaires PEUVENT être utiles pour des applications.
Par exemple, les sous-étiquettes de régions 'AA', 'ZZ' et des intervalles 'QM' à 'QZ' et 'XA' à 'XZ' (dérivées des codes d'utilisation privée ISO 3166) PEUVENT être utilisées pour former une étiquette de langue. Une étiquette telle que "zh-Hans-XQ" véhicule beaucoup d'informations interchangeables publiques à propos de la substance de la langue (à savoir qu'il s'agit de chinois en écriture chinoise simplifiée, convenant pour une certaine région géographique 'XQ'). Quoique la région géographique exacte ne soit pas connue en dehors de l'accord de gré à gré, l'étiquette est porteuse de bien plus d'informations qu'une étiquette opaque telle que "x-someLang", qui ne contient aucune information de langue ou d'écriture hormis dans un cadre privé.
Toutefois, dans certains cas, un contenu balisé avec des sous-étiquettes d'utilisation privée PEUT interagir avec d'autres systèmes de manière différente et peut-être inattendue par rapport aux étiquettes utilisant des sous-étiquettes privées opaques, donc le choix de la meilleure approche dépend parfois du domaine particulier en question.
Cette section traite des processus et obligations nécessaires que doit observer l'IANA pour conserver les registres des sous-étiquettes et des extensions définis par ce document, conformément aux exigences du [RFC2434].
L'impact sur les conservateurs de l'IANA des deux registres définis par ce document se traduira par une faible augmentation de la fréquence des nouvelles entrées ou mises à jour.
Dès l'adoption de ce document, le registre sera initialisé par le document d'accompagnement [RFC4645]. Les critères et le processus de sélection du jeu initial d'enregistrements y seront décrits. Le jeu initial d'enregistrements n'aura aucun impact sur l'IANA, puisque la tâche de le créer sera effectuée à l'extérieur.
Le nouveau registre DOIT être listé sous la rubrique « Language Tags » à http://www.iana.org/numbers.html, en remplaçant les enregistrements existants définis par le [RFC3066]. L'ensemble des formulaires d'enregistrement et des enregistrements RFC 3066 existants DOIT être réintitulé en « Language Tags (Obsolete) » et conservé (mais ni ajouté ni modifié).
Les travaux futurs sur le registre des sous-étiquettes de langues (Language Subtag Registry) DEVRONT se limiter à l'insertion ou au remplacement d'enregistrements entiers préformatés pour l'IANA par le vérificateur des sous-étiquettes de langues (Language Subtag Reviewer) comme décrit dans la section 3.3 de ce document, et à l'archivage des formulaires d'enregistrement transmis.
Chaque enregistrement DOIT être envoyé à l'adresse iana@iana.org avec une ligne objet indiquant s'il s'agit de l'insertion d'un nouvel enregistrement (indiqué par le mot « INSERT » dans la ligne objet) ou du remplacement d'un enregistrement existant (indiqué par le mot « MODIFY » dans la ligne objet). Les enregistrements NE DOIVENT PAS être supprimés du registre.
L'IANA DOIT placer tous les enregistrements insérés ou modifiés dans la section appropriée du registre des sous-étiquettes de langues, en regroupant les enregistrements d'après leur champ 'Type'. Les enregistrements insérés PEUVENT être placés n'importe où dans la section appropriée ; l'ordre des enregisrements n'est pas garanti hormis leur regroupement par 'Type'. Les enregistrements modifiés DOIVENT écraser ceux qu'ils remplacent.
Un nouvel enregistrement 'File-Date' DOIT être inclus pour chaque demande d'insertion ou de modification d'enregistrement. Cet enregistrement DOIT être placé au début du registre. Au cas où la date de l'enregistrement 'File-Date' dans le registre est postérieure à celle de l'enregistrement à insérer ou modifier, l'existant DOIT être conservé.
Le registre des extensions des étiquettes de langues (Language Tag Extensions Registry) sera également généré et envoyé à l'IANA comme décrit dans la section 3.7. Ce registre ne peut contenir au plus que 35 enregistrements, on prévoit donc des changements peu fréquents pour ce registre.
Les futurs travaux de l'IANA sur le registre des extensions des étiquettes de langues se limitent à deux cas. Premièrement, l'IESG PEUT demander de temps en temps l'insertion de nouveaux enregistrements dans ce registre. Ces demandes DOIVENT inclure l'enregistrement à insérer au format exact décrit dans la section 3.7. Deuxièmement, il PEUT y avoir des demandes occasionnelles de l'instance de conservation d'une extension spécifique afin de mettre à jour les coordonnées ou les adresses URL dans l'enregistrement. Ces demandes DOIVENT inclure l'enregistrement entier mis à jour. L'IANA n'est pas tenu de valider les informations fournies, seulement de vérifier son bon formatage. On devrait raisonnablement les identifier comme provenant de l'instance de conservation nommée dans l'enregistrement présent dans le registre.
Les étiquettes de langues utilisées dans une négociation de contenu, comme toute autre information échangée sur l'Internet, peuvent être une source d'inquiétude car elle peuvent être utilisées pour inférer la nationalité de l'émetteur et donc pour identifier des cibles potentielles de surveillance.
Il s'agit d'un cas particulier du problème général selon lequel tout ce qui est envoyé est visible du récepteur et parfois aussi de tiers. Il faut être conscient que de telles préoccupations existent dans certains cas.
L'évaluation de l'ampleur exacte de la menace et des parades possibles est laissée à chaque protocole ou application (cf. le BCP 72 [RFC3552] pour des conseils de pratiques exemplaires actuelles à propos des menaces pour la sécurité et leur prévention).
L'étiquette de langue associée à un élément d'information particulier n'a aucune incidence que ce soit pour déterminer si ce contenu présente d'éventuels homographes. Le fait qu'un texte soit étiqueté comme étant dans une langue ou comme utilisant une sous-étiquette d'écriture particulière n'offre aucune assurance que ce soit qu'il ne contienne pas de caractères d'autres écritures que celle(s) associée(s) à ou indiquée(s) par cette étiquette de langue.
Puisqu'il n'y a aucune limite au nombre des sous-étiquettes de variantes, d'utilisation privée et d'extensions, et par conséquent, aucune limite à la longueur possible d'une étiquette, les mises en œuvre doivent se prémunir des attaques par débordement de tampon. Cf. la section 4.3 pour des précisions sur la troncature des étiquettes de langues susceptible d'avoir lieu en conséquence des préventions contre le débordement de tampon.
Bien que la spécification des sous-étiquettes valides d'une extension (cf. la section 2) DOIT être disponible sur l'Internet, les mises en œuvre NE DEVRAIENT PAS s'attendre mécaniquement à ce qu'elle soit toujours accessible, pour prévenir les attaques par déni de service.
La syntaxe dans ce document impose pour les étiquettes de langues d'utiliser seulement les caractères A-Z, a-z, 0-9 et TRAIT D'UNION, qui sont présents dans la plupart des jeux de caractères, de sorte que la composition des étiquettes de langues ne devrait poser aucun problème en ce qui concerne le jeu de caractères.
Le rendu des caractères en fonction du contenu d'une étiquette de langue n'est pas traité dans ce mémoire. Historiquement, certaines langues dépendaient de l'utilisation de jeux de caractères spécifiques ou d'autres informations pour inférer le rendu d'un caractère spécifique (c'est le cas notamment pour les variations spécifiques de la langue et de la culture des idéogrammes Han, utilisés par le japonais, le chinois et le coréen).
Lorsque des étiquettes de langues sont appliquées à des blocs de texte, les moteurs de rendu utilisent parfois cette information pour décider quelle fonte utiliser en absence d'autres informations, surtout quand les langues avec des traditions d'écriture distinctes utilisent les mêmes caractères.
Les objectifs principaux de cette révision des étiquettes de langues étaient les suivants :
La refonte du registre, d'un contenu d'étiquettes de langues entières vers un contenu de sous-étiquettes, est un élément clé du changement. Une caractéristique importante du RFC 3066 était qu'il autorisait l'utilisation générative de sous-étiquettes. Cela permet d'utiliser des étiquettes générées en toute sincérité, sans les lenteurs d'enregistrement d'étiquettes entières ou l'obligation d'enregistrer toutes les combinaisons qui seraient utiles.
Le choix du placement des sous-étiquettes de langues étendues et d'écritures entre la langue primaire et les sous-étiquettes de régions a fait l'objet d'un débat approfondi. Cette conception a été retenue parce que les schémas de comparaison et de négociation de contenu prévalants reposent sur l'arrangement des sous-étiquettes en ordre de spécificité croissante. C'est-à-dire que l'étiquette qui marque la barrière majeure de l'intelligibilité mutuelle apparaît tout à gauche dans l'étiquette. Par exemple, pour la sélection d'un contenu écrit en azéri, l'écriture (arabe, cyrillique ou latine) représente une barrière plus grande à la compréhension que des variations régionales (celles associées à l'Azerbaïdjan ou à l'Iran par exemple). Les personnes qui préfèrent des documents dans une écriture particulière, et qui peuvent faire avec les différences régionales mineures, peuvent ainsi sélectionner le contenu approprié. Les applications ne traitant pas le contenu écrit continueront d'omettre ces sous-étiquettes.
Le document anticipe également les caractéristiques de la norme ISO 639-3 avec l'ajout des sous-étiquettes de langues étendues ainsi que la possibilité d'utiliser d'autres parties de la norme ISO 639 pour la formation des étiquettes de langues dans le futur.
L'utilisation et la définition des étiquettes d'utilisation privée ont également été revues afin que l'on puisse employer des sous-étiquettes d'utilisation privée pour étendre ou modifier des étiquettes définies et pour sortir autant d'information que possible du cadre privé vers la structure régulière.
Toutes ces modifications ont pour but de réduire ou d'éliminer les besoins de révisions futures de ce document.
Les changements spécifiques dans ce document pour réaliser cet objectif sont les suivants :
Toute liste de contributeurs est forcément incomplète ; veuillez ne considérer la suivante que comme une sélection prise dans le groupe de personnes ayant contribué à faire de ce document ce qu'il est aujourd'hui.
Les contributeurs des RFC 3066 et RFC 1766, les précurseurs de ce document, ont apporté énormément, directement ou indirectement, à ce document et sont généralement responsables du succès des étiquettes de langues.
Les personnes suivantes (en ordre alphabétique) ont participé à ce document ou aux RFC 1766 et 3066 :
Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet, Nathaniel Borenstein, Karen Broome, Eric Brunner, Sean M. Burke, M.T. Carrasco Benitez, Jeremy Carroll, John Clews, Jim Conklin, Peter Constable, John Cowan, Mark Crispin, Dave Crocker, Elwyn Davies, Martin Duerst, Frank Ellerman, Michael Everson, Doug Ewell, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Joel Halpren, Elliotte Rusty Harold, Paul Hoffman, Scott Hollenbeck, Richard Ishida, Olle Jarnefors, Kent Karlsson, John Klensin, Erkki Kolehmainen, Alain LaBonte, Eric Mader, Ira McDonald, Keith Moore, Chris Newman, Masataka Ohta, Dylan Pierce, Randy Presuhn, George Rhoten, Felix Sasaki, Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto Stolz, Tex Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois Yergeau et beaucoup beaucoup d'autres.
Un très grand merci à Harald Tveit Alvestrand, qui est à l'origine des RFC 1766 et 3066, et sans qui ce document n'aurait pas été possible. Un grand merci à Michael Everson, qui fut le vérificateur des étiquettes de langues pratiquement tout le temps depuis la publication du RFC 1766. Un grand merci à Doug Ewell, pour avoir produit le premier registre de sous-étiquettes complet et pour son travail à créer un analyseur syntaxique de test pour vérifier les étiquettes de langues.
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).