この文書はRFC 5198の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group J. Klensin Request for Comments: 5198 M. Padlipsky Obsoletes: 698 March 2008 Updates: 854 Category: Standards Track 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. この文書はインターネット共同体のためのインターネット標準化作業中のプ ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状 態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD 1)の現在の版を参照してください。このメモの配布は無制限です。 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. 今日のインターネットは、初期のARPANETに遡る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. Introduction 1. はじめに 1.1. Requirement for a Standardized Text Stream Format 1.1. 標準化されたテキスト形式の要件 1.2. Terminology 1.2. 用語 2. Net-Unicode Definition 2. ネットユニコード定義 3. Normalization 3. 正規化 4. Versions of Unicode 4. ユニコードバージョン 5. Applicability and Stability of this Specification 5. この適用性と安定性 5.1. Use in IETF Applications Specifications 5.1. IETFアプリケーション仕様での使用 5.2. Unicode Versions and Applicability 5.2. ユニコード版数と適用性 6. Security Considerations 6. セキュリティの考察 7. Acknowledgments 7. 謝辞 Appendix A. History and Context 付録A. 歴史と状況 Appendix B. The ASCII NVT Definition 付録B. ASCII NVT定義 Appendix C. The Line-Ending Problem 付録C. 行末問題 Appendix D. A Note about Related Future Work 付録D. 関連する今後の仕事の記述 References 参考文献 Normative References 参照する参考文献 Informative References 有益な参考文献 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に基づき、そして、 プロトコルで「テキスト」という場合、ASCIIテキストを仮定したり、 明確にネットワーク仮想端末("NVT")や「ネットワーク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」 とはもう一致していません。幸い、単一の国際的に交換可能な文字コードで あるユニコード[Unicode] [ISO10646]に集束しているので、文字集合を指定 する方法を扱う必要がありません(例えば、アラビア語、キリル文字、ヒン ディー語、など、それぞれに規格がある、あるいは、フランス語とドイツ語 とスウェーデン語など文字が共通と考えられる言語を合わせた規格)。残念な がら、今はユニコードに基づく共通のテキスト交換フォーマットを定義すべ き時ですが、「ユニコードを使用する」は何十年も前の「ASCIIを使用 する」よりさらに多くのあいまいさがあります。 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から0x10fffの範囲 の整数に従ってそれぞれの文字を識別します。整数は転送のために少なくと も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]は65536未満の範囲のユニコード文字を16ビット 整数にコード化し、それ以上のコードポイントを32ビットにコード化す る「代用(サロゲージ)」機構を提供します。 o UTF-32 (also known as UCS-4) simply encodes each code point as a 32-bit integer. o (UCS-4と知られている)UTF-32は単に各コード・ポイントを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同様に、これらの形式のいずれでも、行末を示すのに異なる慣習 が使用されるかもしれません。その柔軟性がさらなる混乱を招くかもしれま せん、例えば、文書の索引(オフセット)参照は文字数かもしれません。 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文字集合方針 で議論されるその他の理由で、コード化に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. 選択が可能であれば、ここで指定されるテキストコード化でユニコードが使 われるべきです。この組み合わせは、「拡張ASCII」[RFC0698]の2バイ トコード化や言語毎や国毎に分類された文字コードより優先されます。 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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は [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. ネットワークユニコードのフォーマット(ネットユニコード)は以下の通り 定義されます。この定義の一部は、グローバルに適用される厳しい規則よ り、これを参照するプロトコル固有の特徴や規則での指導を提供するため、 故意に非公式です。 1. Characters MUST be encoded in UTF-8 as defined in [RFC3629]. 1. [RFC3629]で定義されるUTF-8で文字をコード化しなければなりません (MUST)。 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と知られて いる、キャリッジリターン(CR、U+000D)に続くラインフィード (LF、U+000A)で示さなければなりません(MUST)。LFが続かない限りCRは 現れないべきです(SHOULD NOT)。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. アスキー範囲の制御文字(U+0000からU+001FとU+007Fから U+009F)は、 避けられるべきです(SHOULD )。 空白(SP、U+0020)と、CRと、LFと、 フォームフィード(FF、U+000C)はこの原則の例外ですが、1番目を除い たすべての使用は、本書のほかの場所で議論する注意を必要とします。 いわゆる「C1制御」(U+009FからU+0080)は現れてはいけません、これら はアスキーにも現れません)。 FF should be used only with caution: it does not have a standard and universal interpretation and, in particular, if its use 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. 転送前にすべての文字列は、ユニコード正規化フォームNFC"に従って、 正規化されるべきです(SHOULD)(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. RFC 3629の6章に示されるように、バイト順序マーク("BOM")の印はこれ らのテキスト文字列の始めに現れてはなりません(MUST NOT)。 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. この仕様に準拠するシステムは、システムが依存するユニコードのバー ジョンで割り当てられていないコード・ポイントを含む文字列を伝えて はいけません(MUST NOT)。システムの使用するNFCのバージョンとユ ニコードのバージョンは整合しているに違いありません(MUST)。 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を使用するのは問題があります;付録Bの議論を見てください。 新しい制御文字のIND(U+0084)とNEL(「次の行」、U+0085)は様々な行末 の状況のあいまいさを除くのに使用されるかもしれませんが、こらの使用がイ ンターネットで確立おらず、多くのプロトコルがCRLFを必要とし、IND とNELが「C1制御」グループ(下記参照)内に含まれるため、これらを使 用してはなりません(MUST NOT)。同様の事は、阿多悪しい行や段落を区切るた めの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. NVT仕様は多くの追加条項を含みました、例えば、任意使用の多重印字文 字列を発生させるバックスペースキーと「単独CR」(CR NULと送信)です。 ユニコードで事前に決められている文字列、文字の組合せの利用可能性と、 様々な種類の慣習の増加、例えば強調(特殊文字の使用で強調するのではな く)を見ていると、これらの文字列は不要とすべきです。これらの文字列は できれば避けるべきです(SHOULD)。しかしながら、これらがNVTアプリケー ションで任意であり、この仕様がNVTを包含するので、これらを完全に禁 止はできません。これらの規則で最も重要なのは、LF(行末を示す)かNU Lが続かないCRは現れてはならない(MUST NOT)ということです。NUL(値 がゼロのオクテット、つまり[RFC5234]の記法で%x00)が、これを文字列の区 切りとするプログラミング言語で好ましくなく、この理由でCR NUL文 字列は避けるべきです(SHOULD)。 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: 複数のユニコード文字列が、本質的には同じテキストを表して、基本的に同 等な場合があります。これらはユニコード標準で「正規同等物」と呼ばれま す。例えば、以下の文字列は正規同等物です: U+2126 OHM SIGN U+03A9 GREEK CAPITAL LETTER OMEGA U+0061 LATIN SMALL LETTER A, U+0300 COMBINING GRAVE ACCENT U+00E0 LATIN SMALL LETTER A WITH GRAVE 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. このような場合、常に単一の一意な形式で表されるなら、文字列の比較はは るかに簡単になります。ユニコード協会NFC[NFC]と呼ばれる正規化を規定 しており、これは正規同等物を単一の一意な形式に変換するのに必要な対応 と仕組みを供給します。通常、この形式はその流儀で表すことができる任意 の文字列を事前構成された文字列にします。また、一意で明瞭になるように、 結合記号の順番を修正します。 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は実際に使われ ているものに近く、全ての状況で、文字が同等でないのに同等と考えてしま う副作用が小さく、通常、非ユニコードからの変換時に必要な作業は最小で す。 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]が選ばれたとき、ASCII の利点の1つは、標準が最初に発行されたとき、コード空間が完全に満杯で あったということでした。明らかに互換性を保って文字を追加したり、コー ドポイント割当を変える実用的な方法はありませんでした。 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章参照)、は最小限の変換、大規模なN FKCの使用、例えば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表は更新されるかもしれませんが、ユ ニコード協会はNFC文字列の安定性を保証しました。すなわち、文字列に 未割当の文字が含まれず、NFCで正規化されている場合、全ての将来のバー ジョンのユニコード標準でこれは正規化されています。ネットユニコード形 式の安定性は、テキストをネットユニコード形式に変換するずべての実装が 未割当の文字を許さなければ、保証されます。 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. ユニコードがこれらの仮定に反した方法で変えられた場合、つまり、RFC 3629で指定されたバイト順序を無効にしたり、上記のNFCの安定性を変え たて指定された場合、この仕様は適用されないでしょう。言いかえれば、こ の仕様はユニコード5版以降に適用しますが、UTF−8の定義や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に見えるが(文字集合で)確認できないものは、この仕様に 適合するUTF−8と扱うべきです(SHOULD)。 5. Applicability and Stability of this Specification 5. この適用性と安定性 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番目は、変更するには遅すぎていますが、ここで 指定された方法でそれらのプロトコルとコンテンツ種別を標準化させている ほうがよいだろうということです。2番目は以下です、元々のTelnetの設計 か、標準化か、共同利用か、何らかのコンテンツラベルを含まない文字列定 義かその他の取り決めに依存するいくつかのプロトコルがあります。Whois [RFC3912]はこの1つです。非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標準で必 要とされないことや[RFC3629]、現在のStringprep[RFC3454]に依存する標準 で必要とされていないことに注意する価値があります。 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]に限定され、ここで指定された正規が使用されると、インター ネット標準UTF−8[RFC3629]との完全な相互運用性は、ユニコード5.0 版以降に正規化定義とUTF−8自身が変更されないことに依存します。これ らの仮定はかなり安全に見えますが、それでも仮定です。ユニコードの最新版 や5.0版[Unicode]や特定の仮定や状況に基づく版数独立の広い概念を指定 したり、StringprepやNameprepのユニコード3.2[Unicode32]やなにか中間 的な版を指定したりするのに対し、異なるIETF標準での異なるユニコード の見解による明白な損失や上記のようなライブラリに依存するアプリケーショ ン実装により、版数の指定は実際にはほとんど無意味になります。 In theory, one can get around this problem in four ways: 理論上、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 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. 3. 異なる正常化規則に対して工夫します、例えば、ユニコードで以前に未 割当のコード・ポイントに割当られた文字がその文字だけやNFCに代 わる規則で正規化されないのを保障します。恐らくユニコードの将来の 版で文字を加える方法を制限する事で、このような規則が可能であるか どうか、またはある他の完全に安定した規則が考案できるかどうかは明 確ではありません。 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」という名でこの手順が議論されています。 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. これらを受信するプログラムは、受信データの正規化の仮定に関して、攻撃 の一部として非正規化形式を使用するのが可能かもしれないので、無効なU TF−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かアスキーNUL(全ビットが0のオクテット)でなければなら ないという事です。NULはあるプログラミング言語で文字列の終端に使わ れるため問題があり、警告がなければ無用心な罠になります。これは、上記 のLFが続くのを除くCRの使用を完全に避ける追加理由かもしれません。 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 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. ユニコード版数についての上記議論(4章と5.2章参照)はユニコードの将 来の版数に関すして、NFC正規化は適切に適用され、UTF−8は RFC 3629にしたがって正確に処理され転送されると、仮定をします、これらの仮 定のいずれかが正しくないなら、同等であると考えられる文字列の比較が一 致しない場合があります。強健なコードはそれらの可能性の準備をするべき です。 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. 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交換コード)、現在もあるASCII(情報交 換用米国標準コード)。アーパネットが「開放」プロジェクトで、EBCDICが特 定のハードウェアベンダに親密に繋がっていたので、過去のネットワーク作業 部会は、規格をASCIIにするべき事に同意しました。そのASCII形式 はは正確には「8ビットフィールド内の7ビットASCII」で、7ビット指 向ホスト(例えば、36ビットワードに5つの7ビット文字)、8ビット指向ホ スト(8ビット文字を使用する)と、9ビットフィールドに先頭2ビットがゼ ロの7ビットを指向するホスト(36ビットワードに4文字)の妥協でした。 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 characters, use of the high-order bit in octets was reserved for the transmission of control signaling information. より多くの標準化がTelnetプロトコルの最初の予備の記述で示されました [RFC0097]。このプロトコルの後継[RFC0137] [RFC0139]と、その後の本質的 に正式な定義[RFC0318]で、標準の抽象化、ネットワーク仮想端末(NVT) が確立しました。NVT文字コード規則(初めは「telnet ASCII」と呼ばれ、 後に「NVT ASCII」や、より何気なく「ネットワークASCII」と呼ばれた)は、 テキストの行末として改行に続く復帰(CRLF)を要件に含めました。いくつか の参加「ホスト」のオペレーティングシステムが元々一方を使用し、ある他 の少なくとも1つのホストが両方を使用し、一部がどちらも使いませんでし た(代わりに、カウンタ付きの可変長行や、特別な区切りや記号を好みました)、 そして他の文字に特別な規則を指定しました。また、NVT ASCIIが7ビット文 字に制限されたので、オクテットにおける上位ビットの使用は制御情報の伝達 のために予約されました。 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のコマンドストリームとASCII種別[RFC0542]、SMTP転 送のメッセージストリーム[RFC2821]、およびfinger[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 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. 1. 「定義されますが、必要でない」コード−BEL(U+0007)、BS(U+0008)、 HT(U+0009)、VT(U+000B)、およびFF(U+000C))−と未定義の制御コード ("C0")は、例外的な事情は必要でない限り、使用するべきではありませ ん(SHOULD NOT)。元々の「ネットワークプリンタ」の定義はもう一般に 使用されておらず、一般的な慣習は、そこで指定された形式から遠く離 れてしまったか、ユニコードでより良く扱える文字の使用は適切ではあ りません。リストのいくつかの文字は、驚くべき存在をするかもしれま せん、BSは現在の慣習でいまいな解釈になります(いくつかのシステムで は消去で、他では別です)、環境によってHTに関する幅は異なります、そ してVTと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 CR LF)、 現れるはずがありません(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の場合、テキストは消えるか完全に読み にくくなります;LFの場合、最悪の結果はおかしく見える表示です。テ キストの意図するタブ位置か幅情報を伝える標準手段がないので、明ら かに、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, 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. IAC文字(全て1からなるオクテット、つまり%xFF)が有効なUTF−8文字 列に現れることができないので、telnet IAC文字はUTF−8で問題ありませ ん。しかし、ほとんどは使用されませんが、telnetは他のコマンド開始文字列 を許し、そのオクテットのビット列は有効なUTF−8文字の一部であるかも しれません。これはUTF−8のあいまいさを全く引き起こしませんが、ユニ コードは図形文字(「分音符付きのラテン語の小文字の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). 行末問題の自然で発展したさらなる議論は、ユニコード標準[Unicode]の 5.8章にあり、追加の読書のために示されます。私たちが今日のインター ネットから開始できるなら、CR LFに代わって、排他的にLS(U+2028)を使用 するのがたぶん賢いのでしょう。しかしながら、CRLFを使う装置の存在と、 NVTとの下位互換と互換性を仮定するプロトコルの重要性により、それは 不可能で、「復帰改行機能」(”NLF”、参考文献の用語を参照)として CRLFを使用し続ける必要があります。 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. Telnet(または、SSH[RFC4251])のこのストリームの種類を指定するオプショ ンや、新しい「ユニコードテキスト」データ種別を許すFTP拡張[RFC0959] への考慮が必要です 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. [NFC] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", October 2006, <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. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007. Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0 [Unicode32] The Unicode Consortium, "The Unicode Standard, Version 3.0", 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/). Informative References 有益な参考文献 [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", 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. [ISO.646.1991] International Organization for Standardization, "Information technology - ISO 7-bit coded character set for information interchange", ISO Standard 646, 1991. [NamedSequences] The Unicode Consortium, "NamedSequences-4.1.0.txt", 2005, <http://www.unicode.org/Public/UNIDATA/ NamedSequences.txt>. [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. [RFC0097] Melvin, J. and R. Watson, "First Cut at a Proposed Telnet Protocol", RFC 97, February 1971. [RFC0137] O'Sullivan, T., "Telnet Protocol - a proposed document", RFC 137, April 1971. [RFC0139] O'Sullivan, T., "Discussion of Telnet Protocol", RFC 139, May 1971. [RFC0318] Postel, J., "Telnet Protocols", RFC 318, April 1972. [RFC0542] Neigus, N., "File Transfer Protocol", RFC 542, August 1973. [RFC0698] Mock, T., "Telnet extended ASCII option", RFC 698, July 1975. [RFC0742] Harrenstien, K., "NAME/FINGER Protocol", RFC 742, December 1977. [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC0954] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [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. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. Authors' Addresses 著者のアドレス John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Michael A. Padlipsky 8011 Stewart Ave. Los Angeles, CA 90045 USA Phone: +1 310-670-4288 EMail: the.map@alum.mit.edu Full Copyright Statement 完全著作権表示 Copyright (C) The IETF Trust (2008). 著作権(C)IETF信託(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は何の立場もとりません;この様な権利を 認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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. IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書 の実装者や利用者によってされた一般的な許可書や許可を得るためにされた 試みの結果は、http://www.ietf.org/iprにあるIETFオンラインIPR 貯蔵庫で得られます。 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求 めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。