En-têtes de langage du contenu

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

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

Résumé

Le présent document définit un en-tête "Content-language:", à utiliser dans les cas où on désire indiquer le langage de quelque chose qui a des en-têtes du style de ceux de la RFC0822, comme les parties de corps MIME ou les documents de la Toile, et un en-tête "Accept-Language:" à utiliser dans les cas où on souhaite indiquer ses préférences en matière de langage.

1. Introduction

Un certain nombre de langages sont actuellement utilisés (6910) ou ont été utilisés par les hommes dans ce monde.

Une grande partie de ces personnes préfèreraient que les informations soient présentées dans un langage qu'elles comprennent.

Dans certains contextes, il est possible d'avoir des informations disponibles dans plus d'une langue, ou il serair possible de fournir des outils (comme des dictionnaires) pour aider à la compréhension d'une langue.

Dans d'autres cas, il peut être souhaitable d'utiliser un programme informatique pour convertir les informations d'un format (comme le texte en clair) dans un autre (comme de la voix synthétisée, ou du Braille, ou une impression haute définition).

Un prérequis pour de telles fonctions est un moyen pour étiqueter le contenu des informations avec un identifiant pour le langage utilisé dans ce contenu d'informations, comme ce qui est défini par la [RFC3066]. Le présent document spécifie un élément de protocole à utiliser avec les protocoles qui font usage d'en-têtes du style de ceux de la RFC0822 pour porter des étiquettes de langage telles que définies dans la [RFC3066].

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].

2. En-tête Content-language

L'en-tête "Content-Language" (langage du contenu) est destiné à être utilisé dans le cas où on désire indiquer le ou les langages de quelque chose qui a des en-têtes du genre de ceux de la RFC0822, comme des parties de corps MIME ou des documents de la Toile.

L'EBNF de la RFC0822 pour l'en-tête Content-Language était :

Content-Language = "Content-Language" ":" 1#Language-tag

Dans l'ABNF plus strict de la RFC2234 :

Content-Language = "Content-Language" ":" [CFWS] Language-List

Language-List = Language-Tag [CFWS] *("," [CFWS] Language-Tag [CFWS])

L'en-tête Content-Language peut énumérer plusieurs langues dans une liste aux éléments séparés par des virgules.

La construction CFWS (commentaire précédé et suivi d'un saut à la ligne) est destinée à fonctionner comme la convention d'espace blanche dans la RFC0822, qui signifie aussi qu'on peut placer des commentaires entre parenthèses n'importe où dans la séquence de langage, ou utiliser des lignes de continuation. Une définition formelle est donnée dans la [RFC2822].

En poursuivant la tradition de la RFC2822, une grammaire "obsolète" plus libérale est aussi donnée :

obs-content-language = "Content-Language" *WSP ":" [CFWS] Language-List

Comme dans la RFC2822, la présente spécification dit que les mises en œuvre conformes DOIVENT accepter la syntaxe obs-content-language, mais NE DOIVENT PAS la générer ; tous les en-têtes générés DOIVENT se conformer à la syntaxe de Content-Language.

2.1 Exemples de valeurs de Content-language

Enregistrement vocal provenant de Liverpool centre

Content-type: audio/basic

Content-Language: en-scouse

Document en Mingo, langage amérindien qui n'a pas de code ISO 639 :

Content-type: text/plain

Content-Language: i-mingo

Un dictionnaire anglais-français

Content-type: application/dictionary

Content-Language: en, fr (C'est un dictionnaire)

Un document officiel de la Commission européenne (dans quelques une des ses langues officielles) :

Content-type: multipart/alternative

Content-Language: da, de, el, en, fr, it

Un extrait de Star Trek

Content-type: video/mpeg

Content-Language: i-klingon

3. En-tête Accept-Language

L'en-tête "Accept-Language" (langues acceptées) est destiné à être utilisé dans des cas où un usager ou un processus désire identifier le ou les langues préférées lorsque on utilise des en-têtes du genre de ceux de la RFC0822, tels que des parties de corps MIME ou des documents de la Toile.

L'EBNF de la RFC0822 pour l'en-tête Accept-Language était :

Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )

La définition ABNF légèrement plus restrictive de la RFC2234 est :

Accept-Language = "Accept-Language:" [CFWS] language-q *( "," [CFWS] language-q )

language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]

qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )

Une définition ABNF plus libérale de la RFC2234 est :

Obs-accept-language = "Accept-Language" *WSP ":" [CFWS] obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]

obs-language-q = language-range [ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]

Comme la RFC2822, la présente spécification dit que les mises en œuvre conformes DOIVENT accepter la syntaxe obs-accept-language, mais NE DOIVENT PAS la générer ; tous les messages générés DOIVENT se conformer à la syntaxe Accept-Language.

La syntaxe et la sémantique de language-range sont définies dans la [RFC3066]. L'en-tête Accept-Language peut énumérer plusieurs gammes de langues dans une liste séparée par des virgules, et chacune peut inclure une valeur de qualité Q. Si aucune valeur Q n'est donnée, les gammes de langues sont données dans un ordre de priorité, la gamme de langue la plus à gauche étant la langue préferée ; ceci est une extension des règles de HTTP/1.1, mais correspond à la pratique actuelle.

Si des valeurs Q sont données, se référer à HTTP/1.1 [RFC2616] pour les détails sur la façon de les évaluer.

4. Considérations pour la sécurité

Le seul problème de sécurité qui soit soulevé avec les étiquettes de langage depuis la publication de la RFC 1766, qui déclarait que "les questions de sécurité sont estimées non pertinentes pour le présent mémoire", est celui des gammes de langues utilisées dans la négociation de contenu – qui peuvent être utilisées pour déduire la nationalité de l'envoyeur,et donc l'identifé de cibles potentielles aux fins de surveillance.

C'est un cas particulier du problème général que tout ce qu'on envoie est visible au receveur ; il est utile d'être conscient que de tels problèmes peuvent exister dans certains cas.

L'ampleur exacte de la menace, et les contre mesures possibles, sont laissées à l'appréciation de chaque protocle d'application.

5. Considérations sur les jeux de caractères

Le présent document n'ajoute pas de nouvelles considérations au delà de ce qui est mentionné dans la [RFC3066].

6. Remerciements

Le présent document a bénéficié de nombreux tours de relectures et commentaires dans divers forums de l'IETF et des groupes de travail de l'Internet.

Toute liste des contributeurs serait incomplète ; prière de ne considérer ce qui suit que comme une sélection parmi le groupe des personnes qui ont contribué à faire de ce document ce qu'il est aujourd'hui.

Par ordre alphabétique :

Tim Berners-Lee, Nathaniel Borenstein, Sean M. Burke, John Clews, Jim Conklin, John Cowan, Dave Crocker, Martin Duerst, Michael Everson, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Paul Hoffman, Olle Jarnefors, John Klensin, Bruce Lilly, Keith Moore, Chris Newman, Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, Misha Wolf, Francois Yergeau et de très nombreux autres.

Des remerciements particuliers sont dus à Michael Everson, qui a servi de correcteur de langage pendant presque toute la période, depuis la publication de la RFC 1766, et a fourni de nombreux apports à sa révision. Bruce Lilly s'est livré à la tâche particulière de relecture et de commentaire de mes définitions en ABNF.

7. Références

[RFC3066] H. Alvestrand, "Étiquettes pour l'identification des langues", BCP 47, janvier 2001. (Obsolète, voir RFC4646.)

[ISO 639] ISO 639:1988 (E/F) "Code pour la représentation des noms de langues" Organisation Internationale de Normalisation, 1^ère édition, 1988-04-01 Préparée par ISO/TC 37 - Terminologie (principes et coordination). Noter qu'une nouvelle version (ISO 639-1:2000) est en préparation au moment de cette publication.

[ISO 639-2] ISO 639-2:1998 "Codes pour la représentation des noms de langues -- Partie 2 : Code Alpha-3" - édition 1, 1998-11- 01, 66 pages, préparée par ISO/TC 37/SC 2

[ISO 3166] ISO 3166:1988 (E/F) "Codes pour la représentation des noms de pays" Organisation Internationale de Normalisation, 3^e édition, 1988-08-15.

[ISO 15924] ISO/DIS 15924 - Codes for the representation of names of scripts (en cours de développement par ISO TC46/SC2)

[RFC2045] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147.)

[RFC2047] K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

[RFC2048] N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-89)

[RFC2049] N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2616] R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817)

[RFC2822] P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

Appendice A Changements depuis la RFC1766

La définition des étiquettes de langage a été partagée et est maintenant dans la RFC 3066. Le paramètre des différences entre multipart/alternative ne fait plus partie de cette norme parce qu'aucune mise en œuvre de la fonction n'a jamais été faite. Consulter la RFC 1766 en cas de besoin des informations.

L'ABNF pour content-language a été mis à jour pour utiliser l'ABNF de la RFC 2234.

Adresse de l'auteur

Harald Tveit Alvestrand

Cisco Systems

Weidemanns vei 27

7043 Trondheim

Norge

mél : Harald@Alvestrand.no

téléphone : +47 73 50 33 52

Déclaration de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.