RFC5198 日本語訳
5198 Unicode Format for Network Interchange. J. Klensin, M. Padlipsky. March 2008. (Format: TXT=45708 bytes) (Obsoletes RFC0698) (Updates RFC0854) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 5198 M. Padlipsky Obsoletes: 698 March 2008 Updates: 854 Category: Standards Track
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5198M.Padlipskyは以下を時代遅れにします。 698 2008年3月は以下をアップデートします。 854カテゴリ: 標準化過程
Unicode Format for Network Interchange
ネットワーク置き換えのためのユニコード形式
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences.
インターネットは今日国際化している「テキスト」情報の伝達のための標準形を必要としています、ASCIIの使用のためのアルパネットの初期をさかのぼる仕様に沿って。 正常化と特定の系列結末系列があるUTF-8を使用して、このドキュメントはその形式を指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement for a Standardized Text Stream Format . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Net-Unicode Definition . . . . . . . . . . . . . . . . . . . . 3
3. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Versions of Unicode . . . . . . . . . . . . . . . . . . . . . 5
5. Applicability and Stability of this Specification . . . . . . 7
5.1. Use in IETF Applications Specifications . . . . . . . . . 7
5.2. Unicode Versions and Applicability . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. History and Context . . . . . . . . . . . . . . . . . 11
Appendix B. The ASCII NVT Definition . . . . . . . . . . . . . . 12
Appendix C. The Line-Ending Problem . . . . . . . . . . . . . . . 14
Appendix D. A Note about Related Future Work . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 標準化されたテキストストリーム形式. . . . 2 1.2のための要件。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 2。 ネットのユニコード定義. . . . . . . . . . . . . . . . . . . . 3 3。 正常化. . . . . . . . . . . . . . . . . . . . . . . . 5 4。 ユニコード. . . . . . . . . . . . . . . . . . . . . 5 5のバージョン。 このSpecification. . . . . . 7 5.1の適用性とStability。 IETFアプリケーションで仕様. . . . . . . . . 7 5.2を使用してください。 ユニコードバージョンと適用性. . . . . . . . . . . . 7 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 10付録A.歴史と文脈. . . . . . . . . . . . . . . . . 11付録B.ASCII NVT、定義. . . . . . . . . . . . . . 12付録、C. 線結末問題……………; 14付録D.は関連今後の活動. . . . . . . . . . 14参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15引用規格. . . . . . . . . . . . . . . . . . . . . . 15の有益な参照. . . . . . . . . . . . . . . . . . . . . 16に関する注です。
Klensin & Padlipsky Standards Track [Page 1] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[1ページ]。
1. Introduction
1. 序論
1.1. Requirement for a Standardized Text Stream Format
1.1. 標準化されたテキストストリーム形式のための要件
Historically, Internet protocols have been largely ASCII-based and
references to "text" in protocols have assumed ASCII text and
specifically text in Network Virtual Terminal ("NVT") or "Network
ASCII" form (see Appendix A and Appendix B). Protocols and formats
that have moved beyond ASCII have included arrangements to
specifically identify the character set and often the language being
used.
歴史的に、インターネットプロトコルは主にASCIIベースでした、そして、プロトコルの「テキスト」の参照はNetwork Virtual Terminal("NVT")か「ネットワークASCII」におけるASCIIテキストと明確にテキストが形成される(付録Aと付録Bを見る)と仮定しました。 ASCIIで移行したプロトコルと形式は、明確に文字集合としばしば使用される言語を特定するためにアレンジメントを含んでいました。
In our more internationalized world, "text" clearly no longer equates unambiguously to "network ASCII". Fortunately, however, we are converging on Unicode [Unicode] [ISO10646] as a single international interchange character coding and no longer need to deal with per- script standards for character sets (e.g., one standard for each of Arabic, Cyrillic, Devanagari, etc., or even standards keyed to languages that are usually considered to share a script, such as French, German, or Swedish). Unfortunately, though, while it is certainly time to define a Unicode-based text type for use as a common text interchange format, "use Unicode" involves even more ambiguity than "use ASCII" did decades ago.
私たちのさらに国際化している世界では、「テキスト」が、「ASCIIをネットワークでつなぐ」ためにもう明確に明白に一致していません。 しかしながら、幸い、私たちが単一の国際的な置き換えキャラクタコード化ともう対処する必要性としてユニコード[ユニコード][ISO10646]に集まっている、-、文字集合(例えば、それぞれのアラビアの、そして、キリル文字のDevanagariなどの1つの規格、または通常、フランス語、ドイツ語、またはスウェーデン語などのスクリプトを共有すると考えられる言語に合わせられた規格さえ)のスクリプト規格。 残念ながら、確かに定義する時間ですが、もっとも、一般的なテキストが形式を交換して、「ユニコードを使用する」とき使用が「ASCIIを使用する」よりさらに多くのあいまいさにかかわるので、ユニコードベースのテキストタイプは何10年も前にしました。
Unicode identifies each character by an integer, called its "code point", in the range 0-0x10ffff. These integers can be encoded into byte sequences for transmission in at least three standard and generally-recognized encoding forms, all of which are completely defined in The Unicode Standard and the documents cited below:
「コード・ポイント」と呼ばれる整数に従って、ユニコードは0-0 範囲x10ffffで各キャラクタを特定します。 それのすべてがユニコードStandardと以下で引用されたドキュメントで完全に定義される少なくとも3つの標準の、そして、一般に認識されたコード化フォームにおけるトランスミッションのためにこれらの整数をバイト列にコード化できます:
o UTF-8 [RFC3629] defines a variable-length encoding that may be
applied uniformly to all code points.
o UTF-8[RFC3629]は一様にすべてのコード・ポイントに適用されるかもしれない可変長のコード化を定義します。
o UTF-16 [RFC2781] encodes the range of Unicode characters whose
code points are less than 65536 straightforwardly as 16-bit
integers, and provides a "surrogate" mechanism for encoding larger
code points in 32 bits.
o UTF-16[RFC2781]は16ビットの整数としてコード・ポイントがまっすぐ65536未満であるユニコード文字の範囲をコード化して、「代理」のメカニズムを32ビットの、より大きいコード・ポイントをコード化するのに提供します。
o UTF-32 (also known as UCS-4) simply encodes each code point as a
32-bit integer.
o UTF-32(また、UCS-4として、知られている)は32ビットの整数として単に各コード・ポイントをコード化します。
Older forms and nomenclature, such as the 16-bit UCS-2, are now strongly discouraged.
16ビットのUCS-2などの、より古いフォームと用語体系は現在、強くがっかりしています。
As with ASCII, any of these forms may be used with different line- ending conventions. That flexibility can be an additional source of confusion with, e.g., index (offset) references into documents based on character counts.
ASCIIなら、これらのフォームのいずれも異なった系列終わりのコンベンションと共に使用されるかもしれません。 その柔軟性が混乱の追加源であるかもしれない、例えば、ドキュメントへのインデックス(相殺する)参照はカウントをキャラクタに基礎づけました。
Klensin & Padlipsky Standards Track [Page 2] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[2ページ]。
This document proposes to establish "Net-Unicode" as a new standardized text transmission form for the Internet, to serve as an internationalized alternative for NVT ASCII when specified in new -- and, where appropriate, updated -- protocols. UTF-8 [RFC3629] is chosen for the coding because it has good compatibility properties with ASCII and for other reasons discussed in the existing IETF character set policy [RFC2277]. "Net-Unicode" is specified in Section 2; the subsequent sections of the document provide background and explanation.
新しくて適切であるところでアップデートされたプロトコルで指定されると、このドキュメントは、インターネットのための新しい標準化されたテキスト伝送フォームと「ネットのユニコード」を書き立てて、NVT ASCIIのための国際化している代替手段として機能するよう提案します。 それには良い互換性の特性がASCIIと既存のIETF文字集合方針[RFC2277]で議論した他の理由であるので、UTF-8[RFC3629]はコード化に選ばれています。 「ネットのユニコード」はセクション2で指定されます。 ドキュメントのその後のセクションはバックグラウンドと説明を提供します。
Whenever there is a choice, Unicode SHOULD be used with the text encoding specified here. This combination is preferred to the double-byte encoding of "extended ASCII" [RFC0698] or the assorted per-language or per-country character coding systems.
ユニコードSHOULD、選択があるときはいつも、ここで指定されるテキストコード化と共に使用されてください。 この組み合わせは「拡張ASCII」[RFC0698]か言語か国あたりのさまざまなキャラクタに記号化体系をコード化する二重バイトより好まれます。
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Net-Unicode Definition
2. ネットのユニコード定義
The Network Unicode format (Net-Unicode) is defined as follows. Parts of this definition are deliberately informal, providing guidance for specific profiles or rules in the protocols that reference this one rather than firm rules that apply globally.
Networkユニコード書式(ネットのユニコード)は以下の通り定義されます。 この定義の部分は故意に非公式です、グローバルに適用される厳しい規則よりむしろこれに参照をつけるプロトコルの特定のプロフィールか規則のための指導を提供して。
1. Characters MUST be encoded in UTF-8 as defined in [RFC3629].
1. [RFC3629]で定義されるUTF-8でキャラクターをコード化しなければなりません。
2. If the protocol has the concept of "lines", line-endings MUST be
indicated by the sequence Carriage-Return (CR, U+000D) followed
by Line-Feed (LF, U+000A), often known just as CRLF. CR SHOULD
NOT appear except when followed by LF. The only other allowed
context in which CR is permitted is in the combination CR NUL,
which is not recommended (see the note at the end of this
section).
2. プロトコルに「系列」の概念があるなら、ちょうどCRLFとしてしばしば知られているラインフィード(LF、U+000A)があとに続いた系列Carriage-リターン(CR、U+000D)で系列結末を示さなければなりません。 LFによって続かれているときに時を除いて、CR SHOULD NOTは現れます。 組み合わせCR NULにはCRが受入れられる他の唯一の許容文脈があります(このセクションの端で注意を見てください)。(CR NULは推薦されません)。
3. The control characters in the ASCII range (U+0000 to U+001F and
U+007F to U+009F) SHOULD generally be avoided. Space (SP,
U+0020), CR, LF, and Form Feed (FF, U+000C) are exceptions to
this principle, but use of all but the first requires care as
discussed elsewhere in this document. The so-called "C1
Controls" (U+0080 through U+009F), which did not appear in ASCII,
MUST NOT appear.
3. 制御文字はASCIIで及びます。(一般に、U+009F)SHOULDとしてU+001FとU+007F避けられるべきU+0000。 スペース(SP、U+0020)、CR、LF、およびForm Feed(FF、U+000C)はこの原則への例外ですが、1番目を除いたすべての使用はほかの場所で本書では議論するように注意を必要とします。 いわゆる「C1コントロール」(U+009Fを通したU+0080)は現れてはいけません。(それは、ASCIIに現れませんでした)。
FF should be used only with caution: it does not have a standard
and universal interpretation and, in particular, if its use
FFは慎重にだけ使用されるべきです: そして、それには標準的、そして、普遍的な解釈がない、特にその使用です。
Klensin & Padlipsky Standards Track [Page 3] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[3ページ]。
assumes a page length, such assumptions may not be appropriate in
international contexts (e.g., considering 8.5x11 inch paper
versus A4). Other control characters are used to affect display
format, control devices, or to structure files. None of those
uses is appropriate for streams of plain text.
ページ長であり、そのような仮定が国際的な関係(例えば、8.5×11インチが紙である対A4と考える)で適切でないかもしれないと仮定します。 他の制御文字は、システム出力表示形式、制御装置に影響するか、またはファイルを構造化するのに使用されます。 プレーンテキストのストリームには、それらの用途のいずれも適切ではありません。
4. Before transmission, all character sequences SHOULD be normalized
according to Unicode normalization form "NFC" (see Section 3).
4. トランスミッション、すべてのキャラクタがSHOULDを配列する前に、ユニコード正常化フォーム"NFC"に従って、正常にされてください(セクション3を見てください)。
5. As suggested in Section 6 of RFC 3629, the Byte Order Mark
("BOM") signature MUST NOT appear at the beginning of these text
strings.
5. RFC3629のセクション6に示されるように、Byte Orderマーク("BOM")の署名はこれらのテキスト文字列の始めに見えてはいけません。
6. Systems conforming to this specification MUST NOT transmit any
string containing any code point that is unassigned in the
version of Unicode on which they are dependent. The version of
NFC and the version of Unicode used by that system MUST be
consistent.
6. この仕様に一致しているシステムはそれらが依存しているユニコードのバージョンで割り当てられない少しのコード・ポイントも含むどんなストリングも伝えてはいけません。 NFCのバージョンとそのシステムによって使用されるユニコードのバージョンは一貫しているに違いありません。
The use of LF without CR is questionable; see Appendix B for more
discussion. The newer control characters IND (U+0084) and NEL ("Next
Line", U+0085) might have been used to disambiguate the various line-
ending situations, but, because their use has not been established on
the Internet, because many protocols require CRLF, and because IND
and NEL fall within the "C1 Controls" group (see below), they MUST
NOT be used. Similar observations apply to the yet newer line and
paragraph separators at U+2028 and U+2029 and any future characters
that might be defined to serve these functions. For this
specification and protocols that depend on it, lines end in CRLF and
only in CRLF. Anything that does not end in CRLF is either not a
line or is severely malformed.
CRのないLFの使用は疑わしいです。 より多くの議論に関してAppendix Bを見てください。 より新しい制御文字のIND(U+0084)とNEL(「次の線」、U+0085)は様々な系列終わりの状況のあいまいさを除くのに使用されたかもしれませんが、多くのプロトコルがCRLFを必要とするので彼らの使用がインターネットで確立されていなくて、INDとNELが「C1コントロール」というグループの中に落ちるので(以下を見てください)、それらは使用してはいけません。 同様の観測はU+2028とU+2029の分離符とこれらの機能を果たすために定義されるどんな将来のキャラクタもまだより新しい系列とパラグラフに適用します。 それによるこの仕様とプロトコルのために、系列はCRLFだけに終わります。 CRLFに終わらない何でも、系列でない厳しく奇形です。
The NVT specification contained a number of additional provisions, e.g., for the optional use of backspacing and "bare CR" (sent as CR NUL) to generate overstruck character sequences. The much greater number of precomposed characters in Unicode, the availability of combining characters, and the growing use of markup conventions of various types to show, e.g., emphasis (rather than attempting to do that via the use of special characters), should make such sequences largely unnecessary. These sequences SHOULD be avoided if at all possible. However, because they were optional in NVT applications and this specification is an NVT superset, they cannot be prohibited entirely. The most important of these rules is that CR MUST NOT appear unless it is immediately followed by LF (indicating end of line) or NUL. Because NUL (an octet whose value is all zeros, i.e., %x00 in the notation of [RFC5234]) is hostile to programming languages that use that character as a string delimiter, the CR NUL sequence SHOULD be avoided for that reason as well.
例えばバックスペースキーを押して印字位置を一字分戻ることの任意の使用と「むき出しのCR」(CR NULとして、発信する)がoverstruckキャラクタシーケンスを生成するように、NVT仕様は多くの追加条項を含みました。 ユニコードによる前構成されたキャラクタのはるかに大きい数(キャラクタ、および様々なタイプのマーク付けコンベンションの示している増加している使用、例えば強調(特殊文字の使用でそれをするのを試みるよりむしろ)を結合する有用性)で、そのような系列は主に不要になるべきです。 これらはSHOULDを配列します。できれば、避けられます。 しかしながら、それらがNVTアプリケーションで任意であり、この仕様がNVTスーパーセットであるので、それらを完全に禁止できません。 これらの規則に基づき最も重要であるのは、それがすぐにLF(行末を示す)かNULによって続かれていない場合CR MUST NOTが現れるということです。 NUL([RFC5234]の記法で値がすべてのゼロ、すなわち%x00である八重奏)が敵軍であり、ストリングデリミタ、CR NUL系列SHOULDとしてそのキャラクタを使用するプログラミング言語としてまた、その理由で避けられてください。
Klensin & Padlipsky Standards Track [Page 4] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[4ページ]。
3. Normalization
3. 正常化
There are cases where strings of Unicode are fundamentally equivalent, essentially representing the same text. These are called "canonical equivalents" in the Unicode Standard. For example, the following pairs of strings are canonically equivalent:
本質的には同じテキストを表して、ケースがユニコードのストリングが基本的に同等であるところにあります。 これらはユニコードStandardで「正準な同等物」と呼ばれます。 例えば、以下の組のストリングは正準に同等です:
U+2126 OHM SIGN U+03A9 GREEK CAPITAL LETTER OMEGA
U+2126オームサインU+03A9のギリシアの大文字オメガ
U+0061 LATIN SMALL LETTER A, U+0300 COMBINING GRAVE ACCENT U+00E0 LATIN SMALL LETTER A WITH GRAVE
U+0061ラテン語の小文字A、低アクセントU+00 0ユーロのラテン語の小文字Aを墓に結合するU+0300
Comparison of strings becomes much easier if any such cases are always represented by a single unique form. The Unicode Consortium specifies a normalization form, known as NFC [NFC], which provides the necessary mappings and mechanisms to convert all canonically equivalent sequences to a single unique form. Typically, this form produces precomposed characters for any sequences that can be represented in that fashion. It also reorders other combining marks so that they have a unique and unambiguous order.
何かそのような場合がいつもただ一つのユニークなフォームによって表されるなら、ストリングの比較ははるかに簡単になります。 ユニコードConsortiumはすべての正準に同等な系列をただ一つのユニークなフォームに変換するために必要なマッピングとメカニズムを提供するNFC[NFC]として知られている正常化書式を指定します。 通常、このフォームはそのファッションで表すことができるどんな系列のためにも前構成されたキャラクタを生産します。 それ、また、他の結合がaをユニークで明白にするようにマークする追加注文は注文されます。
Of the various normalization forms defined as part of Unicode, NFC is closest to actual use in practice, minimizes side-effects due to considering characters equivalent that may not be equivalent in all situations, and typically requires the least work when converting from non-Unicode encodings.
ユニコードの一部と定義された様々な正常化書式では、NFCは実際には実際の使用の最も近くにあって、キャラクタが同等であると考えるのによるすべての状況で同等でないかもしれない副作用を最小にして、非ユニコードencodingsから変えるとき、作業経済の法則を通常必要とします。
The section above requires that, except in very unusual circumstances, all Net-Unicode strings be transmitted in normalized form. Recognition of the fact that some implementations of applications may rely on operating system libraries over which they have little control and adherence to the robustness principle suggests that receivers of such strings should be prepared to receive unnormalized ones and to not react to that in excessive ways.
上のセクションは、非常に珍しい事情以外のすべてのネットユニコードストリングが正規形で伝えられるのを必要とします。 アプリケーションのいくつかの実装がそれらが少ないコントロールと固守を堅牢性の原則に持っているオペレーティングシステム図書館を当てにするかもしれないという事実の認識は、そのようなストリングの受信機が非正常にされたものを受けて、過度の方法でそれに反応しないように準備されるべきであると示唆します。
4. Versions of Unicode
4. ユニコードのバージョン
Unicode changes and expands over time. Large blocks of space are reserved for future expansion. New versions, which appear at regular intervals, add new scripts and characters. Occasionally they also change some property definitions. In retrospect, one of the advantages of ASCII [ASCII] when it was chosen was that the code space was full when the Standard was first published. There was no practical way to add characters or change code point assignments without being obviously incompatible.
ユニコードは、時間がたつにつれて、変化して、広がります。 大量株のスペースは今後の拡張のために予約されます。 新しいバージョン(一定の間隔を置いて現れる)は新しいスクリプトとキャラクタを加えます。 また、時折、彼らはいくつかの特性の定義を変えます。 追憶では、それが選ばれたとき、ASCII[ASCII]の利点の1つはStandardが最初に発行されたとき、コードスペースが完全であったということでした。 明らかに非互換でなくてキャラクタを加えるか、またはコードポイント課題を変えるどんな実用的な方法もありませんでした。
Klensin & Padlipsky Standards Track [Page 5] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[5ページ]。
While there are some security issues if people deliberately try to trick the system (see Section 6), Unicode version changes should not have a significant impact on the text stream specification of this document for the following reasons:
人々が故意にシステムをだまそうとするなら(セクション6を見てください)いくつかの安全保障問題がある間、ユニコードバージョン変化は以下の理由によるこのドキュメントのテキストストリーム仕様で重要な影響を与えるはずがありません:
o The transformation between Unicode code table positions and the
corresponding UTF-8 code is algorithmic; it does not depend on
whether a code point has been assigned or not.
o ユニコードコードテーブル位置と対応するUTF-8コードの間の変換はアルゴリズムです。 それはコード・ポイントが割り当てられたかどうかによりません。
o The normalization recommended here, NFC (see Section 3), performs
a very limited set of mappings, much more limited than those of
the more extensive NFKC used in, e.g., Nameprep [RFC3491].
o ここのお勧めの正常化(NFC(セクション3を見る))は非常に限られたセットのマッピングを実行します、より大規模なNFKCのものがコネを使用したより有限ないろいろな事、例えば、Nameprep[RFC3491]。
The NFC tables may be updated over time as new characters are added, but the Unicode Consortium has guaranteed the stability of all NFC strings. That is, if a string does not contain any unassigned characters, and it is normalized according to NFC, it will always be normalized according to all future versions of the Unicode Standard. The stability of the Net-Unicode format is thus guaranteed when any implementation that converts text into Net-Unicode format does not permit unassigned characters.
新しいキャラクタを加えるとき、時間がたつにつれて、NFCテーブルをアップデートするかもしれませんが、ユニコードConsortiumはすべてのNFCストリングの安定性を保証しました。 すなわち、ストリングが少しの割り当てられなかったキャラクタも含んでいなくて、NFCによると、正常にされると、ユニコードStandardのすべての将来のバージョンによると、それはいつも正常にされるでしょう。 ネットユニコード形式にテキストを変換するどんな実装も割り当てられなかったキャラクタを可能にしないとき、ネットユニコード形式の安定性はこのようにして保証されます。
Because Unicode code points that are reserved for private use do not have standard definitions or normalization interpretations, they SHOULD be avoided in strings intended for Internet interchange.
私的使用目的で予約されるユニコードコード・ポイントは標準定義か正常化解釈を持たないで、それらはSHOULDです。インターネット置き換えのために意図して、ストリングで避けられてください。
Were Unicode to be changed in a way that violated these assumptions, i.e., that either invalidated the byte string order specified in RFC 3629 or that changed the stability of NFC as stated above, this specification would not apply. Put differently, this specification applies only to versions of Unicode starting with version 5.0 and extending to, but not including, any version for which changes are made in either the UTF-8 definition or to NFC stability. Such changes would violate established Unicode policies and are hence unlikely, but, should they occur, it would be necessary to evaluate them for compatibility with this specification and other Internet uses of NFC.
ユニコードがすなわち、どちらかがRFC3629で指定されたバイトストリングオーダーを無効にしたというこれらの仮定に違反したか、または上で述べられるとしてNFCの安定性を変えた方法で変えられることになっているなら、この仕様は適用されないでしょうに。 異なって置かれて、この仕様はユニコードが変更がUTF-8定義で行われるどんなバージョンからもバージョン5.0から始まって、達しますが、含まないバージョンだけ、または、NFCの安定性に適用されます。 そのような変化は、確立したユニコード方針に違反して、したがって、ありそうもないのですが、起こるなら、NFCのこの仕様と他のインターネット用途との互換性のためにそれらを評価するのが必要でしょう。
If the specification of a protocol references this one, strings that are received by that protocol and that appear to be UTF-8 and are not otherwise identified (e.g., by charset labeling) SHOULD be treated as using UTF-8 in conformance with this specification.
UTF-8です。プロトコルの仕様であるなら、そうでなければ、そのプロトコルによって受け取られるストリングと様々な1つが見える参照は、この仕様がある順応で使用として扱われた(例えば、charsetラベリングによる)特定されたSHOULD UTF-8ではありません。
Klensin & Padlipsky Standards Track [Page 6] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[6ページ]。
5. Applicability and Stability of this Specification
5. このSpecificationの適用性とStability
5.1. Use in IETF Applications Specifications
5.1. IETFでアプリケーション仕様を使用してください。
During the development of this specification, there was some confusion about where it would be useful given that, e.g., the individual MIME media types used in email and with HTTP have their own rules about UTF-8 character types and normalization, and the application transport protocols impose their own conventions about line endings. There are three answers. The first is that, in retrospect, it would have been better to have those protocols and content types standardized in the way specified here, even though it is certainly too late to change them at this time. The second is that we have several protocols that are dependent on either the original Telnet design or other arrangements requiring a standard, interoperable, string definition without specific content-labels of one sort or another. Whois [RFC3912] is an example member of this group. As consideration is given to upgrading them for non-ASCII use, this specification provides a normative reference that provides the same stability that NVT has provided the ASCII forms. This specification is intended for use by other specifications that have not yet defined how to use Unicode. Having a preferred standard Internet definition for Unicode text streams -- rather than just one for transmission codings -- may help improve the specification and interoperability of protocols to be developed in the future. This specification is not intended for use with specifications that already allow the use of UTF-8 and precisely define that use.
この仕様の開発の間、それを考えて、それが役に立つところに関して何らかの混乱がありました、そして、例えばメールとHTTPと共に使用される独特のMIMEメディアタイプはUTF-8字種と正常化に関するそれら自身の規則を持っています、そして、アプリケーショントランスポート・プロトコルは系列結末に関してそれら自身のコンベンションを課します。 3つの答えがあります。 1番目はここで指定された方法でそれらのプロトコルとcontent typeを追憶で標準化させているほうがよいだろうということです、このときそれらを変えるのが確かに遅過ぎますが。 2番目は私たちには1種類の特定の満足しているラベルなしで標準の、そして、共同利用できるストリング定義を必要とするオリジナルのTelnetデザインか他のアレンジメントかもののどちらか別に依存するいくつかのプロトコルがあるということです。 Whois[RFC3912]はこのグループの例のメンバーです。 非ASCII使用のためにそれらをアップグレードさせることに対して考慮を払うとき、この仕様はNVTが提供したのと同じ安定性にASCIIフォームを提供する引用規格を提供します。この仕様は使用のためにまだユニコードを使用する方法を定義していない他の仕様で意図します。 テキストがトランスミッションコーディングのためのちょうどものよりむしろ流すユニコードのための都合のよい標準のインターネット定義を持っているのは、将来開発されるためにプロトコルの仕様と相互運用性を改良するのを助けるかもしれません。 この仕様は既にUTF-8の使用を許して、正確にその使用を定義する仕様がある使用のために意図しません。
5.2. Unicode Versions and Applicability
5.2. ユニコードバージョンと適用性
The IETF faces a practical dilemma with regard to versions of Unicode. Each new version brings with it new characters and sometimes new combining characters. Version 5.0 introduces the new concept of sequences of characters named as if they were individual characters (see [NamedSequences]). The normalization represented by NFC is stable if all strings are transmitted and stored in normalized form if corrections are never made to character definitions or normalization tables and if unassigned code points are never used. The latter is important because an unassigned code point always normalizes to itself. However, if the same code point is assigned to a character in a future version, it may participate in some other normalization mapping (some specific difficulties in this regard are discussed in [RFC4690]). It is worth noting that transmission in normalized form is not required by either the IETF's UTF-8 Standard [RFC3629] or by standards dependent on the current version of Stringprep [RFC3454].
IETFはユニコードのバージョンに関して実用的なジレンマに直面しています。 それぞれの新しいバージョンはそれと共に新しいキャラクタと時々新しい結合したキャラクタを連れて来ます。 バージョン5.0はまるで彼らが個性であるかのように指定されたキャラクタの系列の新しい概念を紹介します([NamedSequences]を見てください)。 修正をキャラクタ定義か正常化テーブルに決してしないで、また割り当てられなかったコード・ポイントを決して使用しないなら、正規形ですべてのストリングを伝えて、保存するなら、NFCによって表された正常化は安定しています。 割り当てられなかったコード・ポイントがいつもそれ自体に正常にされるので、後者は重要です。 しかしながら、同じコード・ポイントが将来のバージョンでキャラクタに割り当てられるなら、それはある他の正常化マッピングに参加するかもしれません([RFC4690]でこの点でいくつかの特定の困難について議論します)。 正規形におけるトランスミッションがIETFのUTF-8 Standard[RFC3629]かStringprepの最新版に依存する規格[RFC3454]によって必要とされないことに注意する価値があります。
Klensin & Padlipsky Standards Track [Page 7] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[7ページ]。
All would be well with this as described in Section 4 except for one problem: Applications typically do not perform their own conversions to Unicode and may not perform their own normalizations but instead rely on operating system or language library functions -- functions that may be upgraded or otherwise changed without changes to the application code itself. Consequently, there may be no plausible way for an application to know which version of Unicode, or which version of the normalization procedures, it is utilizing, nor is there any way by which it can guarantee that the two will be consistent.
すべてがこれによって1つの問題以外のセクション4で説明されるように順調でしょう: アプリケーションは、それら自身の変換をユニコードに通常実行しないで、それら自身の正常化を実行しませんが、代わりにオペレーティングシステムか言語ライブラリ関数を当てにするかもしれません--アップグレードするか、または別の方法で応用コード自体への変化なしで変えられるかもしれない機能。 その結果、ユニコードのどのバージョン、または正常化手順のどのバージョンを知るかアプリケーションのためのどんなもっともらしい方法もないかもしれなくて、それは、2が一貫するのを保証できるどんな方法にも利用であり、そこにあります。
Because of per-version changes in definitions and tables, Stringprep and documents depending on it are now tied to Unicode Version 3.2 [Unicode32] and full interoperability of Internet Standard UTF-8 [RFC3629], when used with normalization as specified here, is dependent on normalization definitions and the definition of UTF-8 itself not changing after Unicode Version 5.0. These assumptions seem fairly safe, but they are still assumptions. Rather than being linked to the latest available version of Unicode, version 5.0 [Unicode] or broader concepts of version independence based on specific assumptions and conditions, this specification could reasonably have been tied, like Stringprep and Nameprep to Unicode 3.2 [Unicode32] or some more recent intermediate version, but, in addition to the obvious disadvantages of having different IETF standards tied to different versions of Unicode, the library-based application implementation behavior described above makes these version linkages nearly meaningless in practice.
定義とテーブルにおける堕落変化のために、それによるStringprepとドキュメントは現在ユニコードバージョン3.2[Unicode32]に結ばれます、そして、正常化と共にここで指定されるとして使用されると、インターネットStandard UTF-8[RFC3629]の最大限のインターオペラビリティは、ユニコードバージョン5.0の後に変化しないことでUTF-8自身の正常化定義と定義に依存しています。 これらの仮定はかなり安全に見えますが、それでも、それらは仮定です。 むしろ、この仕様は特定の仮定と状態に基づくバージョン独立のユニコードの最新の利用可能なバージョン、バージョン5.0ユニコードまたは、より広い概念にリンクされるより合理的に結ばれたかもしれません、ユニコード3.2Unicode32かそれ以上の最近の中間的バージョンへのStringprepとNameprepのように; しかし、異なったIETF規格をユニコードの異なった見解に結ばせる明白な損失に加えて、上で説明されたライブラリベースのアプリケーション実装の振舞いでこれらのバージョンリンケージは実際にはほとんど無意味になります。
In theory, one can get around this problem in four ways:
理論上、1つは4つの方法でこの問題を逃れることができます:
1. Freeze on a particular version of Unicode and try to insist that
applications enforce that version by, e.g., containing lists of
unassigned characters and prohibiting their use. Of course, this
would prohibit evolution to include newly-added scripts and the
tables of unassigned code points would be cumbersome.
1. 割り当てられなかったキャラクタのリストを含んでいて、彼らの使用を禁止しながら、例えばユニコードの特定のバージョンで凍ってください、そして、アプリケーションがそのバージョンを実施すると主張するようにしてください。 もちろん、これは新たに加えられたスクリプトを含むように発展を禁止するでしょう、そして、割り当てられなかったコード・ポイントのテーブルは扱いにくいでしょう。
2. Require that every Unicode "text" string or file start with a
version indication, somewhat akin to the "byte order mark"
indicator. It is unlikely that this provision would be
practical. More important, it would require that each
application implementation be prepared to either support multiple
normalization tables and versions or that it reject text from
Unicode versions with which it was not prepared to deal.
2. あらゆるユニコード「テキスト」ストリングかファイルがバージョン指示から始まるのを必要であってください、「バイト・オーダー・マーク」インディケータといくらか同系です。 この支給が実用的であることは、ありそうもないです。 より重要です、それはそれぞれのアプリケーション実装が複数の正常化がテーブルとバージョンであるとサポートするように準備されるか、またはそれが準備されなかったユニコードバージョンから取引までテキストを拒絶するのを必要とするでしょう。
3. Devise a different set of normalization rules that would, e.g.,
guarantee that no character assigned to a previously-unassigned
code point in Unicode was ever normalized to anything but itself
and use those rules instead of NFC. It is not clear whether or
not such a set of rules is possible or whether some other
3. そうする異なったセットの正常化規則について工夫してください、そして、例えば、ユニコードで以前に割り当てられなかったコード・ポイントに選任されなかったキャラクタが全く今までにそれ自体以外の何にでも正常にされたのを保証してください、そして、NFCの代わりにそれらの規則を使用してください。 または、1セットのそのような規則が可能であるかどうかは、明確でない、ある他の
Klensin & Padlipsky Standards Track [Page 8] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[8ページ]。
completely stable set of rules could be devised, perhaps in
combination with restrictions on the ways in which characters
were added in future versions of Unicode.
完全に、安定集合の規則について工夫できました、恐らくキャラクタがユニコードの将来のバージョンで加えられた方法における制限と組み合わせて。
4. Devise a normalization process that is otherwise equivalent to
NFC but that rejects code points that are unassigned in the
current version of Unicode, rather than mapping those code points
to themselves. This would still leave some risk of incompatible
corrections in Unicode and possibly a few edge cases, but it is
probably stable enough for Internet use in the overwhelming
number of cases. This process has been discussed in the Unicode
Consortium under the name "Stable NFC".
4. そうでなければNFCに同等ですが、それらのコード・ポイントを自分たちに写像するよりユニコードの最新版でむしろ割り当てられないコード・ポイントを拒絶する正常化プロセスについて工夫してください。 これはまだユニコードにおける両立しない修正とことによるといくつかの縁のケースの何らかの危険を残しているでしょうが、ケースの圧倒的な数におけるインターネットの利用において、それはたぶん十分安定しています。 「安定したNFC」という名でユニコードConsortiumでこのプロセスについて議論しました。
None of these approaches seems ideal: the ideal procedure would be as stable and predictable as ASCII has been. But that level is simply not feasible as long as Unicode continues to evolve by the addition of new code points and scripts. The fourth option listed above appears to be a reasonable compromise.
これらのアプローチのいずれも理想的に見えません: 理想的な手順は、ASCIIと同じくらい安定していて同じくらい予測できるでしょう。 しかし、ユニコードが、新法の追加でポイントとスクリプトを発展し続けている限り、そのレベルは絶対に可能ではありません。 上に記載された4番目のオプションは妥当な感染であるように見えます。
6. Security Considerations
6. セキュリティ問題
This specification provides a standard form for the use of Unicode as "network text". Most of the same security issues that apply to UTF-8, as discussed in [RFC3629], apply to it, although it should be slightly less subject to some risks by virtue of requiring NFC normalization and generally being somewhat more restrictive. However, shifts in Unicode versions, as discussed in Section 5.2, may introduce other security issues.
この仕様は「ネットワークテキスト」としてユニコードの使用に標準形式を提供します。 [RFC3629]で議論するようにUTF-8に適用される同じ安全保障問題の大部分はそれに適用されます、それがわずかにNFC正常化を必要とすることによるいくつかのリスクを条件として一般にいくらか制限している状態以上以下であるべきですが。 しかしながら、ユニコードバージョンにおけるセクション5.2で議論するシフトは他の安全保障問題を紹介するかもしれません。
Programs that receive these streams should use extreme caution about assuming that incoming data are normalized, since it might be possible to use unnormalized forms, as well as invalid UTF-8, as part of an attack. In particular, firewalls and other systems that interpret UTF-8 streams should be developed with the clear knowledge that an attacker may deliberately send unnormalized text, for instance, to avoid detection by naive text-matching systems.
受信データが正常にされると仮定することに関してこれらのストリームを受けるプログラムは極端な警告を使用するはずです、非正常にされたフォームを使用するのが可能であるかもしれないので、無効のUTF-8と同様に、攻撃の一部として。 特に、UTF-8ストリームを解釈するファイアウォールと他のシステムは例えば、攻撃者がナイーブなテキストマッチングシステムで検出を避けるために故意に非正常にされたテキストを送るかもしれないという明確な知識で開発されるべきです。
NVT contains a requirement, of necessity repeated here (see Section 2), that the CR character be immediately followed by either LF or ASCII NUL (an octet with all bits zero). NUL may be problematic for some programming languages that use it as a string terminator, and hence a trap for the unwary, unless caution is used. This may be an additional reason to avoid the use of CR entirely, except in sequence with LF, as suggested above.
NVTはここに繰り返された状態で必要な要件を含んでいて(セクション2を見てください)、CRキャラクタはすぐに、LFかASCII NUL(ビットが合っているゼロすべてがある八重奏)のどちらかによって続かれています。 ストリングターミネータとしてそれを使用して、不注意にしたがって、罠を使用するいくつかのプログラミング言語に、NULは問題が多いかもしれません、警告が使用されていない場合。 これはCRの使用を完全に避ける追加理由であるかもしれません、連続してLFを除いて、上に示されるように。
The discussion about Unicode versions above (see Section 4 and Section 5.2) makes several assumptions about future versions of Unicode, about NFC normalization being applied properly, and about
ユニコードバージョンについての上(セクション4とセクション5.2を見る)の議論はユニコードの将来のバージョンに関するいくつかの仮定をします、周囲で適切に適用されるNFC正常化に関して
Klensin & Padlipsky Standards Track [Page 9] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[9ページ]。
UTF-8 being processed and transmitted exactly as specified in RFC 3629. If any of those assumptions are not correct, then there are cases in which strings that would be considered equivalent do not compare equal. Robust code should be prepared for those possibilities.
RFC3629でちょうど指定されるように処理されて、伝えられるUTF-8。 それらの仮定のいずれも正しくないなら、同等であると考えられるストリングが同輩を比較しない場合があります。 強健なコードはそれらの可能性のために準備されるべきです。
7. Acknowledgments
7. 承認
Many thanks to Mark Davis, Martin Duerst, and Michel Suignard for suggestions about Unicode normalization that led to the format described here, and especially to Mark for providing the paragraphs that describe the role of NFC. Thanks also to Mark, Doug Ewell, Asmus Freytag for corrected text describing Unicode transmission forms, and to Tim Bray, Carsten Bormann, Stephane Bortzmeyer, Martin Duerst, Frank Ellermann, Clive D.W. Feather, Ted Hardie, Bjoern Hoehrmann, Alfred Hoenes, Kent Karlsson, Bill McQuillan, George Michaelson, Chris Newman, and Marcos Sanz for a number of helpful comments and clarification requests.
それがNFCの役割について説明するパラグラフであるならここで説明された形式と、そして、特にマークに導いたユニコード正常化に関する提案のためにマーク・デイビス、マーチンDuerst、およびミシェルSuignardをありがとうございます。 また、マーク、ダグ・イーウェル(トランスミッションが形成して、多くの役に立つコメントと明確化のためのアルフレッドHoenes、ケントのティムBray、カルステン・ボルマン、ステファーヌBortzmeyer、マーチンDuerst、フランクEllermann、クライヴD.W.Feather、テッド・ハーディー、ビョルンHoehrmann、カールソン、ビル・マッキラン、ジョージMichaelson、クリス・ニューマン、およびマルコス・サンス要求するユニコードについて説明する直っているテキストのためのAsmusフライターク)をありがとうございます。
Klensin & Padlipsky Standards Track [Page 10] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[10ページ]。
Appendix A. History and Context
付録A.歴史と文脈
This subsection contains a review of prior work in the ARPANET and Internet to establish a standard text type, work that establishes the context and motivation for the approach taken in this document. The text is explanatory rather than normative: nothing in this section is intended to change or update any current specification. Those who are uninterested in this review and analysis can safely skip this section.
この小区分は、標準のテキストタイプ(本書では取られたアプローチに関する文脈と動機を確立する仕事)を証明するためにアルパネットとインターネットに先の仕事のレビューを保管しています。 規範的であるというよりむしろテキストは説明しています: このセクションの何も、どんな現在の仕様も変えるか、またはアップデートすることを意図しません。 このレビューと分析に無関心なものは安全にこのセクションをスキップできます。
One of the earlier application design decisions made in the development of ARPANET, a decision that was carried forward into the Internet, was the decision to standardize on a single and very specific coding for "text" to be passed across the network [RFC0020]. Hosts on the network were then responsible for translating or mapping from whatever character coding conventions were used locally to that common intermediate representation, with sending hosts mapping to it and receiving ones mapping from it to their local forms as needed. It is interesting to note that at the time the ARPANET was being developed, participating host operating systems used at least three different character coding standards: the antiquated BCD (Binary Coded Decimal), the then-dominant major manufacturer-backed EBCDIC (Extended BCD Interchange Code), and the then-still emerging ASCII (American Standard Code for Information Interchange). Since the ARPANET was an "open" project and EBCDIC was intimately linked to a particular hardware vendor, the original Network Working Group agreed that its standard should be ASCII. That ASCII form was precisely "7-bit ASCII in an 8-bit field", which was in effect a compromise between hosts that were natively 7-bit oriented (e.g., with five seven-bit characters in a 36-bit word), those that were 8-bit oriented (using eight-bit characters) and those that placed the seven-bit ASCII characters in 9-bit fields with two leading zero bits (four characters in a 36-bit word).
アルパネットの開発でされた以前のアプリケーション設計決定の1つ(インターネットに進展した決定)は「テキスト」がネットワーク[RFC0020]の向こう側に通過される単一の、そして、非常に特定のコード化のときに標準化する決定でした。 次に、ネットワークのホストが翻訳するのに責任があったか、またはいかなるキャラクタからもコード化コンベンションを写像するのは局所的にその共通中間体表現に使用されました、必要に応じてホストにそれに写像させて、それから地元のフォームまでものマッピングを受け取るのに。 アルパネットが開発されていたとき参加ホスト・オペレーティング・システムが少なくとも3つの異なったキャラクタコーディング標準を使用したことに注意するのはおもしろいです: -まだ次に、古めかしいBCD(2進化10進法)であって、次に、優位な主要なメーカーによって支持されたEBCDIC(拡張BCD Interchange Code)であって、ASCII(情報交換用米国標準コード)として現れます。 アルパネットが「開いている」プロジェクトであり、EBCDICが親密に特定のハードウェア業者にリンクされたので、オリジナルのNetwork作業部会は、規格がASCIIであるべきであるのに同意しました。 そのASCIIフォームは正確に事実上、指向していた状態でネイティブに7ビットであったホスト(例えば、36ビットの単語による5つの7ビットのキャラクタを伴う)と、指向していた状態で8ビットであったそれら(8ビットのキャラクタを使用する)と2先行ゼロビットで7ビットのASCII文字を9ビットの分野に任命したもの(36ビットの単語による4つのキャラクタ)での間妥協であった「8ビットの分野の7ビットのASCII」でした。
More standardization was suggested in the first preliminary description of the Telnet protocol [RFC0097]. With the iterations of that protocol [RFC0137] [RFC0139] and the drawing together of an essentially formal definition somewhat later [RFC0318], a standard abstraction, the Network Virtual Terminal (NVT) was established. NVT character-coding conventions (initially called "Telnet ASCII" and later called "NVT ASCII", or, more casually, "network ASCII") included the requirement that Carriage Return followed by Line Feed (CRLF) be the common representation for ending lines of text (given that some participating "Host" operating systems used the one natively, some the other, at least one used both, and a few used neither (preferring variable-length lines with counts or special delimiters or markers instead) and specified conventions for some other characters. Also, since NVT ASCII was restricted to seven-bit
より多くの標準化がTelnetプロトコル[RFC0097]の最初の予備の記述で示されました。 その繰り返しで、後で[RFC0318]本質的には正式な定義について[RFC0137][RFC0139]と図面についていくらか一緒に議定書の中で述べてください、標準の抽象化、Network Virtual Terminal(NVT)。設立されました。 キャラクタをコード化するNVTコンベンション(初めは、「telnet ASCII」と呼ばれて、後で「NVT ASCII」、または、より何気なく「ネットワークASCII」と呼ばれる)は改行(CRLF)があとに続いた復帰がテキストの終わりの線の共通表現であるという要件を含めました。(それを考えて、いくつかの参加「ホスト」オペレーティングシステムが1人のネイティブを使用しました; ある他のキャラクタのためのもう片方、少なくとも使用される、ものの両方、およびいくつかがどちらも(代わりにカウントがある可変長の台詞、特別なデリミタまたはマーカーを好む)使用しなかったいくつかと指定されたコンベンション; また; NVT ASCIIが7ビットに制限されたので
Klensin & Padlipsky Standards Track [Page 11] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[11ページ]。
characters, use of the high-order bit in octets was reserved for the transmission of control signaling information.
キャラクタ、八重奏における高位のビットの使用はコントロールシグナリング情報の伝達のために控えられました。
At a very high level, the concept was that a system could use whatever character coding and line representations were appropriate locally, but text transmitted over the network as text must conform to the single "network virtual terminal" convention. Virtually all early Internet protocols that presume transfer of "text" assume this virtual terminal model, although different ones assume or limit it in different ways. Telnet, the command stream and ASCII Type in FTP [RFC0542], the message stream in SMTP transfer [RFC2821], and the strings passed to finger [RFC0742] and whois [RFC0954] are the classic examples. More recently, HTTP [RFC1945] [RFC2616] follows the same general model but permits 8-bit data and leaves the line end sequence unspecified (the latter has been the source of a significant number of problems).
非常に高いレベルでは、概念はシステムが局所的にどんな適切であったキャラクタコード化と線表現も使用するかもしれないということでしたが、テキストが「仮想端末をネットワークでつないでください」という単一のコンベンションに従わなければならないので、テキストはネットワークの上を伝わりました。 「テキスト」の転送を推定するほとんどすべての早めのインターネットプロトコルがこの仮想端末モデルに就きます、異なった人は、異なった方法でそれを仮定するか、または制限しますが。 telnet、FTP[RFC0542]におけるコマンドの流れとASCII Type、SMTP転送[RFC2821]におけるメッセージストリーム、および[RFC0742]とwhois[RFC0954]を弄るために渡されたストリングは典型例です。 より最近、HTTP[RFC1945][RFC2616]は、同じ一般的なモデルに従いますが、8ビットのデータを可能にして、列の最後尾の系列を不特定のままにします(後者は多くの問題の源です)。
Appendix B. The ASCII NVT Definition
付録B.はASCII NVT定義です。
The main body of this specification is intended as an update to, and internationalized version of, the Net-ASCII definition. The specification is self-contained in that parts of the Net-ASCII definition that are no longer recommended are not included above. Because Net-ASCII evolved somewhat over time and there has been debate about which specification is the "official" Net-ASCII, it is appropriate to review the key elements of that definition here. This review is informal with regard to the contents of Net-ASCII and should not be considered as a normative update or summary of the earlier specifications (Section 2 does specify some normative updates to those specifications and some comments below are consistent with it).
この仕様の本体がアップデートとして意図して、バージョンを国際的にした、ネットASCII定義。 ネットASCII定義のもうお勧めでない部分が上に含まれていないので、仕様は自己充足的です。 ネットASCIIが時間がたつにつれて、いくらか発展して、仕様が「公式」のネットASCIIである討論があったので、ここでその定義の主要な要素を見直すのは適切です。 このレビューをネットASCIIのコンテンツに関して非公式であり、以前の仕様の標準のアップデートか概要であるとみなすべきではありません(セクション2はいくつかの標準のアップデートをそれらの仕様に指定します、そして、以下でのいくつかのコメントがそれと一致しています)。
The first part of the section titled "THE NVT PRINTER AND KEYBOARD" in RFC 854 [RFC0854] is generally, although not universally, considered to be the normative definition of the (ASCII) Network Virtual Terminal and hence of Net-ASCII. It includes not only the graphic ASCII characters but a number of control characters. The latter are given Internet-specific meanings that are often more specific than the definitions in the ASCII specification. In today's usage, and for the present specification, the following clarifications and updates to that list should be noted. Each one is accompanied by a brief explanation of the reason why the original specification is no longer appropriate.
一般に、RFC854[RFC0854]の「NVTプリンタとキーボード」と題をつけられたセクションの最初の部分はそうです、一般にはありませんが、(ASCII)ネットワーク仮想端末としたがって、ネットのASCIIの標準の定義であると考えられて。 それはグラフィックASCII文字だけではなく、多くの制御文字も含んでいます。 ASCII仕様との定義よりしばしば特定のインターネット特有の意味を後者に与えます。 今日の用法、および現在の仕様によって、そのリストへの以下の明確化とアップデートは有名であるべきです。 正式仕様書がもう適切でない理由に関する短い説明で各々は同伴されます。
1. The "defined but not required" codes -- BEL (U+0007), BS
(U+0008), HT (U+0009), VT (U+000B), and FF (U+000C) -- and the
undefined control codes ("C0") SHOULD NOT be used unless required
by exceptional circumstances. Either their original "network
1. 「定義されますが、必要でない」コード(BEL(U+0007)、BS(U+0008)、HT(U+0009)、バーモント(U+000B)、およびFF(U+000C))と未定義の制御コード、(「C0") 例外的な事情は必要でない場合、使用するべきではありません」。 それらのオリジナルの「ネットワーク」
Klensin & Padlipsky Standards Track [Page 12] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[12ページ]。
printer" definitions are no longer in general use, common
practice has evolved away from the formats specified there, or
their use to simulate characters that are better handled by
Unicode is no longer appropriate. While the appearance of some
of these characters on the list may seem surprising, BS now has
an ambiguous interpretation in practice (erasing in some systems
but not in others), the width associated with HT varies with the
environment, and VT and FF do not have a uniform effect with
regard to either vertical positioning or the associated
horizontal position result. Of course, telnet escapes are not
considered part of the data stream and hence are unaffected by
this provision.
もう一般にない、「プリンタ」定義はそうです。使用、一般的な習慣がそこで指定された形式から遠くで発展したか、または、より良いユニコードによって扱われたキャラクタをシミュレートする彼らの使用はもう適切ではありません。 リストにおけるこれらの何人かのキャラクタの外観は驚くべきものに見えるかもしれませんが、BSは現在習慣(いくつかのシステムでは、他のもので消すのではなく、消す)であいまいな解釈を持っています、そして、環境に従って、HTに関連している幅は異なります、そして、バーモントとFFには、垂直な位置決めか関連水平な位置の結果のどちらかに関して一定の効果がありません。 もちろん、telnetエスケープは、データ・ストリームの一部であることは考えられないで、したがって、この支給で影響を受けないです。
2. In Net-ASCII, CR MUST NOT appear except when immediately followed
by either NUL or LF, with the latter (CR LF) designating the "new
line" function. Today and as specified above, CR should
generally appear only when followed by LF. Because page layout
is better done in other ways, because NUL has a special
interpretation in some programming languages, and to avoid other
types of confusion, CR NUL should preferably be avoided as
specified above.
2. ネットASCIIでは、すぐにNULかLFのどちらかによって続かれているときに時を除いて、CR MUST NOTは現れます、後者(CR LF)が「復帰改行」機能を指定していて。 今日、上で指定されるように、LFによって続かれている場合にだけ、一般に、CRは見えるはずです。 ページレイアウトが他の方法で完了しているほうがよくて、NULにはいくつかのプログラミング言語における特別な解釈があって、もう一方を避けるのが混乱をタイプするので、望ましくは、CR NULは上で指定されるとして避けられるべきです。
3. LF CR SHOULD NOT appear except as a side-effect of multiple CR LF
sequences (e.g., CR LF CR LF).
3. 複数のCR LF系列(例えば、CR LF CR LF)の副作用を除いて、LF CR SHOULD NOTは現れます。
4. The historical NVT documents do not call out either "bare LF" (LF
without CR) or HT for special treatment. Both have generally
been understood to be problematic. In the case of LF, there is a
difference in interpretation as to whether its semantics imply
"go to same position on the next line" or "go to the first
position on the next line" and interoperability considerations
suggest not depending on which interpretation the receiver
applies. At the same time, misinterpretation of LF is less
harmful than misinterpretation of "bare" CR: in the CR case, text
may be erased or made completely unreadable; in the LF one, the
worst consequence is a very funny-looking display. Obviously, HT
is problematic because there is no standard way to transmit
intended tab position or width information in running text.
Again, the harm is unlikely to be great if HT is simply
interpreted as one or more spaces, but, in general, it cannot be
relied upon to format information.
4. 歴史的なNVTドキュメントは特別な処理のために「むき出しのLF」(CRのないLF)かHTのどちらかを呼び出しません。 一般に、両方が問題が多いのが理解されています。 LFの場合には、意味論が、「次の線の上に同じ位置に行ってください」か「次の線に第1ポジションまで行ってください」と相互運用性問題が、受信機がどの解釈を適用するかによるのを示さないのを含意するかどうかに関して解釈上の相違があります。 同時に、LFの誤解は「むき出し」のCRの誤解ほど有害ではありません: CR場合では、テキストを消すか、または完全に読みにくくするかもしれません。 LF1では、最も悪い結果はおかしく非常に見える表示です。 明らかに、広告のための活字原稿には意図しているタブ位置か幅の情報を伝えるどんな標準の方法もないので、HTは問題が多いです。 一方、HTが1つ以上の空間として単に解釈されますが、それで一般に形式情報を当てにすることができないなら、害はすばらしそうにはありません。
It is worth noting that the telnet IAC character (an octet consisting of all ones, i.e., %xFF) itself is not a problem for UTF-8 since that particular octet cannot appear in a valid UTF-8 string. However, while few of them have been used, telnet permits other command- introducer characters whose bit sequences in an octet may be part of valid UTF-8 characters. While it causes no ambiguity in UTF-8,
その特定の八重奏が有効なUTF-8ストリングに現れることができないのでtelnet IACキャラクタ(すなわち、すべてのもの、%xFFから成る八重奏)自体がUTF-8のための問題でないことに注意する価値があります。 しかしながら、それらのわずかしか使用されていませんが、telnetは八重奏における噛み付いている系列が有効なUTF-8キャラクタの一部であるかもしれない他のコマンド誘導子キャラクタを可能にします。 UTF-8であいまいさを全く引き起こしませんが
Klensin & Padlipsky Standards Track [Page 13] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[13ページ]。
Unicode assigns a graphic character ("Latin Small Letter Y with
Diaeresis") to U+00FF (octets C3 B0 in UTF-8). Some caution is
clearly in order in this area.
ユニコードは図形文字(「分切があるラテン語の小文字Y」)をU+00FF(UTF-8の八重奏C3 B0)に割り当てます。 何らかの警告がこの領域で明確に整然としています。
Appendix C. The Line-Ending Problem
付録C.は線結末問題です。
The definition of how a line ending should be denoted in plain text strings on the wire for the Internet has been controversial from even before the introduction of NVT. Some have argued that recipients should be required to interpret almost anything that a sender might intend as a line ending as actually a line ending. Others have pointed out that this would lead to some ambiguities of interpretation and presentation and would violate the principle that we should minimize the number of forms that are permitted on the wire in order to promote interoperability and eliminate the "every recipient needs to understand every sender format" problem. The design of this specification, like that of NVT, takes the latter approach. Its designers believe that there is little point in a standard if it is to specify "anyone can do whatever they like and the receiver just needs to cope".
線結末がワイヤの上にプレーンテキストストリングでどうインターネットに指示されるべきであるかに関する定義はNVTの導入の前同等であるのから論議を呼んでいます。 或るものは、受取人が実際に線結末としてほとんど送付者が線結末として意図するかもしれないものは何でも解釈するべきでなければならないと主張しました。 他のものは、これが相互運用性を促進して、「すべての受取人が、あらゆる送付者形式を理解する必要がある」という問題を解決するために、解釈とプレゼンテーションのいくつかのあいまいさに通じて、私たちがワイヤの上に受入れられるフォームの数を最小にするべきであるという原則に違反すると指摘しました。 NVTのもののように、この仕様のデザインは後者のアプローチを取ります。 指定するために、「だれでも彼らが好きであり、受信機が対処するためにただ必要とすることなら何でもできる」ということであるなら、デザイナーは、ポイントがほとんど規格にないと信じています。
A further discussion of the nature and evolution of the line-ending
problem appears in Section 5.8 of the Unicode Standard [Unicode] and
is suggested for additional reading. If we were starting with the
Internet today, it would probably be sensible to follow the
recommendation there and use LS (U+2028) exclusively, in preference
to CRLF. However, the installed base of use of CRLF and the
importance of forward compatibility with NVT and protocols that
assume it makes that impossible, so it is necessary to continue using
CRLF as the "New Line Function" ("NLF", see the terminology section
in that reference).
自然のさらなる議論と線結末問題の発展は、ユニコードStandard[ユニコード]のセクション5.8に現れて、追加読書のために示されます。 私たちが今日インターネットから始まっているなら、そこに推薦に続いて、排他的に、LS(U+2028)を使用するのはたぶん分別があるでしょうに、CRLFに優先して。 しかしながら、CRLFで役に立つインストールされたベースとNVTとの下位互換とそれを仮定するプロトコルの重要性でそれが不可能になるので、「復帰改行機能」としてCRLFを使用し続けるのが必要です(用語部は、その参照で"NLF"と見ます)。
Appendix D. A Note about Related Future Work
関連未来頃の注意が扱う付録D.
Consideration should be given to a Telnet (or SSH [RFC4251]) option to specify this type of stream and an FTP extension [RFC0959] to permit a new "Unicode text" data TYPE.
新しい「ユニコードテキスト」データTYPEを可能にするために、このタイプの流れとFTP拡大[RFC0959]を指定するためにTelnet(または、SSH[RFC4251])オプションに対して考慮を払うべきです。
Klensin & Padlipsky Standards Track [Page 14] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[14ページ]。
References
参照
Normative References
引用規格
[ISO10646] International Organization for Standardization,
"Information Technology - Universal Multiple-Octet
Coded Character Set (UCS) - Part 1: Architecture
and Basic Multilingual Plane", ISO/
IEC 10646-1:2000, October 2000.
[ISO10646]国際標準化機構、「情報技術--普遍的な複数の八重奏コード化文字集合(UCS)--第1部:、」 2000年10月の「構造的、そして、基本的な多言語飛行機」、ISO/IEC10646-1:2000。
[NFC] Davis, M. and M. Duerst, "Unicode Standard Annex
#15: Unicode Normalization Forms", October 2006,
<http://www.unicode.org/reports/tr15/>.
[NFC] デイヴィス、M.、およびM.Duerst、「ユニコード規格は#15、を付加します」。 「ユニコード正常化フォーム」、2006年10月、<http://www.unicode.org/reports/tr15/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[Unicode] The Unicode Consortium, "The Unicode Standard,
Version 5.0", 2007.
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン5インチ、2007。」
Boston, MA, USA: Addison-Wesley. ISBN
0-321-48091-0
ボストン(MA)米国: アディソン-ウエスリー。 ISBN0-321-48091-0
[Unicode32] The Unicode Consortium, "The Unicode Standard,
Version 3.0", 2000.
[Unicode32] ユニコード共同体、「ユニコード規格、バージョン3インチ、2000。」
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
61633-5). Version 3.2 consists of the definition
in that book as amended by the Unicode Standard
Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the
Unicode Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/).
(読書、MA、アディソン-ウエスリー、2000ISBN0-201- 61633-5。) バージョン3.2はユニコードStandard Annex#27によって修正されるようにその本との定義から成ります: ( http://www.unicode.org/reports/tr27/ )とユニコード規格別館#28によるユニコード3.1: ユニコード3.2( http://www.unicode.org/reports/tr28/ )。
Klensin & Padlipsky Standards Track [Page 15] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[15ページ]。
Informative References
有益な参照
[ASCII] American National Standards Institute (formerly
United States of America Standards Institute), "USA
Code for Information Interchange", ANSI X3.4-1968,
1968.
[ASCII]American National Standards Institut(以前アメリカ合衆国規格研究所)、「米国情報交換用符号」、ANSI X3.4-1968、1968。
ANSI X3.4-1968 has been replaced by newer versions
with slight modifications, but the 1968 version
remains definitive for the Internet. ISO 646
International Reverence Version (IRV)
[ISO.646.1991] is usually considered equivalent to
ASCII.
わずかな変更でANSI X3.4-1968をより新しいバージョンに取り替えましたが、1968年のバージョンはインターネットに決定的に残っています。 通常、ISO646の国際Reverenceバージョン(IRV)[ISO.646.1991]はASCIIに同等であると考えられます。
[ISO.646.1991] International Organization for Standardization,
"Information technology - ISO 7-bit coded character
set for information interchange", ISO Standard 646,
1991.
[ISO、.646、.1991、]、国際標準化機構、「情報技術--、情報交換のためのISOの7ビットのコード化文字集合、」、ISO Standard646、1991
[NamedSequences] The Unicode Consortium, "NamedSequences-4.1.0.txt",
2005, <http://www.unicode.org/Public/UNIDATA/
NamedSequences.txt>.
[NamedSequences]ユニコード共同体、「NamedSequences-4.1.0.txt」、2005、<http://www.unicode.org/公衆/UNIDATA/NamedSequences.txt>。
[RFC0020] Cerf, V., "ASCII format for network interchange",
RFC 20, October 1969.
[RFC0020] サーフ、V.、「ネットワーク置き換えのためのASCII書式」、RFC20、1969年10月。
[RFC0097] Melvin, J. and R. Watson, "First Cut at a Proposed
Telnet Protocol", RFC 97, February 1971.
[RFC0097] メルビンとJ.とR.ワトソン、「プロトコルは最初に提案されたtelnetで切れた」RFC97、1971年2月。
[RFC0137] O'Sullivan, T., "Telnet Protocol - a proposed
document", RFC 137, April 1971.
[RFC0137]オサリヴァン、T.、「テルネット・プロトコル--aはドキュメントを提案した」、RFC137、4月1971日
[RFC0139] O'Sullivan, T., "Discussion of Telnet Protocol",
RFC 139, May 1971.
[RFC0139]オサリヴァン(T.、「テルネット・プロトコルの議論」、RFC139)は1971がそうするかもしれません。
[RFC0318] Postel, J., "Telnet Protocols", RFC 318,
April 1972.
[RFC0318] ポステル、J.、「テルネット・プロトコル」、RFC318、1972年4月。
[RFC0542] Neigus, N., "File Transfer Protocol", RFC 542,
August 1973.
[RFC0542]Neigus、N.、「ファイル転送プロトコル」、RFC542、1973年8月。
[RFC0698] Mock, T., "Telnet extended ASCII option", RFC 698,
July 1975.
[RFC0698] 見せかけ、T.、「telnetの拡張ASCIIオプション」、RFC698、1975年7月。
[RFC0742] Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
December 1977.
[RFC0742] Harrenstien、K.、「名前/指のプロトコル」、RFC742、1977年12月。
Klensin & Padlipsky Standards Track [Page 16] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[16ページ]。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC0854] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
[RFC0954] Harrenstien, K., Stahl, M., and E. Feinler,
"NICNAME/WHOIS", RFC 954, October 1985.
1985年10月の[RFC0954]HarrenstienとK.とスタール、M.とE.Feinler、「NICNAME/WHOIS」RFC954。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer
Protocol", STD 9, RFC 959, October 1985.
[RFC0959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0",
RFC 1945, May 1996.
[RFC1945] バーナーズ・リー、T.、フィールディング、R.、およびH.ニールセン、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2616] 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.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
ISO 10646", RFC 2781, February 2000.
[RFC2781]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")",
RFC 3454, December 2002.
[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A
Stringprep Profile for Internationalized Domain
Names (IDN)", RFC 3491, March 2003.
[RFC3491] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification",
RFC 3912, September 2004.
[RFC3912] Daigle、L.、「WHOISプロトコル仕様」、RFC3912、2004年9月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4251] YlonenとT.とC.Lonvick、「安全なシェル(セキュアシェル (SSH))プロトコル構造」、RFC4251、2006年1月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB,
"Review and Recommendations for Internationalized
Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、カープ、C.、IAB、および「国際化ドメイン名(IDNs)のためのレビューと推薦」、RFC4690(2006年9月)
Klensin & Padlipsky Standards Track [Page 17] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[17ページ]。
Authors' Addresses
作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john-ietf@jck.com
Michael A. Padlipsky 8011 Stewart Ave. Los Angeles, CA 90045 USA
マイケルA.Padlipsky8011スチュワートAve。 ロサンゼルス、カリフォルニア90045米国
Phone: +1 310-670-4288 EMail: the.map@alum.mit.edu
以下に電話をしてください。 +1 310-670-4288 メールしてください: the.map@alum.mit.edu
Klensin & Padlipsky Standards Track [Page 18] RFC 5198 Network Unicode March 2008
Klensin&Padlipsky規格は2008年のネットワークユニコード行進のときにRFC5198を追跡します[18ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Klensin & Padlipsky Standards Track [Page 19]
Klensin&Padlipsky標準化過程[19ページ]
一覧
スポンサーリンク
