Résumé

  • RFC 1766 rendait la balise lisible par segments, mais demandait aux applications de la manipuler comme une seule valeur ; les sous-balises relevaient de l’administration du vocabulaire, pas d’un menu.
  • Les codes ISO, les enregistrements IANA et l’espace privé occupaient des zones différentes de la syntaxe. La norme qui employait la balise devait définir son lien avec le contenu.
  • Les règles ultérieures ont ajouté des opérations de correspondance explicites. Elles n’ont pas transformé chaque trait d’union de la grammaire de 1995 en chemin de navigation.

Le trait d’union ressemble à un fil d’Ariane

En mars 1995, RFC 1766 proposait une façon compacte d’indiquer la langue d’un objet d’information. La forme avait de quoi suggérer un arbre : une balise principale, puis des morceaux facultatifs séparés par des traits d’union. en-US paraissait familier ; az-arabic et az-cyrillic partageaient leur début. Le texte posait pourtant une limite nette : l’application devait traiter la balise entière comme un seul jeton. La séparation en balise principale et sous-balises était un mécanisme administratif, pas une aide à la navigation.

Cette précision empêchait de confondre une chaîne lisible avec une hiérarchie de commandes. La valeur principale pouvait contenir une à huit lettres, tout comme chaque sous-balise. Les espaces étaient interdits dans la chaîne. La casse, elle, n’en changeait pas la valeur. Les conventions pouvaient écrire les codes de pays en majuscules et les langues en minuscules, sans leur donner pour autant un sens supplémentaire.

L’espace de noms était encadré. Les valeurs principales de deux lettres renvoyaient à ISO 639. i était réservé aux enregistrements définis par IANA ; x ouvrait un usage privé dont les sous-balises ne seraient pas enregistrées par IANA. Les autres valeurs principales restaient indisponibles sans révision de la norme. Dans la première sous-balise, les codes de deux lettres suivaient ISO 3166 alpha-2 ; les valeurs de trois à huit lettres pouvaient être enregistrées auprès d’IANA. Les sous-balises suivantes pouvaient aussi faire l’objet d’un enregistrement.

La structure avait donc deux fonctions faciles à mélanger : rendre la chaîne lisible par morceaux et administrer un espace de noms. Elle ne disait pas qu’il fallait parcourir ces morceaux comme des répertoires. Elle ne donnait pas non plus à chaque segment un sens universel pour toutes les applications. RFC 1766 confiait à la norme du contexte la définition du lien entre la balise et l’objet d’information.

L’enregistrement donnait un dossier public aux valeurs

Les exemples de RFC 1766 couvraient l’identification d’un pays (en-US), un dialecte ou une variante (no-nynorsk, en-cockney), une langue enregistrée par IANA (i-cherokee) et des variantes de script (az-arabic, az-cyrillic). Le document ajoutait une réserve essentielle : aucune des sous-balises montrées n’avait encore été attribuée. Elles illustraient la syntaxe ; elles ne constituaient pas un catalogue de valeurs disponibles.

Pour une valeur hors des codes ISO préétablis, le demandeur remplissait un formulaire indiquant notamment le nom de la langue, son nom d’origine, une description publiée et des informations utiles. Le formulaire passait deux semaines sur une liste ouverte. Un réviseur nommé par le directeur de l’aire Applications de l’IETF pouvait transmettre la demande à IANA ou la rejeter après des objections importantes ; une contestation pouvait remonter à l’IESG. Une graphie commune devenait vérifiable grâce à un dossier public, pas simplement parce que quelqu’un ajoutait un suffixe après un trait d’union.

La procédure restait circonscrite : elle enregistrait des identifiants et leurs références, pas une interface universelle. Une balise ne disait pas à chaque protocole s’il devait choisir une représentation, filtrer une bibliothèque, ouvrir une route ou afficher un sélecteur de langue. Ce comportement dépendait du contexte qui employait la balise.

Un en-tête pouvait énumérer les langues sans définir le sélecteur

RFC 1766 définissait également Content-Language, qui pouvait contenir plusieurs balises complètes. Pour multipart/alternative de MIME, un paramètre Differences permettait d’indiquer que les différentes parties se distinguaient par leur langue. Le texte expliquait pourquoi un lecteur pouvait exploiter cette information, mais laissait hors de son champ le mécanisme qui choisirait la partie à présenter.

Trois questions restaient ainsi distinctes : quelle chaîne identifie la langue d’un objet, quel élément de protocole transporte cette chaîne, et ce qu’une application réceptrice en fait. Une balise pouvait figurer dans un en-tête de contenu ; un conteneur pouvait signaler des variantes linguistiques ; le lecteur devait encore disposer de son propre comportement de sélection. La RFC fournissait une étiquette commune et un point d’attache, pas une navigation universelle.

La suite confirme cette séparation. RFC 3066, publiée en 2001, autorisa les chiffres dans les sous-balises et introduisit la notion de language-range. Une plage pouvait correspondre à une balise complète ou à un préfixe s’arrêtant à la limite d’un trait d’union. C’était une opération de correspondance définie. RFC 3282 précisa ensuite les en-têtes Content-Language et Accept-Language, avec des plages de préférence et des valeurs de qualité facultatives. Ces ajouts ont donné des règles protocolaires explicites autour des balises ; ils n’ont pas fait du trait d’union d’origine un chemin générique.

RFC 4646 en 2006 puis RFC 5646 en 2009 poursuivirent l’évolution de BCP 47. Cette chronologie montre que syntaxe et registre ont changé. Elle ne prouve ni que chaque client traitait toutes les valeurs correctement, ni qu’une balise choisissait automatiquement une page, une traduction ou un rendu. L’apport historique de RFC 1766 est plus précis : un identifiant structuré peut rester une valeur indivisible pour l’application tandis que ses segments servent à l’administration du vocabulaire.

Sources et limites

La spécification est RFC 1766. La suite est documentée par RFC 3066, RFC 3282, RFC 4646 et RFC 5646. Ces textes établissent la grammaire, les enregistrements et les révisions protocolaires ; ils ne prouvent pas une implémentation ou un déploiement universels.