この文書は， Phillips & Davis, Matching of Language Tags (RFC 4647), September 2006. の Masashi Nakanishi による日本語訳です。
利用の前に，このサイトの RFC 日本語訳の注意事項に目を通してください。
Network Working Group Request for Comments: 4647 BCP: 47 Obsoletes: 3066 Category: Best Current Practice
A. Phillips, Ed.
Yahoo! Inc.
M. Davis, Ed.
Google
September 2006
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
この文書は，インターネットコミュニティのためにインターネットの現時点における最善の実践（ベストカレントプラクティス）を規定し，改良のために議論と提案を求めるものである。 この文書の配布に制限は無い。
Copyright © The Internet Society (2006).
This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766.
この文書は，"言語範囲" ("language-range") と呼ばれる，ユーザの言語選好のリスト項目を構成するための構文を記述する。 また，言語範囲と言語タグ (language tags) を比較し照合するためのメカニズムについて記述する。 フィルタリングとルックアップの2種類の照合メカニズムが定義される。 フィルタリングは言語タグの(空かもしれない)集合を取り出し，ルックアップは単一の言語タグを取り出す。 言語ネゴシエーションやコンテント選択といった応用があり得る。 この文書は，RFC 4646 との組み合わせによって，RFC 1766 を上書きした RFC 3066 をさらに上書きする。
Human beings on our planet have, past and present, used a number of languages. There are many reasons why one would want to identify the language used when presenting or requesting information.
この星の人類は，今も昔も，多くの言語を使ってきた。 情報を提示したり要求したりする際に使用される言語を同定したい理由は様々ある。
Applications, protocols, or specifications that use language identifiers, such as the language tags defined in [RFC4646], sometimes need to match language tags to a user's language preferences.
[RFC4646] に定義される言語タグのような言語識別子を用いるアプリケーション，プロトコル，その他の仕様では， 言語タグをユーザの言語選好と照合する必要が生じる。
This document defines a syntax (called a language range (Section 2)) for specifying items in the user's list of language preferences (called a language priority list (Section 2.3)), as well as several schemes for selecting or filtering sets of language tags by comparing the language tags to the user's preferences. Applications, protocols, or specifications will have varying needs and requirements that affect the choice of a suitable matching scheme.
この文書は，ユーザの言語選考のリスト (言語優先度リスト (language priority list) (Section 2.3) と呼ばれる) において項目を指定するための構文 (言語範囲 (Section 2) と呼ばれる) を定義する。
This document describes how to indicate a user's preferences using language ranges, three schemes for matching these ranges to a set of language tags, and the various practical considerations that apply to implementing and using these schemes.
この文書は，言語範囲を用いてユーザの選好を示す方法， 言語範囲と言語タグの集合とを照合するための3つのスキーム， これらのスキームを実装し使用するにあたっての様々な実践的考察について記述する。
This document, in combination with [RFC4646], replaces [RFC3066], which replaced [RFC1766].
この文書は，[RFC4646] との組み合わせによって，[RFC1766] を上書きした [RFC3066] をさらに上書きする。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は， [RFC 2119] にて記述されているように解釈されるべきである。
Language tags [RFC4646] are used to help identify languages, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. Applications, protocols, or specifications that use language tags are often faced with the problem of identifying sets of content that share certain language attributes. For example, HTTP/1.1 [RFC2616] describes one such mechanism in its discussion of the Accept-Language header (Section 14.4), which is used when selecting content from servers based on the language of that content.
言語タグ [RFC4646] は，コミュニケーションのために，話し言葉，書き言葉，手話，その他の合図の何であれ，言語を識別するために用いられる。 言語タグを用いるアプリケーション，プロトコル，その他の仕様は，しばしば，ある言語属性を持つコンテント集合を識別するという問題に直面する。 例えば，HTTP/1.1 [RFC2616] では Accept-Language ヘッダ (Section 14.4) の検討においてそのようなメカニズムを規定しており， それはコンテントの言語に基づいてサーバからコンテントを選択する際に用いられる。
It is, thus, useful to have a mechanism for identifying sets of language tags that share specific attributes. This allows users to select or filter the language tags based on specific requirements. Such an identifier is called a "language range".
従って，特定の属性を共有する言語タグの集合を同定するメカニズムは有益である。 これによってユーザは特定の要件に基づいて言語タグを選択しフィルタすることができる。 そのような識別子は "言語範囲" と呼ばれる。
There are different types of language range, whose specific attributes vary according to their application. Language ranges are similar to language tags: they consist of a sequence of subtags separated by hyphens. In a language range, each subtag MUST either be a sequence of ASCII alphanumeric characters or the single character '*' (%x2A, ASTERISK). The character '*' is a "wildcard" that matches any sequence of subtags. The meaning and uses of wildcards vary according to the type of language range.
言語範囲には様々なタイプがあり，その特定の属性は応用次第で異なる。 言語範囲は言語タグと類似している: それはハイフンで区切られたサブタグの並びから成る。 ある言語範囲の中で，それぞれのサブタグはASCII英数字の文字列か，または '*' (%x2A, ASTERISK) という一文字でなければならない。 文字 '*' は "ワイルドカード" であり，いかなるサブタグの並びにもマッチする。 ワイルドカードの意味と用法は言語範囲のタイプによって異なる。
Language tags and thus language ranges are to be treated as case- insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning. Matching of language tags to language ranges MUST be done in a case- insensitive manner.
言語タグと言語範囲は大文字小文字を区別して扱われるべきではない: いくつかのサブタグを大文字にする慣習が存在するが，それが何か意味を持ってはならない。 言語タグと言語範囲との照合は大文字小文字を区別しないやり方で行われなければならない。
A "basic language range" has the same syntax as an [RFC3066] language tag or is the single character "*". The basic language range was originally described by HTTP/1.1 [RFC2616] and later [RFC3066]. It is defined by the following ABNF [RFC4234]:
"基本言語範囲" (basic language range) は [RFC3066] の言語タグと同じ構文である。あるいは "*" という一文字である。 この基本言語範囲はもともと HTTP/1.1 [RFC2616] とその後の [RFC3066] によって規定された。 これは ABNF [RFC4234] にて次のように定義される:
language-range = (1*8ALPHA *("-" 1*8alphanum)) / "*"
alphanum = ALPHA / DIGIT
A basic language range differs from the language tags defined in [RFC4646] only in that there is no requirement that it be "well- formed" or be validated against the IANA Language Subtag Registry. Such ill-formed ranges will probably not match anything. Note that the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the use of digits anywhere in the 'language-range' (see [RFC2616errata]).
基本言語範囲は，[RFC4646] において定義される言語タグと次の点で異なっている: "整形式" (well-formed) であることや IANA Language Subtag Registry と照らして妥当性検証されることを要件としていない。 そのような不整形式 (ill-formed) な言語範囲はおそらく何にもマッチしないだろう。 [RFC2616] における ABNF [RFC4234] での定義は，言語範囲のどこにも数字の使用を許していない点で誤っていることに注意されたい ([RFC2616errata] を参照)。
Occasionally, users will wish to select a set of language tags based on the presence of specific subtags. An "extended language range" describes a user's language preference as an ordered sequence of subtags. For example, a user might wish to select all language tags that contain the region subtag 'CH' (Switzerland). Extended language ranges are useful for specifying a particular sequence of subtags that appear in the set of matching tags without having to specify all of the intervening subtags.
ユーザは，特定のサブタグが入っていることに基づいて言語タグ集合を選択したいことがあるだろう。 "拡張言語範囲" (extended language range) は，ユーザの言語選好をサブタグの順序つき列として記述する。 例えば，ユーザはリージョンサブタグ 'CH' (Switzerland) を含んでいる全ての言語タグを選びたいかもしれない。 拡張言語範囲は，全ての中間のサブタグを指定することなしに，特定のサブタグの並びを指定するのに役立つ。
An extended language range can be represented by the following ABNF:
拡張言語範囲は ABNF で次のように表現される:
extended-language-range = (1*8ALPHA / "*")
*("-" (1*8alphanum / "*"))
The wildcard subtag '*' can occur in any position in the extended language range, where it matches any sequence of subtags that might occur in that position in a language tag. However, wildcards outside the first position are ignored by Extended Filtering (see Section 3.2.2). The use or absence of one or more wildcards cannot be taken to imply that a certain number of subtags will appear in the matching set of language tags.
ワールドカードサブタグ '*' は拡張言語範囲におけるどの位置にでも現れることができ， それはある言語タグの中のその位置に現れるであろう如何なるサブタグにもマッチする。 しかし，先頭の位置以外のワイルドカードは拡張フィルタリングにおいては無視される (Section 3.2.2 を参照) 。 １つ以上のワイルドカードの使用の有無は，マッチする言語タグ集合に一定の数のサブタグが現れることを意味すると受け取ることはできない。
A user's language preferences will often need to specify more than one language range, and thus users often need to specify a prioritized list of language ranges in order to best reflect their language preferences. This is especially true for speakers of minority languages. A speaker of Breton in France, for example, can specify "br" followed by "fr", meaning that if Breton is available, it is preferred, but otherwise French is the best alternative. It can get more complex: a different user might want to fall back from Skolt Sami to Northern Sami to Finnish.
ユーザの言語選好によっては複数の言語範囲を指定する必要がしばしば生じ， それによってユーザは自らの言語選好を最もよく反映させるために言語範囲の優先順位付きリストを指定する必要がある。 これはマイノリティの言語の話者である場合に特によくある。 例えば，フランスにおいてブルターニュ語の話者は "fr" に続いて "br" を指定することができ， これは「もしブルターニュ語が利用できるならそれが最も好まれ，そうでないならフランス語が最善の代替である」ということを意味する。 もっと複雑にもなり得る: 別のユーザはコルタ・サーミ語，次に北サーミ語，次にフィンランド語というのを望むかも知れない。
A "language priority list" is a prioritized or weighted list of language ranges. One well-known example of such a list is the "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section 14.4) and RFC 3282 [RFC3282].
"言語優先度リスト" (language priority list) は優先度付きあるいは重み付きの言語範囲リストである。 そのようなリストのよく知られた例の１つは RFC 2616 [RFC2616] (Section 14.4) と RFC 3282 [RFC3282] に定義されている "Accept-Language" ヘッダである。
The various matching operations described in this document include considerations for using a language priority list. This document does not define the syntax for a language priority list; defining such a syntax is the responsibility of the protocol, application, or specification that uses it. When given as examples in this document, language priority lists will be shown as a quoted sequence of ranges separated by commas, like this: "en, fr, zh-Hant" (which is read "English before French before Chinese as written in the Traditional script").
この文書に記述されている様々な照合操作は言語優先度リストを使用することを考慮に入れている。 この文書は言語優先度リストの構文を定義しない: そのような構文を定義することは，それを使用するプロトコル，アプリケーション，その他の仕様の責任である。 この文書で例として挙げる場合は，言語優先度リストはカンマで区切られた言語範囲の引用符付きの並びとして次のように表される: "en, fr, zh-Hant" (これは "優先度の高いものから順に英語，フランス語，繁体字中国語" と読む).
A simple list of ranges is considered to be in descending order of priority. Other language priority lists provide "quality weights" for the language ranges in order to specify the relative priority of the user's language preferences. An example of this is the use of "q" values in the syntax of the "Accept-Language" header (defined in [RFC2616], Section 14.4, and [RFC3282]).
言語範囲の単純なリストは優先度の降順であると見なされる。 他の言語優先度リストはユーザの言語選好の相対的優先度を指定するために各言語範囲に "品質ウェイト" を付ける。 これの一例は"Accept-Language" ヘッダの構文における "q" 値の使用である ([RFC2616] Section 14.4 と [RFC3282] に定義されている)。
Matching language ranges to language tags can be done in many different ways. This section describes three such matching schemes, as well as the considerations for choosing between them. Protocols and specifications requiring conformance to this specification MUST clearly indicate the particular mechanism used in selecting or matching language tags.
言語範囲と言語タグとの照合は様々なやり方がある。 この節では，3つの照合スキームを記述し，それらからの選択についても考察する。 この仕様に一致することを要求するプロトコルや仕様は，言語タグを選択，照合する際に用いられる特定のメカニズムを明確に示さなければならない。
There are two types of matching scheme in this document. A matching scheme that produces zero or more matching language tags is called "filtering". A matching scheme that produces exactly one match for a given request is called "lookup".
この文書には２タイプの照合スキームが記述されている。 ゼロ以上の言語タグを取り出す照合スキームは "フィルタリング" と呼ばれる。 あるリクエストに関して厳密に１つの言語タグを取り出す照合スキームは "ルックアップ" と呼ばれる。
Applications, protocols, and specifications are faced with the decision of what type of matching to use. Sometimes, different styles of matching are suited to different kinds of processing within a particular application or protocol.
アプリケーション，プロトコル，その他の仕様は，使用する照合のタイプに関する意思決定に直面する。 ある特定のアプリケーションやプロトコルの中で異なる種類の処理に対して異なるスタイルの照合が適当だということがときどきある。
This document describes three matching schemes:
この文書では，３つの照合スキームを記述する:
Filtering can be used to produce a set of results (such as a collection of documents) by comparing the user's preferences to a set of language tags. For example, when performing a search, filtering can be used to limit the results to items tagged as being in the French language. Filtering can also be used when deciding whether to perform a language-sensitive process on some content. For example, a process might cause paragraphs whose language tag matched the language range "nl" (Dutch) to be displayed in italics within a document.
フィルタリングはユーザの選好と言語タグの集合を比較することで (文書の集まりのような) 結果のセットを生成するために用いることができる。 例えば，検索を行うときに，フィルタリングはフランス語で書かれているとタグ付けされているアイテムだけに結果を絞るために用いることができる。 また，フィルタリングはあるコンテントにおいて言語に敏感な処理を行うかどうかを決定する際に用いることができる。 例えば，ある文書内で言語範囲 "nl" (Dutch) にマッチする言語タグで記述された段落をイタリックで表示させるという処理が行われるかもしれない。
Lookup produces the single result that best matches the user's preferences from the list of available tags, so it is useful in cases in which a single item is required (and for which only a single item can be returned). For example, if a process were to insert a human- readable error message into a protocol header, it might select the text based on the user's language priority list. Since the process can return only one item, it is forced to choose a single item and it has to return some item, even if none of the content's language tags match the language priority list supplied by the user.
ルックアップは，利用可能な言語タグのリストからユーザの選好に最もよく適合する単一の結果を取り出すので， １つの項目が要求され返される場合に有効である。 例えば，あるプロセスが人間が読めるエラーメッセージをプロトコルヘッダに挿入しようとするなら，ユーザの言語優先度リストに基づいてそのテキストを選択するかもしれない。 このプロセスはアイテムをたった１つ返すので，単一のアイテムを選ぶことが強制され，たとえコンテントの言語タグのどれもユーザから提供された言語優先度リストにマッチしなくても， アイテムを返さなければならない。
Language tag matching is a tool, and does not by itself specify a complete procedure for the use of language tags. Such procedures are intimately tied to the application protocol in which they occur. When specifying a protocol operation using matching, the protocol MUST specify:
言語タグ照合は１つのツールであり，それ自体によって言語タグの使用に関する完全な手続きを規定するわけではない。 そのような手続きは，それが行われるアプリケーションプロトコルと親密に結びついている。 言語タグ照合を用いるプロトコル操作を規定する際には，そのプロトコルは次のことを定めなければならない:
Applications, protocols, and specifications are not required to validate or understand any of the semantics of the language tags or ranges or of the subtags in them, nor do they require access to the IANA Language Subtag Registry (see Section 3 in [RFC4646]). This simplifies implementation.
アプリケーション，プロトコル，その他の仕様は，言語タグや言語範囲やサブタグの意味を理解したり妥当性検証することを要求されないし， IANA Language Subtag Registry ([RFC4646]の Section 3 を参照) にアクセすることも要求しない。 これによって実装が単純になる。
However, designers of applications, protocols, or specifications are encouraged to use the information from the IANA Language Subtag Registry to support canonicalizing language tags and ranges in order to map grandfathered and obsolete tags or subtags into modern equivalents.
しかし，アプリケーション，プロトコル，その他の仕様の設計者は，言語タグや言語範囲の正規化をサポートするにあたって， 旧制度のものや廃止された言語タグ，サブタグを現代的な同等物へマッピングするために， IANA Language Subtag Registry からの情報を利用することが推奨される。
Applications, protocols, or specifications that canonicalize ranges MUST either perform matching operations with both the canonical and original (unmodified) form of the range or MUST also canonicalize each tag for the purposes of comparison.
言語範囲を正規化するアプリケーション，プロトコル，その他の仕様は，言語範囲の標準的な形式でも元々の(変更されていない)形式でも照合操作を実行しなければならず， また，比較のためにそれぞれの言語タグを正規化しなければならない。
Note that canonicalizing language ranges makes certain operations impossible. For example, an implementation that canonicalizes the language range "art-lojban" (artificial language, lojban variant) to use the more modern "jbo" (Lojban) cannot be used to select just the items with the older tag.
言語範囲を正規化することは，ある特定のオペレーションを不可能にすることに注意されたい。 例えば，言語範囲 "art-lojban" (artificial language, lojban variant) をより現代的な "jbo" (Lojban) を用いて正規化する実装は， 古いほうの言語タグを伴ったアイテムを選択するために使用することができない。
Applications, protocols, or specifications that use basic ranges might sometimes receive extended language ranges instead. An application, protocol, or specification MUST choose to a) map extended language ranges to basic ranges using the algorithm below, b) reject any extended language ranges in the language priority list that are not valid basic language ranges, or c) treat each extended language range as if it were a basic language range, which will have the same result as ignoring them, since these ranges will not match any valid language tags.
基本言語範囲を用いるアプリケーション，プロトコル，その他の仕様は，ときどき代わりに拡張言語範囲を受け取るかもしれない。 アプリケーション，プロトコル，その他の仕様は，以下のどれかを選ばなければならない。 a) 下記のアルゴリズムを用いて拡張言語範囲を基本言語範囲に対応づける， b) 言語優先度リストの中の妥当な基本言語範囲でない拡張言語範囲を拒否する， c) 拡張言語範囲をあたかも基本言語範囲であるかのように扱う（これは，その言語範囲が如何なる言語タグともマッチしないので，無視するのと同じ結果になる）
An extended language range is mapped to a basic language range as follows: if the first subtag is a '*' then the entire range is treated as "*", otherwise each wildcard subtag is removed. For example, the extended language range "en-*-US" maps to "en-US" (English, United States).
拡張言語範囲は次のようにして基本言語範囲に対応づけられる: もし最初のサブタグが '*' ならばその言語範囲全体が "*" として扱われ，そうでなければ，各ワイルドカードサブタグが削除される。 例えば，拡張言語範囲 "en-*-US" は "en-US" (English, United States) に対応づけられる。
Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or configuration options. For example, an implementation could allow a user to associate or map a particular language range to a different value. Such a user might wish to associate the language range subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps a user would want to associate requests for the range "zh-Hans" (Chinese as written in the Simplified script) with content bearing the language tag "zh-CN" (Chinese as used in China, where the Simplified script is predominant). Documentation on how the ranges or tags are altered, prioritized, or compared in the subsequent match in such an implementation will assist users in making these types of configuration choices.
アプリケーション，プロトコル，その他の仕様は，特定の要件に取り組むにあたって，プリプロセッシングや設定オプションを提供できる。 例えば，ある実装は，ユーザが特定の言語範囲を異なる値に結びつけあるいは対応づけすることを許すかもしれない。 ユーザは例えば，言語範囲サブタグ 'nn' (Nynorsk Norwegian) と 'nb' (Bokmal Norwegian) をより一般的なサブタグ 'no' (Norwegian) に結びつけたいかもしれない。 あるいは，言語範囲 "zh-Hans" (簡体字中国語) に関するリクエストを言語タグ "zh-CN" (中国で使われている中国語, そこでは簡体字中国語が主流である) を持つコンテントに結びつけたいだろう。 そのような実装においてどのように言語範囲や言語タグが変造され，優先され，以降の照合にて比較されるかについて文書化することは，この種の設定の選択を行うにあたってユーザを助けるだろう。
Filtering is used to select the set of language tags that matches a given language priority list. It is called "filtering" because this set might contain no items at all or it might return an arbitrarily large number of matching items: as many items as match the language priority list, thus "filtering out" the non-matching items.
フィルタリングは与えられた言語優先度リストに適合する言語タグの集合を選び出すために用いられる。 この集合はアイテムをまったく持たないかもしれないし，多数の（言語優先度リストにマッチする限りの多くの）アイテムを返すかもしれない， つまり，マッチしないアイテムを "取り除く" (filtering out) ので，"フィルタリング" と呼ばれる。
In filtering, each language range represents the least specific language tag (that is, the language tag with fewest number of subtags) that is an acceptable match. All of the language tags in the matching set of tags will have an equal or greater number of subtags than the language range. Every non-wildcard subtag in the language range will appear in every one of the matching language tags. For example, if the language priority list consists of the range "de-CH" (German as used in Switzerland), one might see tags such as "de-CH-1996" (German as used in Switzerland, orthography of 1996) but one will never see a tag such as "de" (because the 'CH' subtag is missing).
フィルタリングにおいては，各言語範囲は，受け入れ可能な最小限に限定的な言語タグ（すなわち，最小の数のサブタグによる言語タグ）を表現する。 マッチした言語タグの集合に含まれるすべての言語タグは，その言語範囲と同じかそれより多いサブタグを持つ。 その言語範囲において全てのワイルドカードでないサブタグは，マッチした言語タグのすべてに含まれる。 例えば，言語優先度リストが言語範囲 "de-CH" (German as used in Switzerland) から成るなら，"de-CH-1996" (German as used in Switzerland, orthography of 1996) という言語タグが結果に含まれるかもしれないが，"de" という言語タグは含まれないだろう（サブタグ 'CH' がないため）。
If the language priority list (see Section 2.3) contains more than one range, the content returned is typically ordered in descending level of preference, but it MAY be unordered, according to the needs of the application or protocol.
もし言語優先度リスト (Section 2.3 を参照) は複数の言語範囲を含むなら，返されるコンテントは典型的には選好の降順で並べられるが， アプリケーションやプロトコルのニーズによっては順序づけられていなくてもよい。
Some examples of applications where filtering might be appropriate include:
フィルタリングが適切であろうアプリケーションの例としては:
Filtering seems to imply that there is a semantic relationship between language tags that share the same prefix. While this is often the case, it is not always true: the language tags that match a specific language range do not necessarily represent mutually intelligible languages.
フィルタリングは，同じ接頭辞を共有する言語タグ群の間には意味論的関係があることを含意するように見える。 これはしばしば正しいが，いつも正しいというわけではない: 特定の言語範囲に適合する言語タグ群は必然的に相互に理解可能な言語群を表すわけではない。
Basic filtering compares basic language ranges to language tags. Each basic language range in the language priority list is considered in turn, according to priority. A language range matches a particular language tag if, in a case-insensitive comparison, it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is "-". For example, the language-range "de-de" (German as used in Germany) matches the language tag "de-DE-1996" (German as used in Germany, orthography of 1996), but not the language tags "de-Deva" (German as written in the Devanagari script) or "de-Latn-DE" (German, Latin script, as used in Germany).
基本フィルタリングは基本言語範囲を言語タグと比較する。 言語優先度リストの中の各基本言語範囲は，優先度に従って，順番に考慮される。 ある言語範囲は，大文字小文字を区別しない比較において，正確に同じ言語タグであるか，言語タグの接頭辞と正確に同じでその接頭辞に続く最初の文字が "-" である場合に， その特定の言語タグにマッチする。 例えば，言語範囲 "de-de" (ドイツで使用されているドイツ語) は言語タグ "de-DE-1996" (ドイツで使用されているドイツ語で，1996年の正字法) にマッチするが， 言語タグ "de-Deva" (ディーバナーガリ文字で書かれたドイツ語) や "de-Latn-DE" (ドイツで使用されている，ラテン文字のドイツ語) にはマッチしない。
The special range "*" in a language priority list matches any tag. A protocol that uses language ranges MAY specify additional rules about the semantics of "*"; for instance, HTTP/1.1 [RFC2616] specifies that the range "*" matches only languages not matched by any other range within an "Accept-Language" header.
言語優先度リストの中の特別な言語範囲 "*" は如何なる言語タグにもマッチする。 言語範囲を用いるプロトコルは "*" の意味について追加ルールを規定してもよい。 例えば，HTTP/1.1 [RFC2616] は言語範囲 "*" は "Accept-Language" ヘッダ内の他のどの言語範囲にもマッチしなかった言語にのみマッチすると規定している。
Basic filtering is identical to the type of matching described in [RFC3066], Section 2.5 (Language-range).
基本フィルタリングは [RFC3066] の Section 2.5 (Language-range) に記述されている照合と同一である。
Extended filtering compares extended language ranges to language tags. Each extended language range in the language priority list is considered in turn, according to priority. A language range matches a particular language tag if each respective list of subtags matches. To determine a match:
拡張フィルタリングは拡張言語範囲と言語タグを比較する。 言語優先度リストの中の各拡張言語範囲は，優先度に従って，順番に考慮される。 ある言語範囲は，個別のサブタグのリストにマッチするなら，その特定の言語タグにマッチする。 マッチするかどうかを決定するには:
Subtags not specified, including those at the end of the language range, are thus treated as if assigned the wildcard value '*'. Much like basic filtering, extended filtering selects content with arbitrarily long tags that share the same initial subtags as the language range. In addition, extended filtering selects language tags that contain any intermediate subtags not specified in the language range. For example, the extended language range "de-*-DE" (or its synonym "de-DE") matches all of the following tags:
このように，言語範囲の末尾のそれも含めて，指定されていないサブタグは，あたかもワイルドカード値 '*' が割り当てられたものとして扱われる。 基本フィルタリングと同様に，拡張フィルタリングは，その言語範囲と同じ先頭サブタグを共有する任意の長い言語タグを伴うコンテントを選び出す。 加えて，拡張フィルタリングは，言語範囲において指定されていないどんな中間サブタグを含んでいる言語タグも選び出す。 例えば，拡張言語範囲 "de-*-DE" (あるいはこれと同義の "de-DE") は次の全ての言語タグにマッチする:
The same range does not match any of the following tags for the reasons shown:
この拡張言語範囲は，次の言語タグにはそこに示した理由によってマッチしない:
de (missing 'DE')
de-x-DE (singleton 'x' occurs before 'DE')
de-Deva ('Deva' not equal to 'DE')
de ('DE' がない)
de-x-DE (単一文字 'x' が 'DE' の前に現れている)
de-Deva ('Deva' は 'DE' と等しくない)
Note: [RFC4646] defines each type of subtag (language, script, region, and so forth) according to position, size, and content. This means that subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as 'Latn' is always a script subtag (unless it follows a singleton) while a subtag such as 'nedis' can only match the equivalent variant subtag. Two-letter subtags in the initial position have a different type (language) than two-letter subtags in later positions (region). This is the reason why a wildcard in the extended language range is significant in the first position but is ignored in all other positions.
[RFC4646] は，位置，サイズ，内容に従ってサブタグの各タイプ（言語，文字，地域など）を定義していることに注意されたい。 これは，言語範囲の中のサブタグが言語タグの中の特定のタイプのサブタグにのみマッチし得るということを意味する。 例えば，'Latn' のようなサブタグは（単一文字サブタグに続くのでない限り）常に用字サブタグ (script subtag) であり， 'nedis' のようなサブタグは同等な異体サブタグ (variant subtag) としかマッチしない。 先頭位置の二文字サブタグ (言語) は，それより後ろの二文字サブタグ (地域) とは異なるタイプである。 これは，拡張言語範囲におけるワイルドカードが先頭位置では重要であるが他の位置では無視される理由である。
Lookup is used to select the single language tag that best matches the language priority list for a given request. When performing lookup, each language range in the language priority list is considered in turn, according to priority. By contrast with filtering, each language range represents the most specific tag that is an acceptable match. The first matching tag found, according to the user's priority, is considered the closest match and is the item returned. For example, if the language range is "de-ch", a lookup operation can produce content with the tags "de" or "de-CH" but never content with the tag "de-CH-1996". If no language tag matches the request, the "default" value is returned.
ルックアップは，あるリクエストに関する言語優先度リストに最もよくマッチする単一の言語タグを選ぶために用いられる。 ルックアップを実行するとき，言語優先度リストの中の各言語範囲は，優先度に従って，順番に考慮される。 フィルタリングとは対照的に，各言語範囲は受け入れ可能な最も限定的な言語タグを表す。 ユーザの優先度に従って最初に見つかったマッチする言語タグは，最も近いマッチと見なされ，それが返される。 例えば，もし言語範囲が "de-ch" なら，ルックアップは言語タグ "de" や "de-CH" を伴うコンテントを取り出すが， 言語タグ "de-CH-1996" を伴うコンテントを取り出すことはない。 もしどんな言語タグもリクエストにマッチしなければ，"デフォルト" の値が返される。
For example, if an application inserts some dynamic content into a document, returning an empty string if there is no exact match is not an option. Instead, the application "falls back" until it finds a matching language tag associated with a suitable piece of content to insert. Some applications of lookup include:
例えば，あるアプリケーションが動的コンテントを文書の中に挿入するなら，マッチするものがない場合に空の文字列を返すのは許されない。 その代わりに，そのアプリケーションは，挿入するコンテントの適当な一部に結びつけられた言語タグのうちマッチするものを見つけるまで，"後戻り" (falls back) する。 ルックアップを行うアプリケーションには次のようなものがある:
In the lookup scheme, the language range is progressively truncated from the end until a matching language tag is located. Single letter or digit subtags (including both the letter 'x', which introduces private-use sequences, and the subtags that introduce extensions) are removed at the same time as their closest trailing subtag. For example, starting with the range "zh-Hant-CN-x-private1-private2" (Chinese, Traditional script, China, two private-use tags) the lookup progressively searches for content as shown below:
ルックアップスキームでは，マッチする言語タグが見つかるまで，言語範囲は後ろから漸次的に切り詰められる。 一文字の英数字のサブタグ（これは私用シーケンスの開始を意味する文字 'x' や拡張の開始を意味するサブタグを含む）はその後ろ隣のサブタグが削られると同時に削られる。 例えば，言語範囲 "zh-Hant-CN-x-private1-private2" (中国語, 繁体字, 中国, 2つの私用サブタグ) で開始すると，ルックアップは下に示すコンテントを順に探す:
Example of a Lookup Fallback Pattern Range to match: zh-Hant-CN-x-private1-private2 1. zh-Hant-CN-x-private1-private2 2. zh-Hant-CN-x-private1 3. zh-Hant-CN 4. zh-Hant 5. zh 6. (default)
ルックアップ後戻りパターンの例 マッチさせる言語範囲: zh-Hant-CN-x-private1-private2 1. zh-Hant-CN-x-private1-private2 2. zh-Hant-CN-x-private1 3. zh-Hant-CN 4. zh-Hant 5. zh 6. (default)
This fallback behavior allows some flexibility in finding a match. Without fallback, the default content would be returned immediately if exactly matching content is unavailable. With fallback, a result more closely matching the user request can be provided.
この後戻りは，マッチするものを見つけるにあたって柔軟性をもたらす。 後戻りなしでは，もし正確にマッチするコンテントがなければ，デフォルトコンテントが即座に返されるだろう。 後戻りがあると，ユーザのリクエストにより近くマッチした結果を取り出すことができる。
Extensions and unrecognized private-use subtags might be unrelated to a particular application of lookup. Since these subtags come at the end of the subtag sequence, they are removed first during the fallback process and usually pose no barrier to interoperability. However, an implementation MAY remove these from ranges prior to performing the lookup (provided the implementation also removes them from the tags being compared). Such modification is internal to the implementation and applications, protocols, or specifications SHOULD NOT remove or modify subtags in content that they return or forward, because this removes information that can be used elsewhere.
拡張サブタグと認識されない私用サブタグはルックアップを行うアプリケーションに関わらないかも知れない。 これらのサブタグはサブタグの並びの末尾に位置するので，後戻りプロセスでは最初に削られ，通常は相互運用性に関して何の障害も引き起こさない。 しかし，ある実装が，ルックアップを実行する前に，言語範囲からこれらを削除してもよい （その実装は比較される言語タグからもそれらを削除するならば）。 そのような修正点はその実装の内部に関するものであり，アプリケーション，プロトコル，その他の仕様は，それらが返すあるいは転送するコンテントのサブタグを削ったり修正したりすべきではない。 なぜならそれによって他のどこかで使用され得る情報を削ってしまうことになるからである。
The special language range "*" matches any language tag. In the lookup scheme, this range does not convey enough information by itself to determine which language tag is most appropriate, since it matches everything. If the language range "*" is followed by other language ranges, it is skipped. If the language range "*" is the only one in the language priority list or if no other language range follows, the default value is computed and returned.
特別な言語範囲 "*" は如何なる言語タグにもマッチする。 ルックアップスキームにおいて，この言語範囲はすべてにマッチするので，それ自体でどの言語タグが最も適切かを決めるための充分な情報を運ぶわけではない。 もし言語範囲 "*" が言語優先度リストの唯一の要素だったり，これの後に続く言語範囲がない場合は，デフォルト値が計算され返される。
In some cases, the language priority list can contain one or more extended language ranges (as, for example, when the same language priority list is used as input for both lookup and filtering operations). Wildcard values in an extended language range normally match any value that can occur in that position in a language tag. Since only one item can be returned for any given lookup request, wildcards in a language range have to be processed in a consistent manner or the same request will produce widely varying results. Applications, protocols, or specifications that accept extended language ranges MUST define which item is returned when more than one item matches the extended language range.
場合によっては，言語優先度リストは１つ以上の拡張言語範囲を含むことができる （例えば，ルックアップとフィルタリングの両方の入力として同じ言語優先度リストが用いられる場合など）。 拡張言語範囲の中のワイルドカード値は通常，言語タグ内のその位置に現れる如何なる値にもマッチする。 どんなルックアップリクエストに関しても返されるのはただ１つのアイテムなので，言語範囲の中のワイルドカードは一貫した仕方で処理されなければならず， そうでなければ同じリクエストであっても非常に多様な結果を生み出すことになるだろう。 拡張言語範囲を受け入れるアプリケーション，プロトコル，その他の仕様は，複数のアイテムがその拡張言語範囲にマッチする場合にどのアイテムが返されるかを定義しなければならない。
For example, an implementation could map the extended language ranges to basic ranges. Another possibility would be for an implementation to return the matching tag that is first in ASCII-order. If the language range were "*-CH" ('CH' represents Switzerland) and the set of tags included "de-CH" (German as used in Switzerland), "fr-CH" (French, Switzerland), and "it-CH" (Italian, Switzerland), then the tag "de-CH" would be returned.
例えば，ある実装は拡張言語範囲を基本言語範囲に対応づけるかもしれない。 他の可能性としては，マッチする言語タグのうちASCII順で先頭に来るものを返すということもあるだろう。 もし言語範囲が "*-CH" ('CH' はスイスを表す) であり言語タグの集合が "de-CH" (スイスで使用されているドイツ語), "fr-CH" (スイスで使用されているフランス語), "it-CH" (スイスで使用されているイタリア語) を含んでいるなら，その場合言語タグ "de-CH" が返されるだろう。
Each application, protocol, or specification that uses lookup MUST define the defaulting behavior when no tag matches the language priority list. What this action consists of strongly depends on how lookup is being applied. Some examples of defaulting behavior include:
ルックアップを用いるアプリケーション，プロトコル，その他の仕様の各々は，言語優先度リストに如何なる言語タグもマッチしないときのデフォルトの振る舞いを定義しなければならない。 このアクションが何で構成されるかは，どのようにルックアップが応用されるかに強く依存している。
When performing lookup using a language priority list, the progressive search MUST process each language range in the list before seeking or calculating the default.
言語優先度リストを用いてルックアップが実行されるとき，プログレッシブ検索はデフォルトを探したり計算したりする前にリスト中の言語範囲を処理しなければならない。
The default value MAY be calculated or include additional searching or matching. Applications, protocols, or specifications can specify different ways in which users can specify or override the defaults.
デフォルト値は計算されてもよいし，追加の検索や照合を含んでもよい。 アプリケーション，プロトコル，その他の仕様はユーザがデフォルトを指定したり上書きしたりできる様々な方法を規定することができる。
One common way to provide for a default is to allow a specific language range to be set as the default for a specific type of request. If this approach is chosen, this language range MUST be treated as if it were appended to the end of the language priority list as a whole, rather than after each item in the language priority list. The application, protocol, or specification MUST also define the defaulting behavior if that search fails to find a matching tag or item.
デフォルトを提供するためのよくある方法の１つは，特定のタイプのリクエストに関して，特定の言語範囲がデフォルトとしてセットされることを許すというものである。 このアプローチが選ばれるなら，この言語範囲はあたかも，言語優先度リストの個々のアイテムの後ではなく言語優先度リスト全体の末尾に追加されたかのように扱われなければならない。 アプリケーション，プロトコル，その他の仕様は，検索が１つのマッチする言語タグやアイテムを見つけるのに失敗した場合のデフォルトの振る舞いも定義しなければならない。
For example, if a particular user's language priority list is "fr-FR, zh-Hant" (French as used in France followed by Chinese as written in the Traditional script) and the program doing the matching had a default language range of "ja-JP" (Japanese as used in Japan), then the program searches as follows:
例えば，あるユーザの言語優先度リストが "fr-FR, zh-Hant" (フランスで使用されているフランス語，その次に，繁体字中国語) であり， 照合を実行するプログラムがデフォルトの言語範囲として "ja-JP" (日本で使用されている日本語) を持っていたら，そのプログラムは次のように検索する:
1. fr-FR 2. fr 3. zh-Hant // next language 4. zh 5. ja-JP // now searching for the default content 6. ja 7. (implementation defined default)
1. fr-FR 2. fr 3. zh-Hant // 次の言語 4. zh 5. ja-JP // ここでいまデフォルトコンテントを検索 6. ja 7. (実装が定義するデフォルト)
When working with language ranges and matching schemes, there are some additional points that can influence the choice of either.
言語範囲と照合スキームに関する仕事をするとき，どれかから一つ選ぶという場面に影響するさらなるポイントがいくつかある。
Users indicate their language preferences via the choice of a language range or the list of language ranges in a language priority list. The type of matching affects what the best choice is for a user.
ユーザは，言語範囲の選択や言語優先度リストにおける言語範囲のリストを通して彼らの言語選好を示す。 照合のタイプは，あるユーザにとっての最善の選択が何であるのかに影響を与える。
Most matching schemes make no attempt to process the semantic meaning of the subtags. The language range is compared, in a case- insensitive manner, to each language tag being matched, using basic string processing. Users SHOULD select language ranges that are well-formed, valid language tags according to [RFC4646] (substituting wildcards as appropriate in extended language ranges).
ほとんどの照合スキームはサブタグの意味を扱おうとしない。 言語範囲は，基本的な文字列処理を用いて，大文字小文字を区別しない仕方で，照合されようとしている各々の言語タグと比較される。 ユーザは，[RFC4646] に照らして妥当な整形式の言語タグであるような言語範囲を選択するべきである（ワイルドカードを拡張言語範囲における適切な形に置き換えて）。
Applications are encouraged to canonicalize language tags and ranges by using the Preferred-Value from the IANA Language Subtag Registry for tags or subtags that have been deprecated. If the user is working with content that might use the older form, the user might want to include both the new and old forms in a language priority list. For example, the tag "art-lojban" is deprecated. The subtag 'jbo' is supposed to be used instead, so the user might use it to form the language range. Or the user might include both in a language priority list: "jbo, art-lojban".
アプリケーションは，非推奨の言語タグやサブタグに関して IANA Language Subtag Registry から得た好ましい値を用いることで， 言語タグと言語範囲を正規化することが推奨される。 もしユーザが古い形式を用いたコンテントに関して仕事をしているなら，そのユーザは言語優先度リストに新しい形式と古い形式の両方を含めたいかもしれない。 例えば，言語タグ "art-lojban" は非推奨である。その代わりに，サブタグ 'jbo' は使用がサポートされている。 よって，そのユーザは言語範囲を作るのにこれを用いるかもしれない。あるいは，言語優先度リストにおいて両方を含めるかもしれない: "jbo, art-lojban"。
Users SHOULD avoid subtags that add no distinguishing value to a language range. When filtering, the fewer the number of subtags that appear in the language range, the more content the range will probably match, while in lookup unnecessary subtags can cause "better", more-specific content to be skipped in favor of less specific content. For example, the range "de-Latn-DE" returns content tagged "de" instead of content tagged "de-DE", even though the latter is probably a better match.
ユーザは，ある言語範囲にまったく特徴的な値を追加しないサブタグの使用を避けるべきである。 フィルタリングを行うとき，言語範囲に含まれるサブタグの数が少なければ少ないほど，その言語範囲がマッチするであろうコンテントが多くなる。 一方でルックアップにおいては，不必要なサブタグは，より限定的でないコンテントを返してしまって，"より良い"，より限定的なコンテントがスキップされるという結果を生じさせ得る。 例えば，言語範囲 "de-Latn-DE" は，言語タグ "de-DE" が付けられたコンテントではなく言語タグ "de" が付けられたコンテントを返す。後者のほうがおそらくより良くマッチしているにも関わらずである。
Whether a subtag adds distinguishing value can depend on the context of the request. For example, a user who reads both Simplified and Traditional Chinese, but who prefers Simplified, might use the range "zh" for filtering (matching all items that user can read) but "zh-Hans" for lookup (making sure that user gets the preferred form if it's available, but the fallback to "zh" will still work). On the other hand, content in this case ought to be labeled as "zh-Hans" (or "zh-Hant" if that applies) for filtering, while for lookup, if there is either "zh-Hans" content or "zh-Hant" content, one of them (the one considered 'default') also ought to be made available with the simple "zh". Note that the user can create a language priority list "zh-Hans, zh" that delivers the best possible results for both schemes. If the user cannot be sure which scheme is being used (or if more than one might be applied to a given request), the user SHOULD specify the most specific (largest number of subtags) range first and then supply shorter prefixes later in the list to ensure that filtering returns a complete set of tags.
サブタグが特徴的な値を追加するかどうかは，リクエストの文脈に依存する。 例えば，簡体字中国語と繁体字中国語の両方を読むが簡体字中国語のほうを好むユーザは，フィルタリングに関して言語範囲 "zh" を用いるかもしれない（このユーザが読めるすべてのアイテムにマッチする）。 しかし，ルックアップに関しては "zh-Hans" を用いるかもしれない（これによってそのユーザはもし利用可能であれば好ましいほうの形式を得るし，"zh" への後戻りも動作する）。 一方で，この場合のコンテントはフィルタリングに関して "zh-Hans" (あるいは "zh-Hant" のほうが適当であればこちら) とラベルされるべきであり， ルックアップに関しては，もし "zh-Hans" コンテントか "zh-Hant" コンテントがあるなら，それらのうちの１つ（デフォルトと見なされるほう）は単純に "zh" でも利用可能であるべきである。 そのユーザは，両方のスキームに関して最善の結果を得られるような言語優先度リスト "zh-Hans, zh" を作成することができる点に注意されたい。 もしユーザにとってどのスキームが用いられようとしているのかはっきりしない場合（あるいはあるリクエストに関して複数のスキームが適用される場合）， ユーザは最も限定的な（サブタグの数が最大の）言語範囲をリストの最初に，そしてより短い接頭辞をその後に入れて， フィルタリングが言語タグの完全な集合を返すことを保証するように指定すべきである。
Many languages are written predominantly in a single script. This is usually recorded in the Suppress-Script field in that language subtag's registry entry. For these languages, script subtags SHOULD NOT be used to form a language range. Thus, the language range "en-Latn" is inappropriate in most cases (because the vast majority of English documents are written in the Latin script and thus the 'en' language subtag has a Suppress-Script field for 'Latn' in the registry).
多くの言語では単一の用字でもって書かれるのが主流である。これは通常，その言語サブタグレジストリエントリにおいて Suppress-Script フィールドに記録されている。 これらの言語では，用字サブタグは言語範囲を作るのに用いられるべきではない。 従って，言語範囲 "en-Latn" はほとんどの場合において不適切である （なぜなら大多数の英語文書はラテン文字で書かれており，言語サブタグ 'en' はレジストリにて 'Latn' を Suppress-Script フィールドに持っているからである。）
When working with tags and ranges, note that extensions and most private-use subtags are orthogonal to language tag matching, in that they specify additional attributes of the text not related to the goals of most matching schemes. Users SHOULD avoid using these subtags in language ranges, since they interfere with the selection of available content. When used in language tags (as opposed to ranges), these subtags normally do not interfere with filtering (Section 3), since they appear at the end of the tag and will match all prefixes. Lookup (Section 3.4) implementations are advised to ignore unrecognized private-use and extension subtags when performing language tag fallback.
言語タグや言語範囲に関する仕事をするとき，拡張サブタグや私用サブタグは言語タグの照合とは直交する，つまり， これらはそのテキストの追加属性をほとんどの照合スキームの目的とは関係なく指定する。 利用可能なコンテントの選択を邪魔してしまうので，ユーザは言語範囲の中にこれらのサブタグを用いるのを避けるべきである。 （言語範囲ではなく）言語タグにて用いられるときは，これらのサブタグは通常，フィルタリング (Section 3) を邪魔しない。 なぜなら，それらは言語タグの末尾に現れ，すべての接頭辞にマッチするだろうからである。 ルックアップ (Section 3.4) の実装は，言語タグ後戻りを実行するとき，認識されない私用サブタグや拡張サブタグを無視するよう勧める。
Selecting language tags using language ranges requires some understanding by users of what they are selecting. The meanings of the various subtags in a language range are identical to their meanings in a language tag (see Section 4.2 in [RFC4646]), with the addition that the wildcard "*" represents any matching sequence of values.
言語範囲を用いた言語タグの選択は，選択しようとしているものについてユーザが幾分理解していることを要求する。 言語範囲の中の様々なサブタグの意味は言語タグの中のそれらの意味と同一であり（[RFC4646] の Section 4.2 を参照）， ワイルドカード "*" はマッチする如何なる値の並びをも表す，という点が付け加わっている。
Private agreement is necessary between the parties that intend to use or exchange language tags that contain private-use subtags. Great caution SHOULD be used in employing private-use subtags in content or protocols intended for general use. Private-use subtags are simply useless for information exchange without prior arrangement.
私用サブタグを含む言語タグを使用したり交換することを意図する関係者の間では私的な合意が必要である。 一般的利用を意図されたコンテントやプロトコルにおいて私用サブタグを用いることは厳重に注意されるべきである。 私用サブタグは，事前の合意なしの情報交換に関しては，単に役に立たない。
The value and semantic meaning of private-use tags and of the subtags used within such a language tag are not defined. Matching private- use tags using language ranges or extended language ranges can result in unpredictable content being returned.
そのような言語タグ内で用いられる私用タグや私用サブタグの値や意味は定義されない。 言語範囲や拡張言語範囲を用いて私用タグを照合することは予測できないコンテントが返されるという結果を招き得る。
Language ranges are very similar to language tags in terms of content and usage. The same types of restrictions on length that can be applied to language tags can also be applied to language ranges. See [RFC4646] Section 4.3 (Length Considerations).
言語範囲は内容や用法において言語タグと非常に類似している。 言語タグに適用される長さに関する制限は同じものが言語範囲にも適用され得る。 [RFC4646] Section 4.3 (Length Considerations) を参照のこと。
Language ranges used in content negotiation might be used to infer the nationality of the sender, and thus identify potential targets for surveillance. In addition, unique or highly unusual language ranges or combinations of language ranges might be used to track a specific individual's activities.
コンテントネゴシエーションにて用いられる言語範囲は送信者の国籍を推測し，監視の対象を同定するのに用いられるかもしれない。 加えて，珍しい，まったく普通でない言語範囲や言語範囲の組み合わせは，特定の個人の活動を追跡するのに用いられるかもしれない。
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 evaluation of the exact magnitude of the threat, and any possible countermeasures, is left to each application or protocol.
この脅威の正確な大きさの評価や可能な対策については，各アプリケーションやプロトコルに委ねられている。
Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN- MINUS (%x2D). Language ranges also use the character ASTERISK (%x2A). These characters are present in most character sets, so presentation or exchange of language tags or ranges should not be constrained by character set issues.
言語タグでは A-Z, a-z, 0-9, HYPHEN-MINUS (%x2D) の文字のみを用いることができる。 言語範囲では ASTERISK (%x2A) 文字も用いる。 これらの文字はほとんどの文字セットに存在するので，言語タグや言語範囲を提示したり交換したりすることは文字セット問題によって制約されないはずである。
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.
The contributors to [RFC1766] and [RFC3066], each of which was a precursor to this document, contributed greatly to the development of language tag matching, and, in particular, the basic language range and the basic matching scheme. This document was originally part of [RFC4646], but was split off before that document's completion. Thus, directly or indirectly, those acknowledged in [RFC4646] also had a hand in the development of this document, and work done prior to the split is acknowledged in that document.
The following people (in alphabetical order by family name) contributed to this document:
Harald Alvestrand, Stephane Bortzmeyer, Jeremy Carroll, Peter Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann, Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson, Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, and many, many others.
Very special thanks must go to Harald Tveit Alvestrand, who originated RFCs 1766 and 3066, and without whom this document would not have been possible.
Addison Phillips (Editor) Yahoo! Inc. EMail: addison@inter-locale.com Mark Davis (Editor) Google EMail: mark.davis@macchiato.com or mark.davis@google.com
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).