Tags for the Identification of Languages 言語同定用tag
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags.
この文書は、情報物体で使われている言語を示すことが望ましい場面で使用する言語tag, この言語tagで使う値の登録方法, 及び言語tagの一致の構成を説明します。
訳注: 一致の構成って何だよ? とか思うけど適切な訳語が思いつかない。
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 information.
この地球の人間は、過去及び現在において、幾多の言語を使用してきました。 情報を表現するときに使われている言語を同定したい理由は沢山あります。
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.
幾つかの場面において、複数の言語で情報が利用可能であるかもしれませんし。言語の理解の補助のための道具 (例えば辞書) を提供することが出来るかもしれません。
Also, many types of information processing require knowledge of the language in which information is expressed in order for that process to be performed on the information; for example spell-checking, computer-synthesized speech, Braille, or high-quality print renderings.
また、多くの情報処理の型において、情報に施される処理のためにどの言語で情報が表現されているのかの知識が必要になります。 例えば、綴り検査, 計算機合成発話, 点字, 又は高品質印刷renderingが挙げられます。
One means of indicating the language used is by labeling the information content with an identifier for the language that is used in this information content.
使用されている言語を同定する一つの方法は、当該情報内容に使用されている言語の識別子で情報内容を札付けするというものです。
This document specifies an identifier mechanism, a registration function for values to be used with that identifier mechanism, and a construct for matching against those values.
この文書は識別子の仕組み, 識別子の仕組みで使用される値の登録機能, 及びこの値の一致の構築について規定します。
JA:RFCKeywordsAre...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].
The language tag is composed of one or more parts: A primary language subtag and a (possibly empty) series of subsequent subtags.
言語tagは1つ以上の部分で構成します。第1言語subtag及びそれに続く (空かもしれない) subtag群です。
The syntax of this tag in ABNF [RFC 2234] is:
このtagの構文を ABNF で表すとこうなります。
The productions ALPHA and DIGIT are imported from RFC 2234; they denote respectively the characters A to Z in upper or lower case and the digits from 0 to 9. The character "-" is HYPHEN-MINUS (ABNF: %x2D).
構成要素 ALPHA
及び DIGIT
は RFC2234 にあります。それぞれ文字 A
〜Z
の大文字・小文字及び数字 0
〜9
を示します。
文字 "-"
は HYPHEN-MINUS
(ABNF: %x2D
) です。
All tags are to be treated as case insensitive; there exist conventions for capitalization of some of them, but these should not be taken to carry meaning. For instance, [ISO 3166] recommends that country codes are capitalized (MN Mongolia), while [ISO 639] recommends that language codes are written in lower case (mn Mongolian).
全てのtagは大文字・小文字を区別しないものとして扱います。
幾つかのものを大文字化する慣習がありますが、これはなんら意味を持つものでもありません。
例えば、 ISO3166 は国名符号を大文字化する (MN
モンゴル)
ことを推奨し、 ISO639 は言語符号を小文字で書く (mn
モンゴル語)
ことを推奨しています。
The namespace of language tags is administered by the Internet Assigned Numbers Authority (IANA) [RFC 2860] according to the rules in section 3 of this document.
言語tagの名前空間はこの文書の第3章の規則に従ってIANAFullNameが管理します。
The following rules apply to the primary subtag:
第1subtagには次の規則を適用します。
- All 2-letter subtags are interpreted according to assignments found in ISO standard 639, "Code for the representation of names of languages" [ISO 639], or assignments subsequently made by the ISO 639 part 1 maintenance agency or governing standardization bodies. (Note: A revision is underway, and is expected to be released as ISO 639-1:2000)
- All 3-letter subtags are interpreted according to assignments found in ISO 639 part 2, "Codes for the representation of names of languages -- Part 2: Alpha-3 code [ISO 639-2]", or assignments subsequently made by the ISO 639 part 2 maintenance agency or governing standardization bodies.
- The value "i" is reserved for IANA-defined registrations
- The value "x" is reserved for private use. Subtags of "x" shall not be registered by the IANA.
- Other values shall not be assigned except by revision of this standard.
"i"
は IANA が定義した登録用に予約する。"x"
は 私用に予約する。subtag "x"
は IANA で登録しない。The reason for reserving all other tags is to be open towards new revisions of ISO 639; the use of "i" and "x" is the minimum we can do here to be able to extend the mechanism to meet our immediate requirements.
他の全てのtagを保留する理由は、 ISO 639 の新しい版に追随するためです。
"i"
や "x"
の使用は、我々の迫った要求に見合うように仕組みを拡張することが出来るようにここで出来る最小限のことです。
The following rules apply to the second subtag:
次の規則を第2subtagに適用します。
- All 2-letter subtags are interpreted as ISO 3166 alpha-2 country codes from [ISO 3166], or subsequently assigned by the ISO 3166 maintenance agency or governing standardization bodies, denoting the area to which this language variant relates.
- Tags with second subtags of 3 to 8 letters may be registered with IANA, according to the rules in chapter 5 of this document.
- Tags with 1-letter second subtags may not be assigned except after revision of this standard.
There are no rules apart from the syntactic ones for the third and subsequent subtags.
第3及びそれ以降のsubtagには構文的規則以外の規則はありません。
Tags constructed wholly from the codes that are assigned interpretations by this chapter do not need to be registered with IANA before use.
この節でその解釈が割当てられた符号のみから構成されるtagは使用の前に IANA に登録する必要はありません。
subtagThe information in a subtag may for instance be:
中の情報は例えば次のようなものです。
- Country identification, such as en-US (this usage is described in ISO 639)
- Dialect or variant information, such as en-scouse
- Languages not listed in ISO 639 that are not variants of any listed language, which can be registered with the i-prefix, such as i-tsolyani
- Region identification, such as sgn-US-MA (Martha's Vineyard Sign Language, which is found in the state of Massachusetts, US)
en-US
(この用法は ISO 639 で説明されています)en-scouse
(英語の Liverpool (西 England の港町) 方言)i-tsolyani
のように i-
接頭辞を付けて登録できるsgn-US-MA
(合衆国マサチューセッツ州マーサズ葡萄園島の手話)訳注: Martha's Vineyard == (台湾名) 馬薩葡萄園島。 『みんなが手話で話した島』(佐野正信訳, 築地書館, urn:ISBN:4-8067-2220-0) という本に詳しいらしい。
This document leaves the decision on what tags are appropriate or not to the registration process described in section 3.
この文書はどのようなtagが第3節で説明する登録過程に適当か否かの決定には触れません。
ISO 639 defines a maintenance agency for additions to and changes in the list of languages in ISO 639. This agency is:
ISO 639 は ISO 639 の言語一覧への追加と変更の管理機関を定義しています。 管理機関は、
International Information Centre for Terminology (Infoterm) P.O. Box 130 専門用語国際情報センター A-1021 Wien Austria
Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72
です。 訳注: Infoterm の日本語名は見つかりませんでした。
ISO 639-2 defines a maintenance agency for additions to and changes in the list of languages in ISO 639-2. This agency is:
ISO 639-2 は ISO 639-2 の言語一覧への追加と変更の管理機関を定義しています。 管理機関は、
Library of Congress 合衆国議会図書館ネットワーク開発及び MARS 標準局 Network Development and MARC Standards Office Washington, D.C. 20540 USA
Phone: +1 202 707 6237 Fax: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639
です。
The maintenance agency for ISO 3166 (country codes) is:
ISO 3166 (国名符号) の維持機関は
ISO 3166 Maintenance Agency Secretariat ISO 3166 維持機関事務局 c/o DIN Deutsches Institut fuer Normung Burggrafenstrasse 6 Postfach 1107 D-10787 Berlin Germany
Phone: +49 30 26 01 320 Fax: +49 30 26 01 231 URL: http://www.din.de/gremien/nas/nabd/iso3166ma/
です。
ISO 3166 reserves the country codes AA, QM-QZ, XA-XZ and ZZ as user-assigned codes. These MUST NOT be used to form language tags.
ISO 3166 は国名符号 AA
, QM
〜QZ
, XA
〜XZ
及び ZZ
を利用者割当符号として予約しています。
これらは言語tagの形成に使用してはMUST。
訳注: ISO 639-2 は qaa
〜qtz
を私用言語符号として予約していますが、これも使用しないのが良いでしょう。
One may occasionally be faced with several possible tags for the same body of text.
時折、textの同一本体に対して複数のtagが考えられる場面があります。
Interoperability is best served if all users send the same tag, and use the same tag for the same language for all documents. If an application has requirements that make the rules here inapplicable, the application protocol specification MUST specify how the procedure varies from the one given here.
全ての利用者が同じtagを送信し、全ての文書で同じ言語に同じtagを使えば最も相互通信性ががります。 応用がその要件によりここでの規則を適用できない場合、応用protocolは手続きがここに示すものからどう変化するのかを規定しなければMUST。
The text below is based on the set of tags known to the tagging entity.
下記のtextはtag付けする実体に対して分かっているtagの集合を基にします。
1. Use the most precise tagging known to the sender that can be ascertained and is useful within the application context.
2. When a language has both an ISO 639-1 2-character code and an ISO 639-2 3-character code, you MUST use the tag derived from the ISO 639-1 2-character code.
3. When a language has no ISO 639-1 2-character code, and the ISO 639-2/T (Terminology) code and the ISO 639-2/B (Bibliographic) code differ, you MUST use the Terminology code. NOTE: At present, all languages for which there is a difference have 2-character codes, and the displeasure of developers about the existence of 2 code sets has been adequately communicated to ISO. So this situation will hopefully not arise.
4. When a language has both an IANA-registered tag (i-something) and a tag derived from an ISO registered code, you MUST use the ISO tag. NOTE: When such a situation is discovered, the IANA-registered tag SHOULD be deprecated as soon as possible.
5. You SHOULD NOT use the UND (Undetermined) code unless the protocol in use forces you to give a value for the language tag, even if the language is unknown. Omitting the tag is preferred.
6. You SHOULD NOT use the MUL (Multiple) tag if the protocol allows you to use multiple languages, as is the case for the Content-Language: header.
i-なんたら
)
と ISO 登録符号に由来するtagを持っている場合、 ISO tag
を使わなければMUST。注意: そのような状況が判明した場合、 IANA
登録tagは可能な限りすぐに非推奨するSHOULD。UND
(未決定) 符号は使用するプロトコルが言語tagの値を与えることを強制していない限り使用しSHOULD NOT。
tagを省略する方が好ましいです。MUL
(複数) tagは、 Content-Language:
headerのようにプロトコルが複数の言語の使用を認めている場合には使用しSHOULD NOT。NOTE: In order to avoid versioning difficulties in applications such as that of RFC 1766, the ISO 639 Registration Authority Joint Advisory Committee (RA-JAC) has agreed on the following policy statement:
注意: RFC 1766 の場合のように応用中での版決定が困難になるのを避けるため、 ISO 630 登録事務局合同諮問委員会 (RA-JAC) は次の方針声明に合意しました。
"After the publication of ISO/DIS 639-1 as an International Standard, no new 2-letter code shall be added to ISO 639-1 unless a 3-letter code is also added at the same time to ISO 639-2. In addition, no language with a 3-letter code available at the time of publication of ISO 639-1 which at that time had no 2-letter code shall be subsequently given a 2-letter code."
「ISO/DIS 639-1 が国際標準として発行された後、3文字符号が同時に ISO 639-2 に追加されない限り新しい2文字符号は ISO 639-1 には追加しない。 加えて、 ISO 639-1 の発行の時点で3文字言語符号を持つが2文字符号は持たない言語には今後2文字符号を与えない。」
This will ensure that, for example, a user who implements "hwi" (Hawaiian), which currently has no 2-letter code, will not find his or her data invalidated by eventual addition of a 2-letter code for that language."
これにより例えば、現在2文字符号を持たない "hwi"
(ハワイ語) を実装した利用者は、結果として起こるこの言語への2文字符号の追加によりそのデータが無効になることはありません。
訳注: 上記段落原文には末尾に <"> がついているが、字下げや内容を考えると RA-JAC 声明の一部ではなく RFC の一部ではないかと思われる。
The language tag always defines a language as spoken (or written, signed or otherwise signaled) by human beings for communication of information to other human beings. Computer languages such as programming languages are explicitly excluded. There is no guaranteed relationship between languages whose tags begin with the same series of subtags; specifically, they are NOT guaranteed to be mutually intelligible, although it will sometimes be the case that they are.
言語tagは常に、人間により他の人間への情報の伝達のために話される (又は書かれる, 示される, その他信号される) 言語を定義します。 プログラム言語のような計算機言語は明白に除外します。 同じsubtag群で始まるtagの言語間の関係についての保障はありません。 具体的には、相互に理解可能であるという保障は、可能であるという場合もあるでしょうが、保障しません。
tagThe relationship between the tag and the information it relates to is defined by the standard describing the context in which it appears. Accordingly, this section can only give possible examples of its usage.
及びその関連する情報の関係は、その出現する文脈を説明した規格の定義によります。 従って、この節はその可能な用法の例のみを示します。
- For a single information object, it could be taken as the set of languages that is required for a complete comprehension of the complete object. Example: Plain text documents.
- For an aggregation of information objects, it should be taken as the set of languages used inside components of that aggregation. Examples: Document stores and libraries.
- For information objects whose purpose is to provide alternatives, the set of tags associated with it should be regarded as a hint that the content is provided in several languages, and that one has to inspect each of the alternatives in order to find its language or languages. In this case, a tag with multiple languages does not mean that one needs to be multi-lingual to get complete understanding of the document. Example: MIME multipart/alternative.
- In markup languages, such as HTML and XML, language information can be added to each part of the document identified by the markup structure (including the whole document itself). For example, one could write <span lang="FR">C'est la vie.</span> inside a Norwegian document; the Norwegian-speaking user could then access a French-Norwegian dictionary to find out what the marked section meant. If the user were listening to that document through a speech synthesis interface, this formation could be used to signal the synthesizer to appropriately apply French text-to-speech pronunciation rules to that span of text, instead of misapplying the Norwegian rules.
multipart/alternative
<span lang="FR">C'est la vie.</span>
と書くことが出来ます。
諾威語話者はマークされた節の意味を理解するために仏諾辞典を引くことが出来ます。
利用者が文書を発話合成界面を通じて聞いているなら、textの当該部分を仏蘭西語の会話発音規則を
(誤って諾威語の規則を適用せずに正しく)
適用するよう合成器に知らせるのに使えます。Since the publication of RFC 1766, it has become apparent that there is a need to define a term for a set of languages whose tags all begin with the same sequence of subtags.
RFC 1766 の発行以後、同じsubtag群で始まるtagの言語の集合を表す語彙を定義する必要があることが明らかになってきました。
The following definition of language-range is derived from HTTP/1.1 [RFC 2616].
次の language-range
の定義は HTTP/1.1 に由来します。
That is, a language-range has the same syntax as a language-tag, or is the single character "*".
つまり、 language-range
は language-tag
と同じ構文を持つか、単一文字 "*"
です。
A language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is "-".
language-range
はtagと完全に等しいか、tagの接頭辞が完全に等しくて、接頭辞の次の文字が
"-"
である場合に language-tag
に一致します。
The special range "*" matches any tag. A protocol which uses language ranges may specify additional rules about the semantics of "*"; for instance, HTTP/1.1 specifies that the range "*" matches only languages not matched by any other range within an "Accept-Language:" header.
特殊範囲 "*"
はどのtagにも一致します。
言語範囲を使用するprotocolは "*"
の意味についての追加の規則を規定しても構いません。例えば、 HTTP/1.1
は Accept-Language:
header中のどの他の範囲にも一致しない言語に一致します。
NOTE: This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
注意: 接頭辞一致規則のこの用法は、ある利用者があるtagの言語を理解するならば、この利用者はこのtagが接頭辞であるtagの全ての言語をも理解するという条件が常に真であるように言語tagが割当てられることを必要とするものではありません。
The procedure given here MUST be used by anyone who wants to use a language tag not given an interpretation in chapter 2.2 of this document or previously registered with IANA.
ここに示す手続きはこの文書の2.2節の解釈又は以前の IANA の登録にない言語tagを使用することを望む人は誰でも使うことが出来なければMUST。
This procedure MAY also be used to register information with the IANA about a tag defined by this document, for instance if one wishes to make publicly available a reference to the definition for a language such as sgn-US (American Sign Language).
手続きはこの文書で定義されるtagについて、
例えば sgn-US
(アメリカ手話)
のような言語の定義の参照先を広く利用可能にしたい場合に
IANA に情報を登録するのに使ってもMAY。
Tags with a first subtag of "x" need not, and cannot, be registered.
最初のsubtagが "x"
であるtagは登録する必要はありませんし、登録出来ません。
The process starts by filling out the registration form reproduced below.
過程は下記を複製した登録用紙を埋めることで始まります。
LANGUAGE TAG REGISTRATION FORM 言語tag登録用紙 Name of requester : 要求者名 E-mail address of requester: 要求者の電子メイル・アドレス Tag to be registered : 登録するtag English name of language : 言語の英語名 Native name of language (transcribed into ASCII): 言語名 (ASCII に翻字) Reference to published description of the language (book or article): 言語についての出版された記述への参照 (書籍又は記事) Any other relevant information: その他関連情報
The language form must be sent to <ietf-languages@iana.org> for a 2-week review period before it can be submitted to IANA. (This is an open list. Requests to be added should be sent to <ietf-languages-request@iana.org>.)
言語用紙はこれが IANA に提出可能となる前に、 MAIL:ietf-languages@iana.org に送信して2週間の評価期間を経なければMUST。 (これは公開リストです。追加の要求は MAIL:ietf-languages-request@iana.org に送って下さい。)
訳注: ML に参加するには後者のメイル・アドレスに送るべし、ということです。 http://www.alvestrand.no/mailman/listinfo/ietf-languages 参照。
When the two week period has passed, the language tag reviewer, who is appointed by the IETF Applications Area Director, either forwards the request to IANA@IANA.ORG, or rejects it because of significant objections raised on the list. Note that the reviewer can raise objections on the list himself, if he so desires. The important thing is that the objection must be made publicly.
2週間の期間が経過したら、 IETF 応用IETFArea理事により任命された言語tagreviewerは要求を MAIL:IANA@IANA.ORG に転送するか又はリストでの重大な異議により却下するかします。 なお、評価者自身がリストで異議を提出したければそうできます。 重要なことは、異議が公的に行われなければならないことです。
The applicant is free to modify a rejected application with additional information and submit it again; this restarts the 2-week comment period.
志願者が却下された申し立てを修正して追加情報を加えて、再び提出するのは自由です。 この場合2週間のコメント期間が再び開始されます。
reviewerDecisions made by the reviewer may be appealed to the IESG [RFC 2028] under the same rules as other IETF decisions [RFC 2026]. All registered forms are available online in the directory http://www.iana.org/numbers.html under "languages".
の決定は他の IETF 判断と同様の規則の元で IESG に訴えられるかもしれません。全ての登録用紙はディレクトリ http://www.iana.org/numbers.html の「language」のところから online で入手出来ます。
訳注: http://www.iana.org/numbers.html#L
Updates of registrations follow the same procedure as registrations. The language tag reviewer decides whether to allow a new registrant to update a registration made by someone else; in the normal case, objections by the original registrant would carry extra weight in such a decision.
登録内容の更新は登録と同じ手続きに従います。 言語tagreviewerは新しい登録者が他の誰かによる登録を更新するのを認めるかどうか決定します。 通常の場合、元の登録者の異議はその決定により重みを持ちます。
There is no deletion of registrations; when some registered tag should not be used any more, for instance because a corresponding ISO 639 code has been registered, the registration should be amended by adding a remark like "DEPRECATED: use <new code> instead" to the "other relevant information" section.
登録の削除はありません。登録されたtagがそれ以上使用するべきではなくなった時、例えば対応する ISO 639 符号が登録された時には、登録は「その他の関連情報」の節に「非推奨: <新しい符号>を代わりに使うべし」と注記を加えるよう改訂するのが良いです。
Note: The purpose of the "published description" is intended as an aid to people trying to verify whether a language is registered, or what language a particular tag refers to. In most cases, reference to an authoritative grammar or dictionary of the language will be useful; in cases where no such work exists, other well known works describing that language or in that language may be appropriate. The language tag reviewer decides what constitutes a "good enough" reference material.
注意: 「出版された記述」の目的は、言語が登録されているかどうかやどの言語が特定のragにより参照されているのかを確認しようとする人を助けることを意図しています。 多くの場合、その言語の権威的な文法書又は辞書への参照が有用でしょう。 そうした成果物が存在しない場合、その言語を説明した又はその言語で書かれたよく知られた成果物が適切かもしれません。 言語tagreviewerが何を持って「十分良い」参考文献とするかを決定します。
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 の発行後に起こった言語tagに係る唯一の安全性の問題は、内容折衝で使われる言語範囲に関するものです。 これは送信者の民族の推測して監視の対象となり得る相手を同定するのに使われるかもしれません。
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 protocol.
実際の脅威の大きさと可能な対応策の評価は各応用protocolの仕事です。
Language tags may always be presented using the characters A-Z, a-z, 0-9 and HYPHEN-MINUS, which are present in most character sets, so presentation of language tags should not have any character set issues.
言語tagは常に文字 A
〜Z
, a
〜z
,
0
〜9
及び HYPHEN-MINUS
という殆どの文字集合に含まれるもので表現されますから、言語tagの表現は文字集合問題を持たないはずです。
The issue of deciding upon the rendering of a character set based on the language tag is not addressed in this memo; however, it is thought impossible to make such a decision correctly for all cases unless means of switching language in the middle of a text are defined (for example, a rendering engine that decides font based on Japanese or Chinese language may produce suboptimal output when a mixed Japanese-Chinese text is encountered)
言語tagに基づく文字集合のrenderingの決定についてはこのメモでは触れません。 しかし、text中での言語の切り替えの手段が定義されていない限り全ての場合に正しくそうした決定をを行うのは不可能と思われます (例えば、日本語か中文かによりfontを決定するrendering機関は日中混合文に遭遇した場合には次善出力しか生成出来ないかもしれません)。
This document has benefited from many rounds of review and comments in various fora of the IETF and the Internet working groups.
この文書は IETF 及び Internet 作業部会の種々の討論場における多段階に亘る評価と注釈によりここまで来ました。
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: アルファベット順で:
Glenn Adams, Tim Berners-Lee, Marc Blanchet, Nathaniel Borenstein, Eric Brunner, Sean M. Burke, John Clews, Jim Conklin, Peter Constable, John Cowan, Mark Crispin, Dave Crocker, Mark Davis, Martin Duerst, Michael Everson, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Paul Hoffman, Olle Jarnefors, Kent Karlsson, John Klensin, Alain LaBonte, Chris Newman, Keith Moore, Masataka Ohta 太田昌孝, Keld Jorn Simonsen, Otto Stolz, Rhys Weatherley, Misha Wolf, Francois Yergeau and many, many others. そして沢山の沢山の皆さん。
Special thanks must go to Michael Everson, who has served as language tag reviewer for almost the complete period since the publication of RFC 1766, and has provided a great deal of input to this revision.
RFC 1766 の発行以後殆ど全期間言語tagreviewerを務めてきて、この改訂にも大変協力していただいた Michael Everson には特に感謝します。
訳注: そんな Everson 君について知りたいあなたは http://www.egt.ie/ 及び http://www.evertype.com/ を参照。
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim NORWAY
Phone: +47 73 50 33 52 EMail: Harald@Alvestrand.no
訳注: Harald 君がどんなにカッコいいか知りたい君は http://www.opengroup.org/public/member/q102/alvestrand.htm を見よう!
[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-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 a Joint Working Group of ISO TC46/SC4 and ISO TC37/SC2.
[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.
[JIS X 0304] JIS X 0304:1999, 『国名コード』, JISC, 1999-11-20。 ISO 3166 に対応。 http://www.jisc.go.jp/ より入手可能。
[RFC 1327] Kille, S., "Mapping between X.400 (1988) / ISO 10021 and RFC 822", RFC 1327, May 1992.
[RFC 1521] Borenstein, N., and N. Freed, "MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993.
[RFC 2045] 『MIME 第1部: Internet メッセージ本体の書式』, RFC2045。 RFC 1521 を廃止。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC 2119] Bradner, S."Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC2234, November 1997.
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2616, June 1999.
[RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
The Library of Congress, maintainers of ISO 639-2, has made the list of languages registered available on the Internet.
ISO 639-2 の維持者である米国議会図書館は登録された言語の一覧を Internet で利用可能にしています。
At the time of this writing, it can be found at http://www.loc.gov/standards/iso639-2/langhome.html
執筆の時点ではこれは http://www.loc.gov/standards/iso639-2/langhome.html にあります。
The IANA registration forms for registered language codes can be found at http://www.iana.org/numbers.html under "languages".
登録された言語符号の IANA 登録用紙は http://www.iana.org/numbers.html の「language」の欄にあります。
The ISO 3166 Maintenance Agency has published Web pages at
ISO 3166 維持機関は Web 頁を出版しています。
http://www.din.de/gremien/nas/nabd/iso3166ma/
language-range] を追加
content-language
headerの定義を他の文書に分離Copyright (C) The Internet Society (2001). All Rights Reserved. RFCFullCopyright RFCAcknowledgement