Network Working Group H. Alvestrand
Request for Comments: 3282 Cisco Systems
Obsoletes: 1766 May 2002
Category: Standards Track
Content Language Headers
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language.
1は、MIMEボディ部分やウェブドキュメントのようなRFC 822のようなヘッダを、持っているものの言語を示すことを望む場合に使用するため、ヘッダ、および「受け入れ言語：」：この文書では、「コンテンツ言語」を定義するヘッダ1は、言語に関して自分の好みを示すために、希望する場合に使用します。
There are a number of languages presently or previously used by human beings in this world.
現在または以前にこの世界の人間が使用する言語の数があります。
A great number of these people would prefer to have information presented in a language which they understand.
これらの人々の多くは、彼らが理解できる言語で提示された情報を持っていることを好むだろう。
In some contexts, it is possible to have information available in more than one language, or it might be possible to provide tools (such as dictionaries) to assist in the understanding of a language.
いくつかの状況では、複数の言語で利用可能な情報を持つことが可能である、または言語の理解を助けるために（辞書など）のツールを提供することが可能かもしれません。
In other cases, it may be desirable to use a computer program to convert information from one format (such as plaintext) into another (such as computer-synthesized speech, or Braille, or high-quality print renderings).
他の場合には、別の（例えば、コンピュータ合成音声、点字、または高品質の印刷レンダリングなど）中に（例えば、平文として）一つのフォーマットからの情報を変換するためにコンピュータプログラムを使用することが望ましいです。
A prerequisite for any such function is a means of labelling the information content with an identifier for the language that is used in this information content, such as is defined by [TAGS]. This document specifies a protocol element for use with protocols that use RFC 822-like headers for carrying language tags as defined in [TAGS].
このような機能のための前提条件は、[タグ]によって定義されるように、この情報の内容で使用される言語の識別子を有する情報コンテンツを標識する手段です。この文書では、[タグ]で定義されるように言語タグを運ぶためのRFC 822のようなヘッダを使用するプロトコルと共に使用するためのプロトコル要素を指定します。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります[RFC 2119]で説明されるように解釈されます。
The "Content-Language" header is intended for use in the case where one desires to indicate the language(s) of something that has RFC 822-like headers, such as MIME body parts or Web documents.
「コンテンツ言語」ヘッダは、一つには、そのようなMIMEボディパーツまたはWebドキュメントとしてRFC 822のようなヘッダを有するものの言語を示すことを望む場合に使用するために意図されています。
The RFC 822 EBNF of the Content-Language header is:
Content-LanguageヘッダのRFC 822 EBNFです。
Content-Language = "Content-Language" ":" 1#Language-tag
コンテンツ言語=の "Content-言語" "：" 1＃言語タグ
In the more strict RFC 2234 ABNF:
より厳密にRFC 2234 ABNFで：
Content-Language = "Content-Language" ":" [CFWS] Language-List Language-List = Language-Tag [CFWS] *("," [CFWS] Language-Tag [CFWS])
コンテンツ言語=の "Content-言語" "：" [CFWS]言語リスト言語リスト=言語タグ[CFWS] *（ "" [CFWS]言語タグ[CFWS]）
The Content-Language header may list several languages in a comma-separated list.
コンテンツ-Languageヘッダは、カンマで区切ったリストで複数の言語をリストすることがあります。
The CFWS construct is intended to function like the whitespace convention in RFC 822, which means also that one can place parenthesized comments anywhere in the language sequence, or use continuation lines. A formal definition is given in RFC 2822 [RFC2822].
CFWS構築物はまた、言語列の任意の場所に括弧コメントを配置、または継続行を使用することができるものを意味RFC 822で空白大会、のように機能することを意図しています。正式な定義は、RFC 2822 [RFC2822]で与えられています。
In keeping with the tradition of RFC 2822, a more liberal "obsolete" grammar is also given:
RFC 2822の伝統を踏まえて、より自由な「時代遅れ」な文法も与えられます。
obs-content-language = "Content-Language" *WSP ":" [CFWS] Language-List
OBS-コンテンツ言語=の "Content-言語" * WSP "：" [CFWS]言語-一覧
Like RFC 2822, this specification says that conforming implementations MUST accept the obs-content-language syntax, but MUST NOT generate it; all generated headers MUST conform to the Content-Language syntax.
RFC 2822と同様に、この仕様では、実装が準拠するOBS-コンテンツ言語の構文を受け入れなければならないが、それを生成してはならないと述べています。生成されたすべてのヘッダには、Content-言語の構文に従わなければなりません。
Voice recording from Liverpool downtown
音声は、リバプールの繁華街から録音します
Content-type: audio/basic Content-Language: en-scouse
コンテンツタイプ：オーディオ/基本的な内容言語：EN-scouse
Document in Mingo, an American Indian language which does not have an ISO 639 code:
ミンゴ、ISO 639コードを持っていないアメリカインディアンの言語でのドキュメント：
Content-type: text/plain Content-Language: i-mingo
コンテンツタイプ：text / plainのコンテンツ言語：I-ミンゴ
A English-French dictionary
英語 - フランス語辞書
Content-type: application/dictionary Content-Language: en, fr (This is a dictionary)
コンテンツタイプ：アプリケーション/辞書コンテンツ言語：EN、FR（これは辞書です）
An official European Commission document (in a few of its official languages):
（その公用語の数で）公式の欧州委員会の文書：
Content-type: multipart/alternative Content-Language: da, de, el, en, fr, it
コンテンツタイプ：マルチパート/代替コンテンツ言語：DA、デ、エル、EN、FR、それを
An excerpt from Star Trek
スター・トレックからの抜粋
Content-type: video/mpeg Content-Language: i-klingon
コンテンツ・タイプ：ビデオ/ MPEGコンテンツ-言語：I-クリンゴン
The "Accept-Language" header is intended for use in cases where a user or a process desires to identify the preferred language(s) when RFC 822-like headers, such as MIME body parts or Web documents, are used.
「受け入れ言語」ヘッダは、ユーザまたはプロセスがそのようなMIMEボディパーツまたはWebドキュメントとしてRFC 822のようなヘッダが、使用される言語（複数可）を識別することを望む場合に使用するために意図されています。
The RFC 822 EBNF of the Accept-Language header is:
Accept-LanguageヘッダーのRFC 822 EBNFです。
Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )
受け入れる言語= "受け入れる言語を" "：" 1＃（言語範囲[ ";" "q" を "=" のqvalue]）
A slightly more restrictive RFC 2234 ABNF definition is:
少しより制限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") ] )
";" [CFWS]言語のQ *（ "" [CFWS]言語-Q）言語Q =言語範囲[：= "受け入れる言語を" 言語を受け入れます[CFWS "Q =" のqvalue] [CFWS]のqvalue =（ "0" [ "" 0 * 3DIGIT]）/（ "1" [ "" 0 * 3（ "0"）]）
A more liberal RFC 2234 ABNF definition is:
より自由な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 ]
OBS-受け入れる言語は= * "言語を受け入れ" WSP "：" [CFWS] OBS言語-Q×（ "" [CFWS] OBS言語-Q）[CFWS] OBS言語-Q =言語範囲[CFWS] ";" [CFWS "Q" [CFWS] "=" のqvalue]
Like RFC 2822, this specification says that conforming implementations MUST accept the obs-accept-language syntax, but MUST NOT generate it; all generated messages MUST conform to the Accept-Language syntax.
RFC 2822のように、この仕様は、準拠する実装がOBS-受け入れる言語の構文を受け入れなければならないが、それを生成してはならないと述べています。生成されたすべてのメッセージが受け入れ言語の構文に従わなければなりません。
The syntax and semantics of language-range is defined in [TAGS]. The Accept-Language header may list several language-ranges in a comma-separated list, and each may include a quality value Q. If no Q values are given, the language-ranges are given in priority order, with the leftmost language-range being the most preferred language; this is an extension to the HTTP/1.1 rules, but matches current practice.
言語範囲の構文と意味論は[TAGS]で定義されています。 Accept-Languageヘッダは、コンマ区切りのリストにいくつかの言語の範囲を一覧表示することができ、それぞれにはQ値が与えられていない場合、言語範囲は左端言語範囲で、優先順に与えられる品質値Qを含んでいてもよいです最も好ましい言語であること。これは、HTTP / 1.1のルールに拡張したものであるが、現在の慣行と一致しました。
If Q values are given, refer to HTTP/1.1 [RFC 2616] for the details on how to evaluate it.
Q値が与えられた場合、それを評価する方法の詳細については、HTTP / 1.1 [RFC 2616]を参照してください。
The only security issue that has been raised with language tags since the publication of RFC 1766, which stated that "Security issues are believed to be irrelevant to this memo", is a concern with language ranges used in content negotiation - that they may be used to infer the nationality of the sender, and thus identify potential targets for surveillance.
「セキュリティ問題はこのメモとは無関係であると考えている」と述べたRFC 1766の出版以来、言語タグで提起された唯一のセキュリティ問題は、コンテンツネゴシエーションで使用される言語範囲と懸念される - 彼らは使用することができること送信者の国籍を推測し、したがって監視のための潜在的標的を同定します。
This is a special case of the general problem that anything you send is visible to the receiving party; it is useful to be aware that such concerns can exist in some cases.
これは、あなたが送信何かが受信側に表示されていることを、一般的な問題の特殊なケースです。そのような懸念は、いくつかのケースで存在することがあるので注意してくださいするのに便利です。
The exact magnitude of the threat, and any possible countermeasures, is left to each application protocol.
脅威の正確な大きさ、および任意の可能な対策は、各アプリケーションプロトコルに残されます。
This document adds no new considerations beyond what is mentioned in [TAGS].
この文書では、[タグ]に記載されているものを超えて新たな考慮事項が追加されていません。
This document has benefited from many rounds of review and comments in various fora of the IETF and the Internet working groups.
この文書は、IETFの様々なフォーラムやインターネットワーキンググループで検討し、コメントの多くのラウンドの恩恵を受けています。
Any list of contributors is bound to be incomplete; please regard the following as only a selection from the group of people who have contributed to make this document what it is today.
貢献者の任意のリストが不完全であることがバインドされています。それが今日である何、この文書を作るために貢献した人々のグループからのみ選択として以下のことを考えてください。
In alphabetical order:
アルファベット順：
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 and many, many others.
ティム・バーナーズ=リー、ナサニエル・ボレンスタイン、ショーンM. Burke氏、ジョン・Clews、ジムコンクリン、ジョン・コーワン、デイブ・クロッカー、マーティンDuerst、マイケル・エバーソン、ネッドフリード、ティム・グッドウィン、ダーク・ウィレム・バン・ガリク、マリオン・ガン、ポール・ホフマン、オルレJarnefors、ジョン・クレンシン、ブルース・リリー、キース・ムーア、クリス・ニューマン、正隆太田、Keldジョーンシモンセン、リースWeatherley、ミーシャ・ウルフ、フランソワYergeau、多くの、多くの他。
Special thanks must go to Michael Everson, who has served as language tag reviewer for almost the entire period, since the publication of RFC 1766, and has provided a great deal of input to this revision. Bruce Lilly did a special job of reading and commenting on my ABNF definitions.
特別な感謝は、RFC 1766の出版以来、ほぼ全期間の言語タグ投稿者を務めており、この改正への入力の多くを提供してきたマイケル・エバーソンに行かなければなりません。ブルース・リリーは読んで、私のABNFの定義にコメントの特別な仕事をしてくれました。
[TAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066
[タグ] Alvestrand、H.、 "言語の識別のためのタグ"、BCP 47、RFC 3066
[ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988-04-01 Prepared by ISO/TC 37 - Terminology (principles and coordination). Note that a new version (ISO 639-1:2000) is in preparation at the time of this writing.
[ISO 639] ISO 639：1988（E / F） - 言語の名前の表現のためのコード - 国際標準化機構、第1版、1988年4月1日ISO / TC 37により調製 - 用語（原則との連携） 。この記事の執筆時点で準備中です：新しいバージョン（2000 ISO 639-1）があることに注意してください。
[ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1, 1998-11- 01, 66 pages, prepared by ISO/TC 37/SC 2
[ISO 639-2] ISO 639-2：1998 - 言語の名前の表現のためのコード - パート2：アルファ-3コード - 版1、1998-11- 01、66ページ、/ ISO / TC 37で調製SC 2
[ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15.
[ISO 3166] ISO 3166：1988（E / F） - 国の名前の表現のためのコード - 国際標準化機構、第3版、1988年8月15日。
[ISO 15924] ISO/DIS 15924 - Codes for the representation of names of scripts (under development by ISO TC46/SC2)
[ISO 15924] ISO / DIS 15924 - （ISO TC46 / SC2によって開発中の）スクリプトの名前の表現のためのコード
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC 2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC 2046]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC 2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[RFC 2048]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
[RFC 2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC 2049]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC 2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC 2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
Appendix A: Changes from RFC 1766
付録A：RFC 1766からの変更点
The definition of the language tags has been split, and is now RFC 3066. The differences parameter to multipart/alternative is no longer part of this standard, because no implementations of the function were ever found. Consult RFC 1766 if you need the information.
言語タグの定義は、分割、および機能のない実装は、これまで発見されなかったので、/代替にmultipartする差異パラメータは、この規格の一部ではなくなった今、RFC 3066でされています。あなたは情報が必要な場合は、RFC 1766を参照してください。
The ABNF for content-language has been updated to use the RFC 2234 ABNF.
コンテンツ言語のためのABNFは、RFC 2234 ABNFを使用するように更新されました。
Author's Address
著者のアドレス
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim NORWAY
ハラルド・トバイット・アルベストランドシスコシステムズWeidemanns道27 7043トロンハイムノルウェー
EMail: Harald@Alvestrand.no Phone: +47 73 50 33 52
電子メール：Harald@Alvestrand.no電話：+47 73 50 33 52
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。