------------------------------------------------------------------------ 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 Yahoo! Inc. Document BCP : 47 M. Davis, rédacteur Remplace : 3066 Google Catégorie : Best Current Practice Septembre 2006 Les étiquettes d'identification de langues Statut de ce mémoire 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. Notice de droits d'auteur Copyright (C) The Internet Society (2005). Résumé 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. Table des matières 1. Introduction 2. L'étiquette de langue 2.1. La syntaxe 2.2. Sources et interprétation des sous-étiquettes de langues 2.2.1. La sous-étiquette de langue primaire 2.2.2. Les sous-étiquettes de langues étendues 2.2.3. La sous-étiquette d'écriture 2.2.4. La sous-étiquette de région 2.2.5. Les sous-étiquettes de variantes 2.2.6. Les sous-étiquettes d'extensions 2.2.7. Les sous-étiquettes d'utilisation privée 2.2.8. Les enregistrements RFC 3066 préexistants 2.2.9. Les catégories de conformité 3. Le format et l'entretien du registre 3.1. Le format du registre des sous-étiquettes de langues IANA 3.2. Le vérificateur des sous-étiquettes de langues 3.3. La conservation du registre 3.4. La stabilité des entrées du registre IANA 3.5. La procédure d'enregistrement des sous-étiquettes 3.6. Les possibilités d'enregistrement 3.7. Les extensions et le registre des extensions 3.8. L'initialisation des registres 4. La formation et le traitement des étiquettes de langues 4.1. La sélection des étiquettes de langues 4.2. La signification de l'étiquette de langue 4.3. Les facteurs de longueur 4.3.1. Le travail avec des mémoires tampon limitées 4.3.2. La troncature des étiquettes de langues 4.4. La canonisation des étiquettes de langues 4.5. Observations sur les sous-étiquettes d'utilisation privée 5. Les devoirs de l'IANA 5.1. Le registre des sous-étiquettes de langues 5.2. Le registre des extensions 6. Observations sur la sécurité 7. Observations sur les jeux de caractères 8. Les changements depuis le RFC 3066 9. Références 9.1. Références normatives 9.2. Références informatives Annexe A. Remerciements Annexe C. Exemples d'étiquettes de langues (informatif) 1. Introduction 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]. 2. L'étiquette de langue 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. 2.1. La syntaxe 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 : o La norme [ISO639-1] recommande d'écrire les codes de langues en minuscules ('mn' pour le mongol). o La norme [ISO3166-1] recommande d'écrire les codes de pays en majuscules ('MN' pour la Mongolie). o La norme [ISO15924] recommande d'écrire les codes d'écritures en minuscules et la lettre initiale en majuscule ('Cyrl' pour le cyrillique). 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. 2.2. Sources et interprétation des sous-étiquettes de langues 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 : o Le terme « étiquette(s) » se rapporte à une (ou plusieurs) étiquette de langue complète, telle que "fr-Latn-CA". Dans ce document, les exemples d'étiquettes sont entre guillemets doubles ("en-US"). o Le terme « sous-étiquette » se rapporte à une section spécifique de l'étiquette, délimitée par un trait d'union, telle la sous-étiquette 'Latn' dans "fr-Latn-CA". Dans ce document, les exemples de sous-étiquettes sont entre guillemets simples ('Latn'). o Le terme « code(s) » se rapporte aux valeurs définies dans des normes externes (et qui sont utilisées comme sous-étiquettes dans ce document). Par exemple, 'Latn' est un code d'écriture [ISO15924] utilisé pour définir la sous-étiquette d'écriture 'Latn' dans une étiquette de langue. Dans ce document, les exemples de codes sont entre guillemets simples ('en', 'Latn'). 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 : o La sous-étiquette d'une seule lettre 'x' est réservée pour introduire une séquence de sous-étiquettes d'utilisation privée. L'interprétation des sous-étiquettes d'utilisation privée est définie exclusivement de gré à gré (private agreement), et non par les règles de cette section, ou dans une norme ou un registre définis dans ce document. o Toutes les autres sous-étiquettes d'un seul caractère sont réservées à l'introduction des séquences de sous-étiquettes d'extensions normalisées décrites dans la section 3.7. 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. 2.2.1. La sous-étiquette de langue primaire 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 : 1. Toutes les sous-étiquettes de langues de deux lettres ont été définies dans le registre IANA d'après les affectations trouvées dans la norme ISO 639-1, « ISO 639-1:2002, Codes for the representation of names of languages -- Part 1: Alpha-2 code » [ISO639-1], ou d'après les affectations effectuées ensuite par l'instance de conservation (maintenance agency) de la norme ISO 639-1 ou le conseil d'une instance de normalisation (governing standardization bodies). 2. Toutes les sous-étiquettes de langues de trois lettres ont été définies dans le registre IANA d'après les affectations trouvées dans la norme ISO 639-2, « ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1 » [ISO639-2], ou d'après les affectations effectuées ensuite par l'instance de conservation de la norme ISO 639-2 ou le conseil d'une instance de normalisation. 3. Les sous-étiquettes dans l'intervalle 'qaa' à 'qtz' sont réservées pour une utilisation privée dans les étiquettes de langues. Ces sous-étiquettes correspondent aux codes réservés par la norme ISO 639-2 pour une utilisation privée. Ces codes PEUVENT être utilisés pour des sous-étiquettes de langues primaires non enregistrées (au lieu d'utiliser des sous-étiquettes d'utilisation privée après 'x-'). Veuillez consulter la section 4.5 pour plus d'informations à propos des sous-étiquettes d'utilisation privée. 4. Toutes les sous-étiquettes de langues de quatre lettres sont réservées pour une possible normalisation future. 5. Toutes les sous-étiquettes de langues longues de 5 à 8 lettres dans le registre IANA ont été définies via le processus d'enregistrement décrit dans la section 3.5 et PEUVENT servir à former 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. 6. La sous-étiquette d'une seule lettre 'x' comme sous-étiquette primaire indique que l'étiquette de langue se compose exclusivement de sous-étiquettes dont la signification est définie de gré à gré. Par exemple, dans l'étiquette "x-fr-CH", on NE DEVRAIT PAS prendre les sous-étiquettes 'fr' et 'CH' pour représenter le français parlé en Suisse (ou toute autre valeur dans le registre IANA) à moins d'un accord de gré à gré mis en place en ce sens. Cf. la section 4.5. 7. La sous-étiquette d'une seule lettre 'i' est utilisées par quelques étiquettes exonérées (cf. la section 2.2.8) telle que "i-klingon" et "i-bnn". (D'autres étiquettes exonérées ont une sous-étiquette de langue primaire en première position). 8. On NE DOIT PAS affecter d'autres valeurs à la sous-étiquette primaire sauf par révision ou mise à jour de ce document. 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". 2.2.2. Les sous-étiquettes de langues étendues Voici les règles qui s'appliquent aux sous-étiquettes de langues étendues (extended language subtags) : 1. Les sous-étiquettes de trois lettres suivant immédiatement la sous-étiquette primaire sont réservées pour une normalisation future, en anticipation des travaux en cours sur ISO 639. 2. Les sous-étiquettes de langues étendues DOIVENT suivre la sous-étiquette primaire et précéder toutes les autres sous-étiquettes. 3. Il PEUT y avoir jusqu'à trois sous-étiquettes de langues étendues. 4. Les sous-étiquettes de langues étendues NE DOIVENT PAS être enregistrées ou utilisées pour former des étiquettes de langues. Leur syntaxe est décrite ici afin que les mises en oeuvre puissent être compatibles avec une révision future de ce document qui pourvoit à leur enregistrement. 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'. 2.2.3. La sous-étiquette d'écriture 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 : 1. Toutes les sous-étiquettes de quatre lettres ont été définies selon [ISO15924] « Codes for the representation of names of scripts » : les codes d'écritures de quatre lettres, ou affectés ensuite par l'instance de conservation ISO 15924 ou le conseil d'une instance de normalisation, indiquant l'écriture ou le système d'écriture utilisés conjointement à cette langue. 2. La sous-étiquette d'écriture DOIT suivre immédiatement la sous-étiquette de langue primaire et toutes les sous-étiquettes de langues étendues, et DOIT apparaître avant tout autre type de sous-étiquette décrit ci-dessous. 3. Les sous-étiquettes d'écritures 'Qaaa' à 'Qabx' sont réservées pour une utilisation privée dans les étiquettes de langues. Ces sous-étiquettes correspondent aux codes réservés par ISO 15924 pour une utilisation privée. Ces codes PEUVENT être utilisés pour des valeurs d'écritures non enregistrées. Veuillez consulter la section 4.5 pour plus d'informations à propos des sous-étiquettes d'utilisation privée. 4. Les sous-étiquettes d'écritures NE DOIVENT PAS être enregistrées en utilisant le processus décrit dans la section 3.5 de ce document. On PEUT faire appel à des sous-étiquettes de variantes pour cela. 5. Il DOIT y avoir une seule sous-étiquette d'écriture au plus dans une étiquette de langue, et on DEVRAIT omettre la sous-étiquette d'écriture si elle n'ajoute aucune valeur distinctive à l'étiquette ou si l'enregistrement de sous-étiquette de langue primaire contient un champ 'Suppress-Script' listant la sous-étiquette d'écriture en question. Exemple : L'étiquette "sr-Latn" représente du serbe en écriture latine. 2.2.4. La sous-étiquette de région 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 : 1. Les sous-étiquettes de régions DOIVENT suivre les sous-étiquettes de langues, de langues étendues ou d'écritures, et DOIVENT précéder toutes les autres sous-étiquettes. 2. Toutes les sous-étiquettes de deux lettres suivant la sous-étiquette primaire ont été définies dans le registre IANA conformément aux affectations trouvées dans [ISO3166-1] (« Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes ») en utilisant la liste des codes de pays de deux lettres, ou en utilisant les affectations effectuées ensuite par l'instance de conservation ISO 3166 ou le conseil d'une instance de normalisation. 3. Toutes les sous-étiquettes de trois chiffres suivant la sous-étiquette primaire ont été définies dans le registre IANA conformément aux affectations trouvées dans le « Codage statistique normalisé des pays et zones » des Nations-Unies [UN_M.49] ou celles effectuées ensuite par le conseil d'instance de normalisation. Notez que les codes UN M.49 ne sont pas tous définis dans le registre IANA. Les règles suivantes définissent les codes entrés dans le registre comme sous-étiquettes valides : A. Les codes numériques UN (United Nations) affectés aux régions 'macro-geographical (continental)' ou sous-régions DOIVENT être inscrits dans le registre. Ces codes non associés à un code de deux lettres affecté par ISO 3166 représentent des zones supranationales, couvrant généralement plusieurs nations, états, provinces ou territoires. B. Les codes numériques UN de type 'economic groupings' ou 'other groupings' NE DOIVENT PAS être inscrits dans le registre IANA et NE DOIVENT PAS être utilisés pour former des étiquettes de langues. C. Les codes numériques UN des pays ou zones avec des codes ISO 3166 de deux lettres ambigus DOIVENT être définis, lors de l'entrée dans le registre, conformément aux règles dans la section 3.4 et DOIVENT être utilisés pour former les étiquettes de langues qui représentent le pays ou la région pour lesquels ils sont définis. D. Les codes numériques UN des pays ou zones pour lesquels il existe un code associé de deux lettres ISO 3166 dans le registre NE DOIVENT PAS être entrés dans le registre et NE DOIVENT PAS être utilisés pour former des étiquettes de langues. Notez que la sous-étiquette ISO 3166 dans le registre DOIT en fait être associée au code UN M.49 en question. E. Les codes numériques UN et ISO 3166 de deux lettres des pays et zones listés comme éligibles à l'enregistrement dans le [RFC4645] mais pas encore enregistrés PEUVENT être entrés dans le registre IANA via le processus décrit dans la section 3.5. Une fois enregistrés, ces codes PEUVENT être utilisés pour former des étiquettes de langues. F. Tous les autres codes numériques UN de pays ou zones sans code de deux lettres ISO 3166 associé NE DOIVENT PAS être entrés dans le registre et NE DOIVENT PAS être utilisés pour former des étiquettes de langues. Pour plus d'informations à propos de ces codes, cf. la section 3.4. 4. Remarque : Les codes alphanumériques dans l'annexe X du document UN NE DOIVENT PAS être entrés dans le registre et NE DOIVENT PAS être utilisés pour former des étiquettes de langues. (Lors de la création de ce document, ces valeurs correspondaient aux codes de deux lettres ISO 3166). 5. Il ne DOIT y avoir au plus qu'une seule sous-étiquette de région dans une étiquette de langue, et elle PEUT être omise si elle n'ajoute aucune valeur distinctive à l'étiquette. 6. Les sous-étiquettes de régions 'AA', 'QM' à 'QZ', 'XA' à 'XZ' et 'ZZ' sont réservées pour une utilisation privée dans les étiquettes de langues. Ces sous-étiquettes correspondent aux codes réservés par ISO 3166 pour une utilisation privée. Ces codes PEUVENT être utilisés pour les sous-étiquettes de régions d'utilisation privée (au lieu d'utiliser une séquence de sous-étiquettes d'utilisation privée). Veuillez consulter la section 4.5 pour plus d'informations sur les sous-étiquettes d'utilisation privée. 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'). 2.2.5. Les sous-étiquettes de variantes 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 : 1. Les sous-étiquettes de variantes ne sont associées à aucune norme externe. Les sous-étiquettes de variantes et leurs significations sont définies par le processus d'enregistrement décrit dans la section 3.5. 2. Les sous-étiquettes de variantes DOIVENT suivre toutes les autres sous-étiquettes définies mais précéder les séquences de sous-étiquettes d'extensions ou d'utilisation privée. 3. On PEUT utiliser plusieurs variantes pour former l'étiquette de langue. 4. Les sous-étiquettes de variantes DOIVENT être enregistrées auprès de l'IANA conformément aux règles de la section 3.5 de ce document avant de les utiliser pour former des étiquettes de langues. Pour distinguer les sous-étiquettes de variantes des autres types de sous-étiquettes, les enregistrements DOIVENT satisfaire aux restrictions de longueur et de contenu suivantes : 1. Les sous-étiquettes de variantes commençant par une lettre (a-z, A-Z) DOIVENT faire au moins cinq caractères de long. 2. Les sous-étiquettes de variantes commençant par un chiffre (0-9) DOIVENT faire au moins quatre caractères de long. 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". 2.2.6. Les sous-étiquettes d'extensions 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) : 1. Les sous-étiquettes d'extensions sont séparées des autres sous-étiquettes définies dans ce document par une sous-étiquette d'un seul caractère (singleton). Le singleton DOIT être celui alloué à une instance d'enregistrement via le mécanisme décrit dans la section 3.7 et NE DOIT PAS être la lettre 'x', laquelle est réservée pour les séquences de sous-étiquettes d'utilisation privée. 2. Remarque : Les séquences de sous-étiquettes d'utilisation privée commençant par la sous-étiquette singleton 'x' sont décrites dans la section 2.2.7 ci-dessous. 3. Une extension DOIT au minimum suivre une sous-étiquette de langue primaire. C'est-à-dire qu'une étiquette de langue ne peut pas commencer par une extension. Les extensions élargissent les étiquettes de langues, elles ne les annulent pas ni ne les remplacent. Par exemple, "a-value" n'est pas une étiquette de langue valide tandis que "de-a-value" l'est. 4. Chaque sous-étiquette singleton DOIT apparaître au moins une fois dans chaque étiquette (autrement que comme sous-étiquette d'utilisation privée). C'est-à-dire que les sous-étiquettes singletons NE DOIVENT PAS être répétées. Par exemple, l'étiquette "en-a-bbb-a-ccc" est invalide parce que la sous-étiquette 'a' apparaît à deux reprises. Notez que l'étiquette "en-a-bbb-x-a-ccc" est valide parce que le deuxième singleton 'a' apparaît dans une séquence d'utilisation privée. 5. Les sous-étiquettes d'extensions DOIVENT satisfaire à toutes les conditions de contenu et format des sous-étiquettes définies dans ce document. 6. Les sous-étiquettes d'extensions DOIVENT satisfaire à toutes les exigences fixées par le document qui définit leur préfixe singleton et toutes celles établies par l'instance de conservation. 7. Chaque sous-étiquette d'extension DOIT faire de deux à huit caractères de long et se composer exclusivement de lettres ou de chiffres, chaque sous-étiquette étant séparée par un seul trait d'union '-'. 8. Chaque singleton DOIT être suivi d'au moins une sous-étiquette d'extension. Par exemple, l'étiquette "tlh-a-b-foo" est invalide parce que le premier singleton 'a' est suivi immédiatement d'un autre singleton 'b'. 9. Les sous-étiquettes d'extensions DOIVENT suivre toutes les sous-étiquettes de langues, de langues étendues, d'écritures, de régions et de variantes dans une étiquette. 10. Toutes les sous-étiquettes après le singleton et avant un autre singleton font partie de l'extension. Exemple : Dans l'étiquette "fr-a-Latn", la sous-étiquette 'Latn' ne représente pas la sous-étiquette d'écriture 'Latn' définie dans le registre des sous-étiquettes de langues IANA. Sa signification est définie par l'extension 'a'. 11. Au cas où plusieurs extensions apparaissent dans une seule étiquette, l'étiquette DEVRAIT être canonisée comme décrit dans la section 4.4. 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". 2.2.7. Les sous-étiquettes d'utilisation privée 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 : 1. Les sous-étiquettes d'utilisation privée sont séparées des autres sous-étiquettes définies dans ce document par la sous-étiquette d'une seule lettre 'x'. 2. Les sous-étiquettes d'utilisation privée DOIVENT se conformer aux conditions de format et de contenu décrites dans la définition ABNF pour toutes les sous-étiquettes. 3. Les sous-étiquettes d'utilisation privée DOIVENT suivre toutes les sous-étiquettes de langues, de langues étendues, d'écritures, de régions, de variantes et d'extensions dans l'étiquette. Autrement dit, toutes les sous-étiquettes après le singleton 'x' DOIVENT être considérées d'utilisation privée. Exemple : La sous-étiquette 'US' dans l'étiquette "en-x-US" est une sous-étiquette d'utilisation privée. 4. Une étiquette PEUT être entièrement constituée de sous-étiquettes d'utilisation privée. 5. Il n'y a aucune source définie pour les sous-étiquettes d'utilisation privée. Leur utilisation est uniquement régie par un accord de gré à gré. 6. Les sous-étiquettes d'utilisation privée NE SONT PAS RECOMMANDÉES s'il existe des alternatives ou pour les échanges généraux. Cf. la section 4.5 pour plus d'informations à propos du choix d'une sous-étiquette 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'. 2.2.8. Les enregistrements RFC 3066 préexistants 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. 2.2.9. Les catégories de conformité Les mises en oeuvre 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 oeuvre 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 oeuvre qui prétend vérifier la bonne forme des étiquettes de langues DOIT : o Vérifier que l'étiquette et toutes ses sous-étiquettes, y compris les sous-étiquettes d'extensions et d'utilisation privée, sont conformes à la définition ABNF, ou que l'étiquette se trouve dans la liste des étiquettes exonérées. o Vérifier que les sous-étiquettes singletons identifiant des extensions ne se répètent pas. Par exemple, l'étiquette "en-a-xx-b-yy-a-zz" n'est pas bien formée. On préconise vivement que les processeurs de bonne forme mettent en oeuvre les règles de canonisation contenues dans la setion 4.4. Une mise en oeuvre qui prétend être validante DOIT : o Vérifier que l'étiquette est bien formée. o Indiquer la date de registre particulière pour laquelle la mise en oeuvre effectue une validation des sous-étiquettes. o Vérifier si l'étiquette est une étiquette exonérée, ou bien si toutes les sous-étiquettes de langues, d'écritures, de régions et de variantes sont constituées de codes valides pour une utilisation dans les étiquettes de langues d'après le registre IANA à la date particulière indiquée par la mise en oeuvre. o Indiquer, le cas échéant, les documents RFC d'extension définis dans la section 3.7 qui sont gérés, y compris la version, la révision et la date. Pour chacune des extensions gérées, vérifier que toutes les sous-étiquettes qui y apparaissent sont valides. Pour les sous-étiquettes de langues variantes et étendues, si le registre contient un ou plusieurs champs 'Prefix' pour la sous-étiquette, vérifier que l'étiquette correspond à au moins un préfixe. L'étiquette correspond si toutes les sous-étiquettes dans les champs 'Prefix' apparaissent aussi dans l'étiquette. Par exemple, le préfixe "es-CO" correspond à l'étiquette "es-Latn-CO-x-private" car la sous-étiquette de langue 'es' et la sous-étiquette de région 'CO' apparaissent toutes deux dans l'étiquette. 3. Le format et l'entretien du registre 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). 3.1. Le format du registre des sous-étiquettes de langues 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 : o 'Type' * La valeur du champ 'Type' DOIT être l'une des chaînes suivantes : "language", "extlang", "script", "region", "variant", "grandfathered" ou "redundant". Elle indique le type de l'étiquette ou de la sous-étiquette. o Soit 'Subtag', soit 'Tag' * La valeur du champ 'Subtag' contient la sous-étiquette à définir. Ce champ DOIT uniquement apparaître dans les enregistrements dont le champ 'Type' a l'une des valeurs suivantes : "language", "extlang", "script", "region" ou "variant". * La valeur du champ 'Tag' contient une étiquette de langue complète. Ce champ DOIT uniquement apparaître dans les enregistrements dont le champ 'Type' a l'une des valeurs suivantes : "grandfathered" ou "redundant". Notez que le corps de champ suivra toujours la production 'grandfathered' dans la définition ABNF dans la section 2.1. o 'Description' * La valeur du champ 'Description' contient une description non normative de la sous-étiquette ou de l'étiquette. o 'Added' * La valeur du champ 'Added' contient la date où l'enregistrement a été ajouté au registre. 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 : o 'Preferred-Value' * Pour les champs de type 'language', 'extlang', 'script', 'region' et 'variant', le champ 'Preferred-Value' contient la sous-étiquette de même 'Type' préférée pour former l'étiquette de langue. * Pour les champs de type 'grandfathered' et 'redundant', une application canonique vers une étiquette de langue complète. o 'Deprecated' * La valeur du champ 'Deprecated' contient la date de caducité (deprecation) de l'enregistrement. o 'Prefix' * La valeur du champ 'Prefix' contient une étiquette de langue que cette sous-étiquette PEUT utiliser pour former une nouvelle étiquette de langue, éventuellement avec d'autres sous-étiquettes. Ce champ ne DOIT apparaître que dans les enregistrements dont la valeur du champ 'Type' est 'variant' ou 'extlang'. Par exemple, la valeur 'Prefix' de la variante 'nedis' est 'sl', signifiant par-là que les étiquettes "sl-nedis" et "sl-IT-nedis" seraient appropriées et non l'étiquette "is-nedis". o 'Comments' * Le champ 'Comments' contient des informations supplémentaires à propos de la sous-étiquette, jugées appropriées pour la compréhension du registre et pour une mise en oeuvre des étiquettes de langues utilisant la sous-étiquette ou l'étiquette. o 'Suppress-Script' * Le champ 'Suppress-Script' contient une sous-étiquette d'écriture qui NE DEVRAIT PAS être utilisée pour former des étiquettes de langues avec la sous-étiquette de langue primaire associée. Ce champ ne DOIT apparaître que dans les enregistrements dont la valeur du champ 'Type' est 'language'. Cf. la section 4.1. 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 : 1. Les codes de langues ISO 639 abandonnés ensuite en faveur d'autres codes. Ces valeurs sont quasiment des curiosités historiques. 2. Les codes de langues ISO 3166 abandonnés en faveur de codes nouveaux. Cela se produit parfois lorsqu'un pays change de nom ou d'administration au point de justifier un nouveau code de région. 3. Les étiquettes exonérées de RFC 3066. Dans beaucoup de cas, ces étiquettes sont devenues obsolètes car les valeurs qu'elles représentent ont été codées ensuite par ISO 639. 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". 3.2. Le vérificateur des sous-étiquettes de langues 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. 3.3. La conservation du registre 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. 3.4. La stabilité des entrées du registre IANA 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 : 1. Les valeurs des champs 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' et 'Preferred-Value' NE DOIVENT PAS changer et elles sont assurées d'être stables dans le temps. 2. Les valeurs des champs 'Description' NE DOIVENT PAS changer d'une façon qui invaliderait les étiquettes préexistantes. On PEUT en élargir quelque peu la portée, les changer pour ajouter des informations ou les adapter à l'utilisation moderne la plus courante. Par exemple, les pays changent épisodiquement de nom, un exemple historique en étant la « Haute-Volta » changée en « Burkina Faso ». 3. Les valeurs des champs 'Prefix' PEUVENT être ajoutées aux enregistrements de type 'variant' via le processus d'enregistrement. 4. Les valeurs des champs 'Prefix' PEUVENT être modifiées tant que la modification élargit l'ensemble des préfixes. C'est-à-dire qu'un préfixe PEUT être remplacé par l'un de ses propres préfixes. Par exemple, le préfixe "en-US" pourrait être remplacé par "en", mais non par les préfixes "en-Latn", "fr" ou "en-US-boont". Si l'on a besoin de ces préfixes, on DEVRAIT enregistrer un nouveau champ 'Prefix'. 5. Les valeurs du champ 'Prefix' NE DOIVENT PAS être supprimées. 6. Le champ 'Comments' PEUT être ajouté, changé, modifié ou supprimé via le processus d'enregistrement, ou les processus ou observations décrits dans cette section. 7. Le champ 'Suppress-Script' PEUT être ajouté ou supprimé via le processus d'enregistrement. 8. Les codes affectés par les normes ISO 639, ISO 15924 et ISO 3166, qui ne sont pas en conflit avec les sous-étiquettes existantes du type associé et dont la signification n'est pas la même que celle d'une sous-étiquette du même type, entrent dans le registre IANA comme nouveaux enregistrements. 9. Le codes affectés par les normes ISO 639, ISO 15924 ou ISO 3166, qui sont annulés par leurs instances de conservation ou d'enregistrement respectives, restent valides dans les étiquettes de langues. Un champ 'Deprecated' contenant la date d'annulation est ajoutée à l'enregistrement. Si un nouvel enregistrement du même type représentant une valeur de remplacement est ajouté, alors un champ 'Preferred-Value' PEUT l'être aussi. 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'). 10. Les codes affectés par les normes ISO 639, ISO 15924 ou ISO 3166 qui sont en conflit avec les sous-étiquettes existantes du type associé, y compris les sous-étiquettes caduques, NE DOIVENT PAS entrer dans le registre. Les observations supplémentaires suivantes s'appliquent aux valeurs de sous-étiquettes réaffectées : A. Pour les codes ISO 639, si la signification du nouveau code affecté n'est pas représentée par une sous-étiquette dans le registre IANA, le vérificateur des sous-étiquettes de langues, comme décrit dans la section 3.5, DEVRA préparer aussitôt que possible une proposition d'entrée dans le registre IANA d'une sous-étiquette de langue enregistrée comme valeur alternative pour le nouveau code. La forme de la sous-étiquette de langue enregistrée est à la discrétion du vérificateur et DOIT être conforme aux autres restrictions sur les sous-étiquettes de langues dans ce document. B. Pour toutes les sous-étiquettes dont la signification dérive d'une norme externe (c'est-à-dire, ISO 639, ISO 15924, ISO 3166 ou UN M.49), si une nouvelle signification est affectée à un code existant et qu'elle élargit la signification de ce code, alors la signification de la sous-étiquette associée PEUT être changée pour correspondre. Par contre, la signification d'une sous-étiquette NE DOIT PAS être réduite, car cela peut aboutir à rendre invalide une proportion inconnue des utilisations existantes d'une sous-étiquette. Remarque : L'instance de conservation/enregistrement (MA/RA) ISO 639 a adopté une politique de stabilité similaire. C. Pour les codes ISO 15924, si la signification du nouveau code affecté n'est pas représentée par une sous-étiquette dans le registre IANA, le vérificateur des sous-étiquettes de langues, comme décrit dans la section 3.5, DEVRA préparer aussitôt que possible une proposition d'entrée dans le registre IANA d'une sous-étiquette de variante enregistrée comme valeur alternative pour le nouveau code. 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. D. Pour les codes ISO 3166, si la signification du nouveau code affecté est associée au même code UN M.49 comme autre sous-étiquette de 'region', alors la sous-étiquette de région existante reste la valeur préférée pour cette région et aucune nouvelle entrée n'est créée. Un commentaire PEUT être ajouté à la sous-étiquette de région existante indiquant la relation avec le nouveau code ISO 3166. E. Pour les codes ISO 3166, si la signification du nouveau code affecté est associée à un code UN M.49 non représenté par une sous-étiquette de région existante, alors le vérificateur des sous-étiquettes de langues, comme décrit dans la section 3.5, DEVRA préparer une proposition d'entrée du code de pays UN M.49 approprié comme entrée dans le registre IANA. F. Pour les codes ISO 3166, s'il n'y a aucun code numérique UN associé, alors le vérificateur des sous-étiquettes de langues DEVRA devra faire une demande de création auprès des Nations-Unies (UN). Sans réponse de leur part dans les quatre-vingt-dix jours suivant la demande, le vérificateur DEVRA préparer aussitôt que possible une proposition d'entrée dans le registre IANA d'une sous-étiquette de variante enregistrée comme valeur alternative pour le nouveau code. La forme de la sous-étiquette de variante enregistrée est à la discrétion du vérificateur et DOIT être conforme aux autres restrictions sur les sous-étiquettes de variantes dans ce document. Ce cas ne se présentera probablement jamais. 11. La norme UN M.49 a des codes pour les pays et les zones (tel que '276' pour l'Allemagne) et pour les régions géographiques et sous-régions (tel que '150' pour l'Europe). Les codes UN M.49 de pays et zones pour lesquels il n'existe pas de code ISO 3166 correspondant NE DEVRAIENT PAS être enregistrés, sauf comme représentant d'un code ISO 3166 bloqué à l'enregistrement par une sous-étiquette existante. Si un tel code est nécessaire, alors on DEVRAIT d'abord solliciter l'affectation d'une code à la région auprès de l'instance d'enregistrement ISO 3166. Si la pétition d'affectation de code par l'instance ISO 3166 est rejetée ou non observée dans les délais, alors on PEUT utiliser le processus d'enregistrement décrit dans la section 3.5 pour enregistrer le code UN M.49 correspondant. À la rédaction de ce document, il n'existait que quatre codes de ce genre : 830 (Îles Anglo-Normandes), 831 (Guernesey), 832 (Jersey) et 833 (Île de Man). De cette manière, les codes UN M.49 restent disponibles comme valeurs de dernier recours au cas où l'instance ISO 3166 réaffectait une valeur caduque dans le registre. 12. Les dispositions de stabilié s'appliquent aux étiquettes exonérées sauf l'exception suivante : si toutes les sous-étiquettes dans une étiquette exonérée (grandfathered) devenaient valides dans le registre IANA, alors la valeur du champ 'Type' dans cet enregistrement changerait de 'grandfathered' pour 'redundant'. Notez que cela n'affecterait pas les étiquettes de langues qui correspondent à l'étiquette exonérée, puisque ces étiquettes correspondraient alors aux séquences de sous-étiquettes génératives. Par exemple, si la sous-étiquette 'gan' dans l'étiquette de langue "zh-gan" était enregistrée comme sous-étiquette de langue étendue, alors l'étiquette exonérée "zh-gan" serait caduque (mais le contenu ou les mises en oeuvre utilisant "zh-gan" resteraient valides). 3.5. La procédure d'enregistrement des sous-étiquettes 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é à ; 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 à ). 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. 3.6. Les possibilités d'enregistrement Les possibilités d'enregistrement de sous-étiquettes ou d'informations au sujet de sous-étiquettes comprennent : o Les sous-étiquettes de langues primaires de langues non listées dans ISO 639, qui ne sont pas les variantes d'une langue listée ou enregistrée, PEUVENT être enregistrées. À la création de ce document, il n'y avait pas d'exemple de cette forme de sous-étiquette. Avant toute tentative d'enregistrer une sous-étiquette de langue, une tentative d'enregistrer la langue dans ISO 639 DOIT avoir eu lieu. On NE DOIT PAS enregistrer de sous-étiquettes pour des codes existant dans ISO 639-1 ou ISO 639-2, en cours d'examen par l'instance de conservation ou d'enregistrement ISO 639, ou n'ayant jamais fait l'objet d'une tentative d'enregistrement auprès de ces instances. Si l'instance ISO 639 a rejeté précédemment l'enregistrement d'une langue, on peut raisonnablement penser qu'il faudra une preuve supplémentaire incontestable d'un besoin pour qu'elle entre dans le registre IANA (dans la mesure où il est très improbable que des sous-étiquettes de ce genre seront enregistrées). o Un dialecte ou d'autres divisions ou variations au sein d'une langue, son orthographe, son système d'écriture, son utilisation régionale ou historique, une translitération ou une autre transformation, ou une variatin distinctive PEUVENT être enregistrés comme sous-étiquettes de variantes. Un exemple est celui de la sous-étiquette 'rozaj' (le dialecte de Resia du slovène). o L'ajout de champs ou leur mise à jour (généralement de nature informationnelle) dans les enregistrements de type 'Tag' ou 'Subtag', comme décrit dans la section 3.1 et sous réserve des dispositions de stabilité dans la section 3.4. Sont compris les descriptions, les commentaires, la caducité et les valeurs préférées pour les codes obsolètes ou annulés, ou l'ajout d'informations d'écriture ou de langue externe (extlang) aux sous-étiquettes de langues primaires. o L'ajout d'enregistrements et les changements nécessaires des valeurs de champs liées pour refléter les affectations effectuées par les instances ISO 639, ISO 15924, ISO 3166 et UN M.49, comme décrit dans la section 3.4. 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) Aichholzgasse 6/12, AT-1120 Wien, Austria Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 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 Congress Network Development and MARC Standards Office Washington, D.C. 20540 USA Phone: +1 202 707 6237 Fax: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-2 L'instance de conservation de la norme ISO 3166 (codes de pays) est la suivante : ISO 3166 Maintenance Agency c/o International Organization for Standardization Case postale 56 CH-1211 Geneva 20 Switzerland Phone: +41 22 749 72 33 Fax: +41 22 749 73 49 URL: http://www.iso.org/iso/country_codes L'instance d'enregistrement pour la norme ISO 15924 (codes d'écritures) est la suivante : Unicode Consortium Box 391476 Mountain View, CA 94039-1476, USA URL: http://www.unicode.org/iso15924 La 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 Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA Fax: +1-212-963-0623 E-mail: statistics@un.org URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm 3.7. Les extensions et le registre des extensions Les 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 oeuvre 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 : o La spécification DOIT référencer la version ou la révision spécifiques de ce document qui régit sa création et DOIT référencer cette section de ce document. o La spécification et toutes les sous-étiquettes définies par elle DOIVENT respecter la définition ABNF et les autres règles de formation des étiquettes et sous-étiquettes comme défini dans ce document. En particulier, elle DOIT indiquer que la casse n'est pas significative et que les sous-étiquettes NE DOIVENT PAS excéder huit caractères de long. o La spécification DOIT indiquer une représentation canonique. o La spécification des sous-étiquettes valides DOIT être accessible par Internet sans contrepartie financière. o La spécification DOIT être dans le domaine public ou disponible via une licence libre de droits acceptable pour l'IETF et indiquée dans le document RFC. o La spécification DOIT être versionnée et chaque version de la spécification DOIT être numérotée, datée et stable. o La spécification DOIT être stable. C'est-à-dire que les sous-étiquettes d'extensions, une fois définies par une spécification, NE DOIVENT PAS être rétractée ou changer de sens d'aucune façon substantielle. o La spécification DOIT inclure, dans une section séparée, le formulaire d'enregistrement reproduit dans cette section (ci-dessous), à utiliser pour l'enregistrement de l'extension dès publication comme document RFC. o L'IANA DOIT être informé des changements de coordonnées et d'adresse URL de la spécification. 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. 3.8. L'initialisation des registres 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. 4. La formation et le traitement des étiquettes de langues 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. 4.1. Le choix d'une étiquette de langue 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 oeuvre 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 oeuvre 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 : 1. Utiliser une étiquette aussi précise que possible, mais pas plus spécifique que nécessaire. Éviter l'utilisation de sous-étiquettes non importantes pour distinguer le contenu dans une application. * 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. 2. On NE DEVRAIT PAS utiliser une sous-étiquette d'écriture pour former des étiquettes de langues à moins que l'écriture ajoute une information distinctive à l'étiquette. Le champ 'Suppress-Script' dans l'enregistrement de langue primaire du registre indique les sous-étiquettes d'écritures qui n'ajoutent pas d'informations distinctives, pour la plupart des applications. * 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. 3. Si une étiquette (ou une sous-étiquette) a un champ 'Preferred-Value' dans son entrée de registre, alors la valeur de ce champ DEVRAIT être utilisée pour former l'étiquette de langue, de préférence à l'étiquette (ou la sous-étiquette) dans laquelle cette valeur préférée apparaît. * Par exemple, utiliser 'he' pour l'hébreu de préférence à 'iw'. 4. La sous-étiquette de langue primaire 'und' (Undetermined) NE DEVRAIT PAS être utilisée pour étiqueter le contenu, même si la langue est inconnue. Il est préférable d'omettre complètement l'étiquette de langue plutôt que d'utiliser une étiquette avec une sous-étiquette de langue primaire de 'und'. La sous-étiquette 'und' PEUT être utile lors de la comparaison d'étiquettes de langues dans certaines situations. 5. La sous-étiquette de langue primaire 'mul' (Multiple) NE DEVRAIT PAS être utilisée lorsque le protocole permet de séparer les étiquettes de multiples langues, comme c'est le cas pour l'en-tête Content-Language dans HTTP. La sous-étiquette 'mul' véhicule peu d'informations utiles : un contenu de multiples langues DEVRAIT baliser les langues là où elles apparaissent, ou sinon indiquer la langue concrète de préférence à la sous-étiquette 'mul'. 6. La même sous-étiquette de variante NE DEVRAIT PAS être utilisée plus d'une fois au sein d'une étiquette de langue. * 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. 4.2. La signification de l'étiquette de langue 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. o Pour un seul objet d'information, les étiquettes de langues associées peuvent être interprétées comme l'ensemble des langues nécessaires pour une compréhension complète de l'objet entier. Exemple : Les documents en texte ordinaire (plain text). o Pour une agrégation d'objets d'information, les étiquettes de langues associées peuvent être assimilées à l'ensemble des langues utilisées à l'intérieur des composants de cette agrégation. Exemples : Les entrepôts et bibliothèques de documents. o Pour les objets d'information dont le but est de fournir des alternatives, on peut considérer les étiquettes de langues associées comme un indice que le contenu est fourni dans plusieurs langues et qu'on doit inspecter chaque alternative pour trouver sa langue ou ses langues. Dans ce cas, la présence d'étiquettes multiples ne signifie pas qu'il faille être polyglotte pour comprendre entièrement le document. Exemple : Le type MIME multipart/alternative. o Dans les langages de balisage, tels que HTML et XML, on peut ajouter une information de langue à chaque partie du document identifiée par la structure du balisage (y compris le document dans sa globalité). Par exemple, on pourrait écrire C'est la vie. dans un document en norvégien ; le locuteur norvégien pourrait alors attraper un dictionnaire norvégien-français pour connaître la signification de la section ainsi balisée. Si l'utilisateur écoute le document au travers d'une interface de synthèse vocale, ce balisage pourrait être utilisé pour signaler au synthétiseur d'appliquer de façon appropriée les règles de prononciation française pour la synthèse vocale de cette étendue de texte, au lieu des règles norvégiennes inappropriées. 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. 4.3. Les facteurs de longueur 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. 4.3.1. Le travail avec des mémoires tampon limitées 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 oeuvre 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 : o Les mises en oeuvre NE DEVRAIENT PAS tronquer les étiquettes de langues, sauf si la signification de l'étiquette est changée à dessein ou si l'étiquette n'entre pas dans l'espace de tampon limité défini par le protocole pour le stockage ou la transmission. o Les mises en oeuvre DEVRAIENT avertir l'utilisateur lorsqu'une étiquette est tronquée puisque la troncature change la signification sémantique de l'étiquette. o Les mises en oeuvre de protocoles ou de spécifications qui sont contraintes par l'espace mais n'ont pas de limite fixe DEVRAIENT utiliser une étiquette la plus longue possible de préférence à une troncature. o Les protocoles ou spécifications qui définissent des tailles de mémoire tampon limitées pour les étiquettes de langues DOIVENT admettre des étiquettes de langues jusqu'à 33 caractères. Les protocoles ou spécifications qui définissent des tailles de mémoire tampon limitées pour les étiquettes de langues DEVRAIENT admettre des étiquettes de langues d'au moins 42 caractères. 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 4.3.2. La troncature des étiquettes de langues 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 4.4. La canonisation des étiquettes de langues 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 : 1. L'étiquette est bien formée selon les règles des sections 2.1 et 2.2. 2. Les sous-étiquettes de type 'Region' qui ont une correspondance 'Preferred-Value' dans le registre IANA (cf. la section 3.1) DEVRAIENT être remplacées par leur valeur associée (mapped value). Remarque : Dans de rares cas, la valeur associée aura également une indication 'Preferred-Value'. 3. Les étiquettes redondantes ou exonérées qui ont une correspondance 'Preferred-Value' dans le registre IANA (cf. la section 3.1) DOIVENT être remplacées par leur valeur associée. Ces éléments sont soit des correspondances caduques créées avant l'adoption de ce document (telle la correspondance de "no-nyn" à "nn", ou de "i-klingon" à "tlh"), soit le résultat d'enregistrements ou d'ajouts tardifs à ce document (par exemple, l'étiquette "zh-guoyu" pourrait être associée à une combinaison language-extlang telle que "zh-cmn" par quelque mise à jour future de ce document). 4. Les autres sous-étiquettes qui ont une correspondance 'Preferred-Value' dans le registre IANA (cf. la section 3.1) DOIVENT être remplacées par leur valeur associée. Ces éléments sont entièrement constitués de corrections d'écriture sur la norme ISO 639-1 où les sous-étiquettes caduques ont été conservées pour des raisons de compatibilité. 5. S'il y a plusieurs séquences de sous-étiquettes d'extensions, ces séquences sont arrangées dans l'ordre ASCII indépendamment de la casse par sous-étiquette singleton. 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. 4.5. Observations sur les sous-étiquettes d'utilisation privée 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. 5. Les devoirs de l'IANA 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. 5.1. Le registre des sous-étiquettes de langues 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é. 5.2. Le registre des extensions 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. 6. Observations sur la sécurité 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 oeuvre 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 oeuvre NE DEVRAIENT PAS s'attendre mécaniquement à ce qu'elle soit toujours accessible, pour prévenir les attaques par déni de service. 7. Observations sur les jeux de caractères 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. 8. Les changements depuis le RFC 3066 Les objectifs principaux de cette révision des étiquettes de langues étaient les suivants : *Compatibilité* : Toutes les étiquettes de langues RFC 3066 (y compris celles dans le registre IANA) restent valides dans cette spécification. Les changements dans ce document représentent des contraintes supplémentaires sur les étiquettes de langues. C'est-à-dire que la syntaxe n'est en aucun cas plus permissive, et les processeurs fondés sur la définition ABNF et les autres dispositions du RFC 3066 (tels que ceux décrits dans la spécification [XMLSchema]) seront capables de traiter les étiquettes décrites par ce document. En outre, ce document définit les étiquettes de langues de façon à assurer une compatibilité future. *Stabilité* : À cause des changements apportés dans le passé aux normes ISO sous-jacentes, une étiquette de langue RFC 3066 valide pouvait devenir invalide ou voir sa signification changer. Un contenu avec une durée de vie étendue peut se trouver invalidé. Dans cette spécification, une fois l'étiquette de langue validée, elle le reste indéfiniment. *Validité* : La structure des étiquettes de langues définies par ce document permet de déterminer si une étiquette particulière est bien formée indépendamment du contenu actuel ou de la signification de l'étiquette dans son ensemble. C'est important parce que le registre grandit et les normes sous-jacentes changent avec le temps. En outre, on doit pouvoir déterminer si une étiquette est valide (ou non) à un moment donné dans le temps pour assurer des résultats testables reproductibles. Ce processus ne doit pas être sujet à l'erreur, sinon les mises en oeuvres peuvent donner des résultats différents. En ayant un registre de référence avec une information de version spécifique, on peut déterminer la validité des étiquettes de langues à tout moment dans le temps (au lieu d'interpoler des valeurs provenant de plusieurs sources séparées). *Utilité* : Il est parfois important de pouvoir différencier les formes écrites d'une langue, car pour beaucoup de mises en oeuvre, cela importe plus que de différencier les variantes parlées d'une langue. Les langues s'écrivent dans une grande variété d'écritures différentes, et ce document pourvoit à l'utilisation générative des codes d'écritures ISO 15924. Tout comme l'utilisation générative des codes de langues et de pays ISO dans le RFC 3066, cela permet de produire des combinaisons sans recourir au processus d'enregistrement. L'ajout des codes UN M.49 pourvoit à la génération d'étiquettes de langues à portée régionale, que certaines applications demandent aussi. 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. *Extensibilité* : Du fait de l'utilisation répandue des étiquettes de langues, les révisions périodiques de la spécification centrale, même en face d'un besoin démontré, sont pertubantes. Le mécanisme d'extension permet aux documents RFC indépendants de définir des extensions aux étiquettes de langues. Ces extensions ont une structure bien définie très rigide qui les empêche d'interférer avec les mises en oeuvre des étiquettes de langues définies dans ce document. 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 : o Établir les définitions ABNF et des règles de sous-étiquettes afin de pouvoir déterminer la catégorie de toutes les sous-étiquettes sans référence au registre. o Ajouter le concept de processeur de bonne forme contre processeur de validation, en définissant les règles selon lesquelles une mise en oeuvre peut revendiquer être d'un type ou de l'autre. o Remplacer le registre des étiquettes de langues IANA par un un registre de sous-étiquettes de langues fournissant une liste complète des sous-étiquettes valides dans le registre IANA. Cela assure une fiabilité de la mise en oeuvre et une facilité d'entretien. Le registre des sous-étiquettes de langues devient la source canonique de la formation des étiquettes de langues. o Fournir un processus qui garantit la stabilité des étiquettes de langues, en gérant la réutilisation des valeurs par les normes ISO 639, ISO 15924 et ISO 3166 au cas où elles enregistrent une valeur utilisée précédemment pour une nouvelle raison. o Admettre les sous-étiquettes de codes d'écritures ISO 15924 et leur permettre d'être utilisées de façon générative. Définir une méthode pour indiquer dans le registre lorsque des sous-étiquettes d'écritures sont nécessaires pour une étiquette de langue donnée. o Ajouter le concept d'étiquette de variante et permettre aux variantes d'être utilisées de façon générative. o Ajouter la possibilité d'utiliser une classe d'étiquettes UN M.49 pour les régions supranationales et pour résoudre les conflits dans l'affectation des codes ISO 3166. o Définir les étiquettes d'utilisation privée dans ISO 639, ISO 15924 et ISO 3166 comme le mécanisme pour créer les sous-étiquettes d'utilisation privée de langues, d'écritures et de régions respectivement. o Ajouter un mécanisme d'extension bien défini. o Définir une sous-étiquette de langue étendue, pour une utilisation possible avec certaines caractéristiques anticipées de ISO 639-3. 9. Références 9.1. Références normatives [ISO10646] International Organization for Standardization, "ISO/IEC 10646:2003. Information technology -- Universal Multiple-Octet Coded Character Set (UCS)", 2003. [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 1997. [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002. [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. [N.d.T. en français] Division de statistique des Nations-Unies, «Codage statistique normalisé des pays et zones » http://unstats.un.org/unsd/methods/m49/m49frnch.htm 9.2. Références informatives [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4645] Ewell, D., Ed., "Initial Language Subtag Registry", RFC 4645, September 2006. [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, September 2006. [Unicode] Unicode Consortium, "The Unicode Standard, Version 5.0", Boston, MA, Addison-Wesley, 2007. ISBN 0-321- 48091-0. [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", 02 2004. [XMLSchema] Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2: Datatypes Second Edition", 10 2004, http://www.w3.org/TR/xmlschema-2/. [iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: Working principles for ISO 639 maintenance", March 2000, http://www.loc.gov/standards/iso639-2/iso639jac_n3r.html. [record-jar] Raymond, E., "The Art of Unix Programming", 2003, . Annexe A. Remerciements 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. Annexe C. Exemples d'étiquettes de langues (informatif) Étiquettes de langues simples : de (allemand) fr (français) ja (japonais) i-enochian (exemple d'étiquette exonérée) Étiquettes de langues plus sous-étiquette d'écriture : zh-Hant (chinois en écriture chinoise traditionnelle) zh-Hans (chinois en écriture chinoise simplifiée) sr-Cyrl (serbe en écriture cyrillique) sr-Latn (serbe en écriture latine) Lanque-écriture-région : zh-Hans-CN (chinois en écriture simplifiée tel qu'utilisé en Chine continentale) sr-Latn-CS (serbe en écriture latine tel qu'utilisé en Serbie et Montenegro) Langue-variante : sl-rozaj (dialecte de Resia du slovène) sl-nedis (dialecte de Nadiza du slovène) Langue-région-variante : de-CH-1901 (allemand utilisé en Suisse dans la variante de 1901 [orthographe]) sl-IT-nedis (slovène utilisé en Italie, dialecte de Nadiza) Langue-écriture-région-variante : sl-Latn-IT-nedis (dialecte de Nadiza du slovène en écriture latine tel qu'utilisé en Italie. Notez que cette étiquette N'EST PAS RECOMMANDÉE parce que le champ 'Suppress-Script' de la sous-étiquette 'sl' a une valeur de 'Latn') Langue-région : de-DE (allemand utilisé en Allemagne) en-US (anglais utilisé aux États-Unis) es-419 (espagnol approprié pour la région Amérique Latine et Caraïbes utilisant le code de région UN) Sous-étiquettes d'utilisation privée : de-CH-x-phonebk az-Arab-x-AZE-derbend Sous-étiquettes de langues étendues (UNIQUEMENT pour exemple : les langues étendues DOIVENT être définies par une révision ou une mise à jour de ce document) : zh-min zh-min-nan-Hant-CN Valeurs du registre d'utilisation privée : x-whatever (utilisation privée avec le singleton 'x') qaa-Qaaa-QM-x-southern (toutes des étiquettes privées) de-Qaaa (allemand, avec une écriture privée) sr-Latn-QM (serbe, écriture latine, région privée) sr-Qaaa-CS (serbe, écriture privée, pour la Serbie et Montenegro) Étiquettes qui utilisent des extension (UNIQUEMENT pour exemple : les extensions doivent être définies par une révision ou une mise à jour de ce document ou par un RFC) : en-US-u-islamCal zh-CN-a-myExt-x-private en-a-myExt-b-another Quelques étiquettes invalides : de-419-DE (deux sous-étiquettes de régions) a-DE (utilisation d'une sous-étiquette d'un seul caractère en position primaire ; notez que quelques étiquettes exonérées commencent par "i-" et sont valides) ar-a-aaa-b-bbb-a-ccc (deux extensions avec le même préfixe d'une seule lettre) Coordonnées des auteurs Addison Phillips (rédacteur) Yahoo! Inc. EMail: addison@inter-locale.com Mark Davis (rédacteur) Google EMail: mark.davis@macchiato.com ou mark.davis@google.com ------------------------------------------------------------------------ Full Copyright Statement 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. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). ------------------------------------------------------------------------