この文書は、 H. Alvestrand: Content Language Headers (RFC 3282), May 2002. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。
Network Working Group Request for Comments: 3282 Obsoletes: 1766 Category: Standards Track
H. Alvestrand
Cisco Systems
May 2002
この文書は、インターネットコミュニティにおけるインターネット標準化過程プロトコルを規定し、改良のために議論と提案を求めるものである。 このプロトコルの標準化状態と状況については、"Internet Official ProtocolStandards" (STD 1) の最新版を参照していただきたい。 この文書の配布に制限は無い。
Copyright © The Internet Society (2002). All Rights Reserved.
この文書は、MIME ボディ部分や Web 文書のような、RFC 822 ライクなヘッダを持つものについてその言語を示したい場合に使用するための "Content-Language:" ヘッダと、言語に関してより望むものを識別したい場合に使用するための "Accept-Language:" ヘッダを定義する。
世界中には、現在あるいは過去に人間に使用されてきた無数の言語がある。
これらの人々の非常に多くは、彼らが理解できる言語によって表現された情報を取得できるのであれば、それを望むであろう。
いくつかの状況では、情報を複数の言語で利用する事ができる、あるいは言語の理解の助けとなる (辞書のような) 道具を提供する事もできるかもしれれない。
その他の場合では、(プレーンテキストのような) ある形式から (コンピュータ合成スピーチ、ブライユ点字法、あるいは高品質な印刷用表現等の) 他の形式に情報を変換するためのコンピュータプログラムを使う事が望ましいかもしれない。
このような機能では、[TAGS] にて定義されているような、この情報内容中で使用されている言語の識別子をもってその情報内容をラベリングするという手法が不可欠である。 この文書は、[TAGS] 中で定義された言語タグを伝えるための RFC 822 ライクなヘッダを使用するプロトコルで使用するためのプロトコル要素を詳述するものである。
この文書中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 各キーワードは、[RFC 2119] 中に記述されるように解釈されるべきである。
"Content-Language" ヘッダは、MIME ボディ部分や Web 文書のような、RFC822 ライクなヘッダを持つものについてその言語を示したい場合での使用が意図される。
Content-Language ヘッダの RFC 822 EBNF は以下の通りである:
Content-Language = "Content-Language" ":" 1#Language-tag
より厳格な RFC 2234 ABNF では:
Content-Language = "Content-Language" ":" [CFWS] Language-List
Language-List = Language-Tag [CFWS]
*("," [CFWS] Language-Tag [CFWS])
Content-Language ヘッダは、コンマで区切られるリストによってて複数の言語を列挙できる。
CFWS 構造は、 RFC 822 において空白を置く慣習のように機能する事を意図しており、これは括弧で括られるコメントを言語シーケンス中の任意の場所に置けるという事や、複数行使用できるという事も意味する。 正式な定義はRFC 2822 [RFC 2822] 中に与えられる。
RFC 2822 の慣習より引き続き、より寛大な "旧式の" 文法も与えられる:
obs-content-language = "Content-Language" *WSP ":"
[CFWS] Language-List
RFC 2822 同様、この仕様書では、これに従う実装は obs-content-language構文を受け入れなければならない が、これを生成してはならない という事を述べる; すなわち、全ての生成されるヘッダは、Content-Languageの構文に従わなければならない。
Liverpool の下町にて録音された声
Content-type: audio/basic Content-Language: en-scouse
Mingo という、ISO 639 コードを持たないアメリカンインディアンの言語による文書
Content-type: text/plain Content-Language: i-mingo
英仏辞典
Content-type: application/dictionary Content-Language: en, fr (This is a dictionary)
公式な欧州委員会の (その公用語のいくつかによる) 文書
Content-type: multipart/alternative Content-Language: da, de, el, en, fr, it
Star Trek からの引用
Content-type: video/mpeg Content-Language: i-klingon
"Accept-Language" ヘッダは、MIME ボディ部分や Web 文書のような、RFC822 ライクなヘッダが使用される時に、ユーザやそのプロセスがより望む言語を識別したい場合での使用が意図される。
Accept-Language ヘッダの RFC 822 EBNF は以下の通りである:
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
それよりわずかに限定的な RFC 2234 ABNF では:
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") ] )
より寛大な RFC 2234 ABNF では:
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 ]
RFC 2822 同様、この仕様書では、これに従う実装は obs-accept-language構文を受け入れなければならない が、これを生成してはならない という事を述べる; すなわち、全ての生成されるヘッダは、Content-Languageの構文に従わなければならない。
language-range の構文と意味論{semantics} は、[TAGS] で定義されている。 Accept-Language ヘッダは、コンマで区切られるリストによってて複数の言語を列挙でき、またその各々は品質値 Q を含む事ができる。 Q 値が与えられていない場合、language-range は列挙順に与えられ、最も左の language-range が最優先の言語となる; これは HTTP/1.1 規則の拡張であるが、現在の慣習と一致している。
Q 値が与えられている場合に、これを評価するための方法の詳細についてはHTTP/1.1 [RFC 2616] を参照。
RFC 1766 では、"セキュリティ問題はこの文書とは無関係であると考えられる" としていたが、その発行以来、言語タグに関する唯一のセキュリティ問題が浮上してきており、それは内容ネゴシエーション中で使用される言語範囲に関係する - すなわち、送信者の国籍を推測するために使用でき、それ故監視のための潜在的な目標を識別するために使用する事ができる。
これは、あなたが送信したものが全て受信する相手に見る事ができるという一般的な問題の特別の場合である; そのような関心を持つ人もいるという事に気づいているという事は有用である。
その脅威の正確な大きさの評価、及びあらゆる可能な対抗策は、各適用プロトコルに委ねられる。
この文書では [TAGS] にて言及されるもの以上の考察は追加しない。
この文書は、IETF やインターネットワーキンググループの様々なフォーラムの中で何度も繰り返し検討及びコメントの恩恵を受けてきた。
あらゆる貢献者のリストは永遠に不完全なままであろう; 以下の方々は、この文書を今日のものとするために貢献した方々のグループからのみ選んだと見なして頂きたい。
アルファベット順に:
Tim Berners-Lee, Nathaniel Borenstein, Sean M. Burke, John Clews, JimConklin, John Cowan, Dave Crocker, Martin Duerst, Michael Everson,Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, PaulHoffman, Olle Jarnefors, John Klensin, Bruce Lilly, Keith Moore,Chris Newman, Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley,Misha Wolf, Francois Yergeau, そしてその他の多くの方々。
Michael Everson には特別なる感謝をしなければならない。 彼は、RFC 1766 の発行以降ほとんど全ての期間言語タグの検討を務め、またこの改訂版に多大なる入力を与えてくれた。 Bruce Lilly は私の ABNF 定義を読み、コメントするという特別な働きをしてくれた。
言語タグの定義は分離され、現在は RFC 3066 となっている。 multipart/alternative の differences パラメータについては、この機能を実装するものが見られなかったので、この標準にはもはや載っていない。 もし情報が必要なれば、RFC 1766 を参照の事。
content-language についての ABNF は、RFC 2234 ABNF を使用するように更新された。
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim NORWAY EMail: Harald@Alvestrand.no Phone: +47 73 50 33 52
Copyright © The Internet Society (2001). All Rights Reserved.
この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。
上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。
この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。
RFC Editer 機構の資金は、現在インターネット学会から提供されている。