UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 開始 2010年11月12日 / translation 12 November 2010 翻訳 2010年11月20日 / translation 20 November 2010 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2482 を訳者( marimo@wdic.org )が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 Network Working Group K. Whistler Request for Comments: 2482 Sybase Category: Informational G. Adams Spyglass January 1999 Unicodeプレーンテクストでの言語タグ付け このメモの位置づけ このメモはインターネットコミュニティのための情報を提供する。それは、 いかなる種類のインターネット標準も指定しない。このメモの配布は無制限で ある。 著作権 Copyright (C) The Internet Society (1999). All Rights Reserved. IESG注意: この文書は、ISO/IEC 10646第二部、第14面に包含するための推薦としてWG2 から提出するために、会議#34のISO/IEC JTC1/SC2/WG2によって承認された。 1. 要約 この文書は、[UNICODE]プレーンテクストでの言語タグ付けの機構を提案し た。[ISO10646]の第14面上(UTF-8、UTF-16、およびUCS-4符号化法でアクセス できる)の特殊用途のタグの文字セットは、ISO10646(またはUNICODE)から通常 のテクスト内容の文字を厳密に分離することができる文字を使用したASCII ベースの文字列タグの表記が可能な符号化法が提案されている。 また一つのタグ識別文字と、一つのキャンセルタグ文字が提案されている。 特に、言語タグ識別文字は、明確に言語タグ文字列を特定するために提案され ている; 言語タグ自体は、第14面タグ文字を使用することで綴られた、 [RFC1766] 言語タグ文字列を利用する。プレーンテクストで言語タグを埋め込 むための、特定の、そして低いオーバーヘッドの機構の提供は、UTF-8文字列 の言語をマークするための標準的な機構を必要とするACAPのようなインター ネットプロトコルでの需要を満たすことを目的としている。 タグ付け機構としても、この文書で提案の文字はUnicode標準に含めるため のUnicodeコンソーシアムによって承認されている。ただし、この決定の実装 は、ISO JTC1/SC2/WG2、ISO10646に責任があるワーキンググループによる正式 な承認を待っている。潜在的な実装者は、正式に受諾されるまで、ここに提案 された文字のいずれの使用法も、厳密には実験的であり、標準化された文字 データ交換のために認可されていないことを認識する必要がある。 2. 定義と記法 試みは、この文書で使用されるすべての用語を定義していない。特に、符号 化文字システムを対象とする用語は明確に指定されない。この領域の追加定義 に関しては、[UNICODE]、[ISO10646]、および[RFC2130]を参照せよ。 2.1 要件記法 この文書では時々、大文字で表示される用語を使用する。 用語 "MUST"、"SHOULD"、"MUST NOT"、"SHOULD NOT"、および "MAY" が大文 字で表示され、それらは、この仕様の特定の要件を示すために用いられている。 これらの用語の意味についての議論は、[RFC2119] で示されている。 2.2 定義 以下で定義される用語は、特別な感覚で使用されており、結果として、何ら かの明確化が保証されている。 2.2.1 タグ付け プライマリーテクストの部分または範囲があるテクストの属性の関連付け (特定のタグの値は、一般的なテクストの "内容" の一部とは見なされない。 タグの典型的な例としては、言語やテクストの一部のフォントをマークするこ とである)。 2.2.2 注釈 部分または範囲のプライマリテクストの二次テクストコンテンツの関連付け (特に注釈の値はテクストの "内容" の一部と *みなされる*。典型的な例に、 引用、例証、日本語の読みなどがある)。 2.2.3 アウトオブバンド アウトオブバンドチャンネルは、テクストの内容が完全にそのまま、かつ変 更されていないことを確認するような方法で、エンコードされ、タグを伝える。 これは、メタデータまたはある種の超構造(hyperstructure)で一般的に行なわ れている。 2.2.4 インバンド インバンドチャンネルは、テクスト自体と同じ基本的な符号化機構を使用し て、テクストの内容と一緒にタグを伝える。これは様々な手段によって行なわ れており、有名な例はSGMLマークアップで、タグはテクストと同じ文字集合で 符号化されて点在し、テクストデータとともに運ばれる。 3.0 背景 言語のタグ付けと、他の種類のUnicodeプレーンテクストのタグ付けは、過 去8年間で多くの議論がなされている。Unicodeプレーンテクストの言語タグは、 特定のテクストのプロセスに必要であるという多少の普遍的な同意があると言 える。たとえば、複数の辞書に基づく多言語スペルチェックを適切に動かすた めには、多言語テクストの "ヒント" 言語が必要である。言語タグは、テクス トを音声に変換する処理を正常に動作させるための必要最小限の情報を提供す る。言語タグは、例文の代替コンテンツの選択を有効にするために、規則的に Webページ上で行なわれる。 しかしながら、言語タグの適切な位置付けに関して大きな論争があった。い くつかは、言語タグ(または他の種類のタグ)の唯一の適切な配置はアウトオブ バンドで、属性付きテクストの構造やメタデータを使用するということで成立 した。その他は、プレーンテキストの言語タグ(または他のタグ)はインバンド で複雑でないものが要件だと主張されている。 論争は、インバンドテクストマークアップ(HTML、text/enrichedなど)、い くつかの機構の存在と普及によって混乱した、とされている。これは、言語タ グを有効にする、しかしどのプロトコルの開発者や他のアプリケーションの数 があまりにも "ヘビー級" と判断される一般的な解析機構を使うことを意味す る。単純なプロトコルの一般的なインバンドテクストマークアップを使用して の難易度は、一部の文字がテクストコンテンツおよびテクストマークアップの 双方に使われているという事実から派生する; これで、原文の内容だけを見つ けるため、及びタグを無視するか逆もまた同様で、簡単で速いアルゴリズムを 書くのは、より難しくなる(すべてのマークアップタグを解釈するブラウザを 使用せずに、生のHTMLソーステクストのコンテンツを人間の読者が読み取ろう とする難易度のアルゴリズムと同等として考えられる)。 第14面の提案は、Unicodeの典型的なテキストマークアップの機構よりも軽 量にタグ付けできる周期的で永続的な呼び出し手法である。提案の特別な文字 のセットは、タグ付け*のみ*に使用される。これらのタグの文字は、プレーン テクストに埋め込むことができ、識別することができ、そして/または、単純 なアルゴリズムを無視でき、これらのタグ文字を使わないオーバーロードがあ るので -- それらはタグの値を表現することができ、そして決してテクストの 内容自体にはならない。 第14面の提案はテクストの引用、音声朗読(例: 日本語の読み)など、テクス トの一般的な注釈のためのものではない。現在の形式は、その使用はインライ ン言語タグを指定するだけに制限されることを意図している。将来の拡張で、 用法の範囲が広がる可能性がある。 4.0 提案 この提案では、94の印刷可能な7ビットASCIIグラフィック文字と、ASCIIス ペースのクローンで構成されるISO/IEC 10646の第14面の最初に符号化された 97の専用のタグの文字を使用するだけでなく、タグの識別文字と、タグのキャ ンセル文字も提案している。 これらのタグ文字は、Unicodeプレーンテクスト内に埋め込む需要の全ASCII ベースのタグ付け方式を綴るのに使用される。特に、IABキャラクタワーク ショップ(RFC 2130)のガイドラインに従って、ACAPプロトコルの表現された必 要条件と他の新しいプロトコルのありそうな要件を満たすために、言語タグを 綴るために使用することができる。 タグ文字のための予約ブロックの第14面推奨範囲と、ISO/IEC 10646の3つの 最も一般的に使用される符号化スキームのそれぞれの表現は、次のとおりであ る: UCS-4 U-000E0000 .. U-000E007F UTF-16 U+DB40 U+DC00 .. U+DB40 U+DC7F UTF-8 0xF3 0xA0 0x80 0x80 .. 0xF3 0xA0 0x81 0xBF この範囲、U-000E0020 .. U-000E007Eは、ASCIIのクローンタグ文字自体の 推奨範囲である。 4.1 タグ文字の名前 ASCIIクローンタグ文字の名前は、単語 "TAG" を冠した、7ビットASCIIのた めの厳密なISO 10646名となる。 また、一つのタグ識別文字とCANCELタグ文字がある。これらの文字の用法と 構文は、以下に詳細に記載されている。 提案された第14面タグの文字と、それらの文字の名前の全体の符号化は、以 下のリストから派生することができる(こことこの提案の中でコード化された 値はUCS-4フォームで記述されており、それは最も解釈しやすい。しかしなが ら、殆どのUnicodeアプリケーションは実際の実装において、UTF-16かUTF-8符 号化を使用すると思われる)。 U-000E0000 U-000E0001 言語タグ(LANGUAGE TAG) U-000E0002 U-000E001F U-000E0020 TAG SPACE U-000E0021 TAG EXCLAMATION MARK U-000E0041 TAG LATIN CAPITAL LETTER A U-000E007A TAG LATIN SMALL LETTER Z U-000E007E TAG TILDE U-000E007F キャンセルタグ(CANCEL TAG) 4.2 タグ文字の範囲チェック タグ文字コードのテストに必要な範囲チェックは、次のようになる。同じ範 囲のチェックが10646のための3つの重要な符号化形式ごとにCでここに表現さ れる。 UCS-4表現の範囲チェック: if ( ( *s >= 0xE0000 ) || ( *s <= 0xE007F ) ) UTF-16 (Unicod表現の範囲チェック: if ( ( *s == 0xDB40 ) && ( *(s+1) >= 0xDC00 ) && ( *(s+1) <= 0xDC7F ) ) UTF-8表現の範囲チェック: if ( ( *s == 0xF3 ) && ( *(s+1) == 0xA0 ) && ( *(s+2) & 0xE0 == 0x80 ) タグ文字のための範囲の選択のために、UCS-4かUTF-16のためにビットマス ク操作で範囲検査を表現することも可能だろう。 4.3 タグを埋め込むための構文 第14面タグ文字の利用は非常に簡単である。Unicodeプレーンテクストに任 意のASCII-派生タグを埋め込むためには、単にタグ文字で代わりに綴り、適切 なタグ識別文字で始める。結果の文字列はテクストに直接埋め込まれている。 タグの識別文字は、さまざまな種類のタグを識別するための機構として用い られている。これは、複数のタイプのタグを円満にプレーンテキストに埋め込 ことを可能にし、タグが別のタグに直接連結されている場合の区切りの問題を 解決する。定義されているタグは現在1種類、すなわち言語タグのみだが、将 来的にまったく別のタグの種類を使うことで、他のタグの識別文字の符号化が 可能になる。 終了文字は、タグに必須ではない。タグは、最初の第14面タグ文字以外(す なわち、他の通常のUnicodeの値)が検出されたとき、または次のタグの識別文 字が検出されると終了する。 すべてのタグの引数は、タグ文字U-000E0020 .. U-000E007Eのみを符号化す る必要がある。タグの引数を表現するためには、その他の文字は無効である。 タグの詳細なBNF構文は以下の通りである。 4.4 タグのスコープとネスト 確立したタグの値は、タグの位置から、テクストに埋め込まれている次のい ずれかまで継続する: A. テクスト自体は、アプリケーションで定義されるように、スコープか ら続く。(例えば、行指向のプロトコルで行末または文字列端に到達 すると; テクストストリームでストリーム末端に到達すると; など) または B. タグは、キャンセルタグ文字で明示的に取り消される。 同じ種類のタグは、いかなる方法でも入れ子にすることはできない。新たな 組み込み言語タグの出現、例えば既に言語タグ付けされていたテクストの後に 単に新しいタグで指定されると、後続のテクストのタグ値を変更する。 異なったタイプのタグは互いに絡み合うスコープを持つことができる。しか し、階層的なスコープではない。実際には、異なる種類のタグは完全に、お互 いを無視する。言語タグ(または他の任意のタグ種)の利用は、同じテキストの ソースタグを文字セットを使用しても将来的にも完全な非同期にすることがで きる。 4.5 キャンセルタグの値 U-000E007F CANCEL TAGはタグ値の特定のキャンセルが可能なように提供さ れている。CANCEL TAGの利用法には、以下の構文がある。特定の種類のタグ値 をキャンセルするには、適切な型のタグ識別文字にCANCEL TAG文字を付加する。 例えば、言語タグをキャンセルするための完全な文字列は: U-000E0001 U-000E007F そのタグ種類のデフォルト状態に関連するタグ型の値を返す。すなわち: タ グ値が指定されていない、タグ付けされていないテクストと同様である。 プレフィックスのタグ識別文字がないCANCEL TAGを使用すると、定義される *どんな* 第14面タグ値でも取り消される。現時点では、自明なタグ識別文字 は言語タグだけが提供されるため、言語タグだけが現在、影響を受ける。 CANCEL TAGの主な機能は、タグ付けをされた文脈において、文字列の無効な 連結として文字列境界をまたがって不適当なタグ値が伝播しないように操作す ることである。例えば未知の言語値の別の文字列がそれに連結される前に、日 本語タグでタグ付けをされた文字列は、終了のCANCEL TAGとタグ値の「封印」 を持つことができる。これは、日本語の文字列に連結する際に、未知の言語の 文字列が誤って日本語としてマークされることを防止する。 4.6 タグ構文の説明 この提案で規定されたタグの拡張BNF(バッカス記法)の説明は下記の通りで ある。以下のBNF拡張がこの形式を用いていることに注意せよ: 1. 意味的な制約は、二重括弧の間に指定されたアサーション形式の規則で 指定される; 変数$$は、この非終端が一致する全ての終端記号で構成さ れる文字列を表わす。 例: {{ Assert ( $$[0] == '?' ); }} 意味: この非終端によってマッチした文字列の先頭文字は '?' でなけ ればならない 2. 述語関数の数は、例外が定義されていない意味的な制約ルールで採用さ れている; それらの名前は、それらの述語的叙述を決定するには十分で ある。 例: IsRFC1766LanguageIdentifier ( tag-argument ) 意味: tag-argumentは、有効なRFC1766言語識別子である 3. 語彙拡張機能は、タグ、ASCII文字形式のタグを表わすために使用され る; この機能の引数は、範囲か列挙式によって指定された文字か文字集 合のいずれかである。 例: TAG('-') 意味: TAG HYPHEN-MINUS 例: TAG([A-Z]) 意味: TAG LATIN CAPITAL LETTER A ... TAG LATIN CAPITAL LETTER Z 4. マクロは、ASCIIで直接表わすことができない文字リテラルである終端記 号を指示する際に用いられる。マクロの引数はUNICODE(ISO/IEC 10646) 文字の名前である。 例: '${TAG CANCEL}' 意味: 文字リテラルのコード値は、U-000E007F である 5. 使用される発生インジケーターは、'+'(1以上)と'*'(ゼロか以上)であ る; 任意の発生は '[' と ']' の包囲によって示される。 4.6.1 正式なタグの構文 tag : language-tag | cancel-all-tag ; language-tag : language-tag-introducer language-tag-argument ; language-tag-argument : tag-argument {{ Assert ( IsRFC1766LanguageIdentifier ( $$ ); }} | tag-cancel ; cancel-all-tag : tag-cancel ; tag-argument : tag-character+ ; tag-character : { c : c in TAG( { a : a in printable ASCII characters or SPACE } ) } ; language-tag-introducer : '${TAG LANGUAGE}' ; tag-cancel : '${TAG CANCEL}' ; 5.0 タグの種類 5.1 言語タグ 言語タグは、一般的な関心があり、プロトコルを用いるために高い水準の相 互運用性を持っている必要がある。この目的のたに、LANGUAGE TAGタグの特定 の識別文字が用意されている。U-000E0001 LANGUAGE TAGのプレフィックス、 第14面のタグ文字列は、言語タグを構成するために規定されている。また、言 語タグのタグ値はRFC 1766で指定され登録されたタグの値のみ、または "x-" で始まるユーザー定義の言語タグ文字を利用して綴られる。 例えば、日本語の言語タグを埋め込むには、第14面文字は、次のように使用 される。日本語のタグはRFC 1766から、"ja" (ISO 639の言語ID) または、代 わりに "ja-JP" (ISO 639の言語IDに加え、ISO 3166の国ID)である。RFC 1766 の仕様による言語タグは大文字と小文字を区別しないため、第14面タグ文字に 変換する前に全体を小文字にすることを推奨する(これはUnicode適合に必要で はない。しかし、テクストに埋め込まれた言語タグの特定や無視する処理の、 簡素化やスピードアップのため、RFC 1766の言語タグを利用するプロトコルで 一般的な習慣としてに従う必要がある)。小文字で言語タグ値を表現すること が一般的な慣習となっているため、大文字よりむしろ小文字で表記することが 推薦される。 従って、全体の言語タグ(の長い形式)は、以下の第14面タグ文字に変換され るだろう: U-000E0001 U-000E006A U-000E0061 U-000E002D U-000E006A U-000E0070 次のように言語タグ(の、短い "ja" 形式)を表現できる: U-000E0001 U-000E006A U-000E0061 この文字列の値は、いずれかの符号化形式(UCS-4、UTF-16、UTF-8)が必要で あり、関連する時点で、テクストに埋め込まれて表わされる。 5.2 その他のタグ その他のタグの識別文字が、将来的に定義される可能性がある。例えば、 CHARACTER SET SOURCE TAG、あるいはタグのプライベート定義用GENERIC TAG、 のようになる。 特定のタグ識別文字が符号化されるときには都度、識別子に関連付けられた タグの値に対応する参照標準を指定する必要があるので、当事者の相互運用で のタグの使用は、タグが取るかもしれない値を解釈する方法を知るだろう。 6.0 表示の問題 タグ文字ブロック内の全ての文字は、通常のテクストにおいて、表示のレン ダリングを持っていると考えられる。タグを解釈するプロセスは、タグ値に基 づいてテクストのレンダリングを変更することができる(例えば、支那語と日 本語でレンダリングに適したスタイルにフォントを変更する)。タグ文字自体 は表示が全くない; それらはその点で、U+200B ZERO WIDTH SPACEと同様と考 えられるだろう。タグの文字は、タグを解釈するプロセスがタグ値に基づいて このような動作を課すことを選択する場合を除いて、改行や連結、その他の形 式またはレイアウトのプロパティには影響しない。 デバッグまたはその他の操作のために、タグ自体を表示するレンダリングを する必要がある。そのタグ文字は、対応するASCII文字のグリフ(おそらく通常 のASCII文字と区別するために体系的に変更されている)を使用してレンダリン グすることを推奨する。しかし、以下に述べられるように、タグ文字値は表示 対応なしで同等になるように選ばれており、タグ文字は殆どのデバッガーで解 明できるだろう。 7.0 Unicodeの適合性の問題 タグ文字のUnicodeに準拠するための基本的ルールは、正確に他のUnicode文 字と同じである。準拠プロセスが、タグの文字を解釈する必要はない。もしタ グの文字を解釈しない場合、それらの値はいかなる他の未解釈文字とともに乱 してはならない。もし解釈するのであれば、すなわち、綴られたタグとしての 規格に従って、それらが解釈されなければならない。 そして非TagAwareのUnicodeアプリケーションでは、遭遇するあらゆる言語 タグ文字(または第14面タグ文字で表現される他の種類のタグ)も、まるで解釈 されていないBMPのチベット語、解釈されていない第1面のLinear B、または 第15面の私用スペースからの解釈されていないエジプトの象形文字のように扱 われるだろう。 TagAwareにもかかわらず、TagPhobic Unicodeアプリケーションは、第14面 のタグ文字の範囲を認め、タグの無いプレーンテクストを作るために意図的に それらを除去ことを選択できる。 正しく形成されたタグの存在が、タグ付きデータが正しくタグ付けされてい ることを保証するとは解釈できない。例えば、フランス語のデータをスペイン 語と、あるいはギリシャ文字やキリル文字含むときに日本語のJIS-派生である と誤ってラベルすることを防げない。 7.1 言語タグのエンコーディングに関する注意 Unicodeでタグ文字を符号化するためのこの提案が、言語タグ値を指定する ための機構を含んでいるという事実は、Unicodeが基本的な符号化原則の一つ から出発していることを意味しない: Unicodeは、言語ではなく、スクリプトを符号化する これは、Unicode符号化(およびISO/IEC 10646)でも、プレーンテクストで言 語タグを指定するための機構が存在する場合でさえ、当てはまる。第14面のタ グの使用に関する義務は、言語タグかタグのいかなる他の種類にかかわらず、 存在しない。 言語タグ付けは、現在の符号化された文字や将来のスクリプトの符号化に、 決して影響を与えない。 既にアウトオブバンドの機構を利用している言語タグ付け、またはHTMLのよ うな「重量級の」インバンド機構では、第14面タグ文字は完全に無視され、さ れ続けることが、Unicodeの実装で完全に予想されている。 8.0 セキュリティについての考察 この文書によって提起されたセキュリティ上の問題は知られていない。 参考文献 [ISO10646] ISO/IEC 10646-1:1993 International Organization for Standardization. "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", Geneva, 1993. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2070] Yergeau, F., Nicol, G. Adams, G. and M. Duerst, "Internationalization of the Hypertext Markup Language", RFC 2070, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2130] Weider, C. Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997. [UNICODE] The Unicode Standard, Version 2.0, The Unicode Consortium, Addison-Wesley, July 1996. 謝辞 以下の人々は、直接または間接的に、この文書に貢献した: Chris Newman、 Mark Crispin、Rick McGowan、Joe Becker、John Jenkins、そしてAsmus Freytag。このドキュメントもUnicode技術委員会によって再検討された。そし て著者は彼らの援助についてUTC代表に皆、感謝したがっている。著者は、も ちろん、テクストに残るかもしれない全ての間違いまたは不作為に対応する責 任がある。 著者のアドレス Ken Whistler Sybase, Inc. 6475 Christie Ave. Emeryville, CA 94608-1050 Phone: +1 510 922 3611 EMail: kenw@sybase.com Glenn Adams Spyglass, Inc. One Cambridge Center Cambridge, MA 02142 Phone: +1 617 679 4652 EMail: glenn@spyglass.com 著作権全文 Copyright (C) The Internet Society (1999). All Rights Reserved. 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. 訳: この文書およびその翻訳は、コピーされ、他に供給され、そして派生語を 論評、違った形で説明、またはその実装の促進が準備され、コピーされ、 出版されて、もし上記の版権情報およびこのパラグラフが、すべてのその ようなコピーおよび派生した作品に含まれるなら、どのような種類の制限 なしで全体や部分を配布できる。しかし、この文書自身は、発展途上のイ ンターネット標準やインターネット標準プロセスにおいて定義された著作 権のための手続のために必要な場合や、英語以外の言語への翻訳の要求が ある場合を除いて、インターネットソサエティまたは他のインターネット 組織の版権情報や参照を削除するなど、いかなる点でも修正できない。 上記で与えられる制限された権限は永久で、インターネットソサエティま たはその後継者、委託人によって撤回されることはない。 ここに含まれるこの文書及び情報は、ありのまま "AS IS" インターネット ソサエティに関して提供され、そして、インターネット特別技術調査委員会 (IETF)タスクフォースは、保証、説明または暗示、どのような保証にも制限 されない一切の権利を侵害しない情報を利用すること、何らかの市販性の保 証の暗示、または、特定の目的のための適切性の全てを否定する。