[要約] RFC 2278は、IANA文字セットの登録手続きに関する規定であり、文字セットの登録手続きと管理を統一することを目的としています。このRFCは、文字セットの一貫性と互換性を確保するためのガイドラインを提供します。

Network Working Group                                           N. Freed
Request for Comments: 2278                                      Innosoft
BCP: 19                                                        J. Postel
Category: Best Current Practice                                      ISI
                                                            January 1998
        

IANA Charset Registration Procedures

IANA Charset登録手順

Status of this Memo

本文書の状態

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (1998). All Rights Reserved.

Copyright(C)The Internet Society(1998)。全著作権所有。

1. Abstract
1. 概要

MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. In particular, the general applicability and appropriateness of a given registered charset is a protocol issue, not a registration issue, and is not dealt with by this registration procedure.

MIME [RFC-2045、RFC-2046、RFC-2047、RFC-2184]および他のさまざまな最新のインターネットプロトコルは、多くの異なる文字セットを使用できます。つまり、さまざまな文字セットにラベルを付ける機能が不可欠です。この登録手順は、特定の名前を特定の文字セットに関連付け、MIMEテキストオブジェクトで特定の文字セットを使用できるかどうかを示すためにのみ存在します。特に、特定の登録済み文字セットの一般的な適用性と適切性はプロトコルの問題であり、登録の問題ではなく、この登録手順では処理されません。

2. Definitions and Notation
2. 定義と表記

The following sections define various terms used in this document.

次のセクションでは、このドキュメントで使用されるさまざまな用語を定義します。

2.1. Requirements Notation
2.1. 要件表記

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC-2119].

このドキュメントでは、大文字で表示される用語を使用することがあります。 「MUST」、「SHOULD」、「MUST NOT」、「SHOULD NOT」、および「MAY」という用語は、大文字で表記されている場合、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は[RFC-2119]にあります。

2.2. Character
2.2. キャラクター

A member of a set of elements used for the organisation, control, or representation of data.

データの編成、制御、または表現に使用される一連の要素のメンバー。

2.3. Charset
2.3. 文字コード

The term "charset" (see historical note below) is used here to refer to a method of converting a sequence of octets into a sequence of characters. This conversion may also optionally produce additional control information such as directionality indicators.

「charset」という用語(以下の履歴ノートを参照)は、オクテットのシーケンスを文字のシーケンスに変換する方法を指すためにここで使用されます。この変換では、オプションで方向性インジケータなどの追加の制御情報を生成することもできます。

Note that unconditional and unambiguous conversion in the other direction is not required, in that not all characters may be representable by a given charset and a charset may provide more than one sequence of octets to represent a particular sequence of characters.

すべての文字が特定の文字セットで表現できるわけではなく、文字セットは特定の文字シーケンスを表すために複数のオクテットシーケンスを提供する場合があるため、無条件で明確な逆方向の変換は必要ありません。

This definition is intended to allow charsets to be defined in a variety of different ways, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO 2022's techniques, to be used as charsets. However, the definition associated with a charset name must fully specify the mapping to be performed. In particular, use of external profiling information to determine the exact mapping is not permitted.

この定義は、US-ASCIIなどの単純な単一テーブルマッピングからISO 2022の手法を使用するような複雑なテーブルスイッチングメソッドまで、文字セットをさまざまな方法で定義できるようにすることを目的としています。ただし、文字セット名に関連付けられた定義では、実行するマッピングを完全に指定する必要があります。特に、正確なマッピングを判別するための外部プロファイリング情報の使用は許可されていません。

HISTORICAL NOTE: The term "character set" was originally used in MIME to describe such straightforward schemes as US-ASCII and ISO-8859-1 which consist of a small set of characters and a simple one-to-one mapping from single octets to single characters. Multi-octet character encoding schemes and switching techniques make the situation much more complex. As such, the definition of this term was revised to emphasize both the conversion aspect of the process, and the term itself has been changed to "charset" to emphasize that it is not, after all, just a set of characters. A discussion of these issues as well as specification of standard terminology for use in the IETF appears in RFC 2130.

歴史的注記:「文字セット」という用語は元々、MIMEでUS-ASCIIやISO-8859-1などの簡単なスキームを説明するために使用されていました。これは、文字の小さなセットと、単一のオクテットから単一の文字。マルチオクテットの文字エンコーディングスキームとスイッチング技術により、状況はさらに複雑になります。そのため、この用語の定義は、プロセスの変換の側面の両方を強調するように改訂され、用語自体は結局のところ、単なる文字のセットではないことを強調するために「charset」に変更されました。これらの問題についての議論、およびIETFで使用するための標準的な用語の仕様は、RFC 2130に記載されています。

2.4. Coded Character Set
2.4. コード化文字セット

A Coded Character Set (CCS) is a mapping from a set of abstract characters to a set of integers. Examples of coded character sets are ISO 10646 [ISO-10646], US-ASCII [US-ASCII], and the ISO-8859 series [ISO-8859].

コード化文字セット(CCS)は、一連の抽象文字から一連の整数へのマッピングです。コード化文字セットの例は、ISO 10646 [ISO-10646]、US-ASCII [US-ASCII]、およびISO-8859シリーズ[ISO-8859]です。

2.5. Character Encoding Scheme
2.5. 文字コード体系

A Character Encoding Scheme (CES) is a mapping from a Coded Character Set or several coded character sets to a set of octets. A given CES is typically associated with a single CCS; for example, UTF-8 applies only to ISO 10646.

文字エンコーディング方式(CES)は、コード化文字セットまたはいくつかのコード化文字セットからオクテットのセットへのマッピングです。特定のCESは通常、単一のCCSに関連付けられています。たとえば、UTF-8はISO 10646にのみ適用されます。

3. Registration Requirements
3. 登録要件

Registered charsets are expected to conform to a number of requirements as described below.

登録された文字セットは、以下に説明するように、いくつかの要件に準拠している必要があります。

3.1. Required Characteristics
3.1. 必要な特性

Registered charsets MUST conform to the definition of a "charset" given above. In addition, charsets intended for use in MIME content types under the "text" top-level type must conform to the restrictions on that type described in RFC 2045. All registered charsets MUST note whether or not they are suitable for use in MIME.

登録された文字セットは、上記の「文字セット」の定義に準拠する必要があります。さらに、「テキスト」トップレベルタイプのMIMEコンテンツタイプでの使用を目的とした文字セットは、RFC 2045で説明されているそのタイプの制限に準拠する必要があります。登録されているすべての文字セットは、MIMEでの使用に適しているかどうかを記録する必要があります。

All charsets which are constructed as a composition of a CCS and a CES MUST either include the CCS and CES they are based on in their registration or else cite a definition of their CCS and CES that appears elsewhere.

CCSとCESの構成として構築されるすべての文字セットは、それらの登録に基づいたCCSとCESを含めるか、他の場所に表示されるCCSとCESの定義を引用する必要があります。

All registered charsets MUST be specified in a stable, openly available specification. Registration of charsets whose specifications aren't stable and openly available is forbidden.

登録されているすべての文字セットは、公開された安定した仕様で指定する必要があります。仕様が安定しておらず、公開されていない文字セットの登録は禁止されています。

3.2. New Charsets
3.2. 新しい文字セット

This registration mechanism is not intended to be a vehicle for the definition of entirely new charsets. This is due to the fact that the registration process does NOT contain adequate review mechanisims for such undertakings.

この登録メカニズムは、まったく新しい文字セットを定義する手段となることを意図したものではありません。これは、登録プロセスにそのような事業の適切な審査メカニズムが含まれていないためです。

As such, only charsets defined by other processes and standards bodies, or specific profiles of such charsets, are eligible for registration.

そのため、他のプロセスや標準化団体によって定義された文字セット、またはそのような文字セットの特定のプロファイルのみが登録の対象になります。

3.3. Naming Requirements
3.3. 命名要件

One or more names MUST be assigned to all registered charsets. Multiple names for the same charset are permitted, but if multiple names are assigned a single primary name for the charset MUST be identified. All other names are considered to be aliases for the primary name and use of the primary name is preferred over use of any of the aliases.

登録されているすべての文字セットに1つ以上の名前を割り当てる必要があります。同じ文字セットの複数の名前が許可されますが、複数の名前が割り当てられている場合、文字セットの単一のプライマリ名を識別する必要があります。他のすべての名前はプライマリ名のエイリアスと見なされ、エイリアスの使用よりもプライマリ名の使用が優先されます。

Each assigned name MUST uniquely identify a single charset. All charset names MUST be suitable for use as the value of a MIME content type charset parameter and hence MUST conform to MIME parameter value syntax. This applies even if the specific charset being registered is not suitable for use with the "text" media type.

割り当てられた名前はそれぞれ、単一の文字セットを一意に識別しなければなりません。すべての文字セット名は、MIMEコンテンツタイプの文字セットパラメータの値としての使用に適している必要があり、したがってMIMEパラメータ値の構文に準拠している必要があります。これは、登録されている特定の文字セットが「テキスト」メディアタイプでの使用に適していない場合にも当てはまります。

Finally, charsets being registered for use with the "text" media type MUST have a primary name that conforms to the more restrictive syntax of the charset field in MIME encoded-words [RFC-2047, RFC-2184] and MIME extended parameter values [RFC-2184]. A combined ABNF definition for such names is as follows:

最後に、「テキスト」メディアタイプで使用するために登録される文字セットは、MIMEエンコードされた単語[RFC-2047、RFC-2184]およびMIME拡張パラメータ値[ RFC-2184]。そのような名前の結合されたABNF定義は次のとおりです。

   mime-charset = 1*<Any CHAR except SPACE, CTLs, and cspecials>
        
   cspecials    = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
                  <"> / "/" / "[" / "]" / "?" / "." / "=" / "*"
        

CHAR = <any ASCII character> ; ( 0-177, 0.-127.) SPACE = <ASCII SP, space> ; ( 40, 32.) CTL = <any ASCII control ; ( 0- 37, 0.- 31.) character and DEL> ; ( 177, 127.)

CHAR = <任意のASCII文字>; (0-177、0.-127。)スペース= <ASCII SP、スペース>; (40、32。)CTL = <任意のASCIIコントロール; (0- 37、0.- 31.)文字とDEL>; (177、127)。

3.4. Functionality Requirement
3.4. 機能要件

Charsets must function as actual charsets: Registration of things that are better thought of as a transfer encoding, as a media type, or as a collection of separate entities of another type, is not allowed. For example, although HTML could theoretically be thought of as a charset, it is really better thought of as a media type and as such it cannot be registered as a charset.

文字セットは、実際の文字セットとして機能する必要があります。転送エンコーディング、メディアタイプ、または別のタイプの個別のエンティティのコレクションとして考えられるものの登録は許可されていません。たとえば、HTMLは理論的には文字セットと考えることもできますが、メディアタイプとして考える方がよいため、文字セットとして登録することはできません。

3.5. Usage and Implementation Requirements
3.5. 使用と実装の要件

Use of a large number of charsets in a given protocol may hamper interoperability. However, the use of a large number of undocumented and/or unlabelled charsets hampers interoperability even more.

特定のプロトコルで多数の文字セットを使用すると、相互運用性が妨げられる可能性があります。ただし、ドキュメント化されていない、またはラベル付けされていない多数の文字セットを使用すると、相互運用性がさらに低下します。

A charset should therefore be registered ONLY if it adds significant functionality that is valuable to a large community, OR if it documents existing practice in a large community. Note that charsets registered for the second reason should be explicitly marked as being of limited or specialized use and should only be used in Internet messages with prior bilateral agreement.

したがって、大規模なコミュニティに役立つ重要な機能を追加する場合、または大規模なコミュニティでの既存の慣行を文書化する場合にのみ、文字セットを登録する必要があります。 2番目の理由で登録された文字セットは、限定的または特殊な用途であることを明示的にマークする必要があり、事前の双方向の合意があるインターネットメッセージでのみ使用する必要があることに注意してください。

3.6. Publication Requirements
3.6. 出版要件

Charset registrations can be published in RFCs, however, RFC publication is not required to register a new charset.

文字セット登録はRFCで公開できますが、新しい文字セットを登録するためにRFC公開は必要ありません。

The registration of a charset does not imply endorsement, approval, or recommendation by the IANA, IESG, or IETF, or even certification that the specification is adequate. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, charsets that have proven particularly useful in those contexts.

文字セットの登録は、IANA、IESG、またはIETFによる承認、承認、推奨、または仕様が適切であることの証明を意味するものではありません。特定のアプリケーションの適用性に関する声明は、これらのコンテキストで特に有用であることが証明されている文字セットの実装とサポートを推奨するように随時公開されることが予想されます。

3.7. MIBenum Requirements
3.7. MIBenumの要件

Each registered charset MUST also be assigned a unique enumerated integer value. These "MIBenum" values are defined by and used in the Printer MIB [RFC-1759].

登録された各文字セットには、一意の列挙整数値も割り当てる必要があります。これらの「MIBenum」値は、プリンターMIB [RFC-1759]によって定義され、使用されます。

A MIBenum value for each charset will be assigned by IANA at the time of registration.

各文字セットのMIBenum値は、登録時にIANAによって割り当てられます。

4. Registration Procedure
4. 登録手続き

The following procedure has been implemented by the IANA for review and approval of new charsets. This is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay.

次の手順は、新しい文字セットの確認と承認のためにIANAによって実装されています。これは正式な標準プロセスではなく、過度の時間遅延なしにコミュニティのコメントと健全性チェックを可能にすることを目的とした管理手順です。

4.1. Present the Charset to the Community
4.1. コミュニティにCharsetを提示する

Send the proposed charset registration to the "ietf-charsets@iana.org" mailing list. This mailing list has been established for the sole purpose of reviewing proposed charset registrations. Proposed charsets are not formally registered and must not be used; the "x-" prefix specified in RFC 2045 can be used until registration is complete.

提案された文字セット登録を「ietf-charsets@iana.org」メーリングリストに送信します。このメーリングリストは、提案された文字セット登録をレビューすることのみを目的として確立されました。提案された文字セットは正式に登録されておらず、使用してはなりません。 RFC 2045で指定されている「x-」プレフィックスは、登録が完了するまで使用できます。

The intent of the public posting is to solicit comments and feedback on the definition of the charset and the name chosen for it over a two week period.

公開投稿の目的は、2週間にわたって文字セットの定義とその文字セットに選択された名前に関するコメントとフィードバックを求めることです。

4.2. Charset Reviewer
4.2. Charsetレビューア

When the two week period has passed and the registration proposer is convinced that consensus has been achieved, the registration application should be submitted to IANA and the charset reviewer. The charset reviewer, who is appointed by the IETF Applications Area Director(s), either approves the request for registration or rejects it. Rejection may occur because of significant objections raised on the list or objections raised externally. If the charset reviewer considers the registration sufficiently important and controversial, a last call for comments may be issued to the full IETF. The charset reviewer may also recommend standards track processing (before or after registration) when that appears appropriate and the level of specification of the charset is adequate.

2週間が経過し、登録提案者が合意に達したと確信したら、登録申請書をIANAおよび文字セットレビューアに提出する必要があります。 IETFアプリケーションエリアディレクターによって任命された文字セットレビューアは、登録の要求を承認するか、拒否します。リストで発生した重大な異論や外部からの異議が原因で、拒否が発生する可能性があります。文字セットレビューアが登録を十分に重要で論争の的と見なす場合、コメントの最後の呼び出しが完全なIETFに発行される場合があります。文字セットのレビューアは、標準トラックの処理(登録前または後)が適切であると思われ、文字セットの仕様のレベルが適切である場合にも推奨する場合があります。

Decisions made by the reviewer must be posted to the ietf-charsets mailing list within 14 days. Decisions made by the reviewer may be appealed to the IESG.

レビュー担当者による決定は、14日以内にietf-charsetsメーリングリストに投稿する必要があります。レビューアによる決定は、IESGに上訴される場合があります。

4.3. IANA Registration
4.3. IANA登録

Provided that the charset registration has either passed review or has been successfully appealed to the IESG, the IANA will register the charset, assign a MIBenum value, and make its registration available to the community.

文字セットの登録がレビューに合格したか、またはIESGに上訴された場合、IANAは文字セットを登録し、MIBenum値を割り当て、その登録をコミュニティで利用できるようにします。

5. Location of Registered Charset List
5. 登録された文字セットリストの場所

Charset registrations will be posted in the anonymous FTP file "ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets" and all registered charsets will be listed in the periodically issued "Assigned Numbers" RFC [currently RFC-1700]. The description of the charset may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-2223]).

文字セットの登録は、匿名FTPファイル「ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets」に投稿され、登録されているすべての文字セットは、定期的に発行される「Assigned Numbers」RFCにリストされます。現在RFC-1700]。文字セットの説明は、「rfc-editor@isi.edu」に送信することにより、情報RFCとして公開することもできます(RFC作成者[RFC-2223]への指示に従ってください)。

6. Registration Template
6. 登録テンプレート

To: ietf-charsets@iana.org Subject: Registration of new charset

宛先:ietf-charsets@iana.org件名:新しい文字セットの登録

Charset name(s):

文字セット名:

(All names must be suitable for use as the value of a MIME content-type parameter.)

(すべての名前は、MIME content-typeパラメーターの値として使用するのに適している必要があります。)

Published specification(s):

公開された仕様:

(A specification for the charset must be openly available that accurately describes what is being registered. If a charset is defined as a composition of a CCS and a CES then these defintions must either be included or referenced.)

(登録されているものを正確に記述する文字セットの仕様が公開されている必要があります。文字セットがCCSとCESの構成として定義されている場合、これらの定義を含めるか参照する必要があります。)

Person & email address to contact for further information:

詳細について連絡する人とメールアドレス:

7. Security Considerations
7. セキュリティに関する考慮事項

This registration procedure is not known to raise any sort of security considerations that are appreciably different from those already existing in the protocols that employ registered charsets.

この登録手順では、登録された文字セットを使用するプロトコルにすでに存在するものとはかなり異なるセキュリティ上の考慮事項を提起することは知られていません。

8. References
8. 参考文献

[ISO-2022] International Standard -- Information Processing -- Character Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th ed.

[ISO-2022]国際規格-情報処理-文字コード構造と拡張技術、ISO / IEC 2022:1994、第4版。

[ISO-8859] International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed. - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed. - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed. - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed. - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st ed. - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed. - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed. - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed. - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st ed. International Standard -- Information Technology -- 8-bit Single-Byte Coded Graphic Character Sets - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1st ed.

[ISO-8859]国際規格-情報処理-8ビットシングルバイトコード化グラフィック文字セット-パート1:ラテンアルファベットNo. 1、ISO 8859-1:1987、第1版。 -パート2:ラテンアルファベットNo. 2、ISO 8859-2:1987、第1版。 -パート3:ラテンアルファベットNo. 3、ISO 8859-3:1988、第1版。 -パート4:ラテンアルファベットNo. 4、ISO 8859-4:1988、第1版。 -パート5:ラテン語/キリル文字のアルファベット、ISO 8859-5:1988、第1版。 -パート6:ラテン語/アラビア語のアルファベット、ISO 8859-6:1987、第1版。 -パート7:ラテン語/ギリシャ語のアルファベット、ISO 8859-7:1987、第1版。 -パート8:ラテン語/ヘブライ語のアルファベット、ISO 8859-8:1988、第1版。 -パート9:ラテンアルファベットNo. 5、ISO / IEC 8859-9:1989、第1版。国際標準-情報技術-8ビットシングルバイトコード化グラフィック文字セット-パート10:ラテンアルファベットNo. 6、ISO / IEC 8859-10:1992、第1版。

[ISO-10646] ISO/IEC 10646-1:1993(E), "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", JTC1/SC2, 1993.

[ISO-10646] ISO / IEC 10646-1:1993(E)、「Information technology-Universal Multiple-Octet Coded Character Set(UCS)-Part 1:Architecture and Basic Multilingual Plane」、JTC1 / SC2、1993。

[RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.

[RFC-2048] Freed、N.、Klensin、J。、およびJ. Postel、「Multipurpose Internet Mail Extensions(MIME)Part Four:Registration Procedures」、RFC 2048、1996年11月。

[RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

[RFC-1700] Reynolds、J。、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。

[RFC-1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.

[RFC-1759] Smith、R.、Wright、F.、Hastings、T.、Zilles、S。、およびJ. Gyllenskog、「Printer MIB」、RFC 1759、1995年3月。

[RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC-2045] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions(MIME)Part One:Format of Internet Message Bodies」、RFC 2045、1996年11月。

[RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC-2046] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions(MIME)Part Two:Media Types」、RFC 2046、1996年11月。

[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-Ascii Text in Internet Message Headers", RFC 2047, November 1996.

[RFC-2047]ムーアK.、「多目的インターネットメール拡張(MIME)パート3:インターネットメッセージヘッダー内の非ASCIIテキストの表現」、RFC 2047、1996年11月。

[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC-2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "Report from the IAB Character Set Workshop", RFC 2130, April 1997.

[RFC-2130]ウィダー、C。、プレストン、C。、サイモンセン、K。、アルベストランド、H。、アトキンソン、R。、クリスピン、M。、およびP.スヴァンバーグ、「IAB Character Set Workshopからのレポート」、 RFC 2130、1997年4月。

[RFC-2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.

[RFC-2184] Freed、N。、およびK. Moore、「MIMEパラメータ値とエンコードされたワード拡張:文字セット、言語、および継続」、RFC 2184、1997年8月。

[US-ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[US-ASCII]コード化文字セット-情報交換のための7ビットのアメリカ標準コード、ANSI X3.4-1986。

9. Authors' Addresses
9. 著者のアドレス

Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA

Ned Freed Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA

   Phone: +1 626 919 3600
   Fax:   +1 626 919 3614
   EMail: ned.freed@innosoft.com
        

Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 USA

Jon Postel USC / Information Sciences Institute 4676 Admiralty Wayマリナデルレイ、カリフォルニア州90292アメリカ

   Phone: +1 310 822 1511
   Fax:   +1 310 823 6714
   EMail: Postel@ISI.EDU
        

Full Copyright Statement

完全な著作権表示

Copyright (C) The Internet Society (1998). All Rights Reserved.

Copyright(C)The Internet Society(1998)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。