RFC2278 日本語訳
2278 IANA Charset Registration Procedures. N. Freed, J. Postel. January 1998. (Format: TXT=18881 bytes) (Obsoleted by RFC2978) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Freed
Request for Comments: 2278 Innosoft
BCP: 19 J. Postel
Category: Best Current Practice ISI
January 1998
ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2278Innosoft BCP: 19J.ポステルカテゴリ: 最も良い現在の練習ISI1998年1月
IANA Charset
Registration Procedures
IANA Charset登録手順
Status of this Memo
この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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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]と他の様々な現代のインターネットプロトコルは多くの異なったcharsetsを使用できます。 これは、異なったcharsetsをラベルする能力が不可欠であることを順番に意味します。 この登録手順は、唯一与えられたcharsetの種名か名前を関連づけて、MIMEテキストオブジェクトで与えられたcharsetを使用できるかどうかしるしを与えるために存在しています。 与えられた登録されたcharsetの一般的な適用性と適切さは、特に、登録問題ではなく、プロトコル問題であり、この登録手順で対処されていません。
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"、「必須NOT」である、「」 「5月」は大文字で書かれるように見えて、それらは、この仕様の特定の要件を示すのに使用されるべきです。 これらの用語の意味の議論は[RFC-2119]に現れます。
Freed & Postel Best Current Practice [Page 1] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[1ページ]RFC2278Charset登録1998年1月
2.2. Character
2.2. キャラクター
A member of a set of elements used for the organisation, control, or representation of data.
機構に使用される1セットの要素、コントロール、またはデータの表現のメンバー。
2.3. Charset
2.3. Charset
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.
もう片方の方向への無条件の、そして、明白な変換は必要でないことに注意してください、すべてのキャラクタがどんな与えられたcharsetで「表-可能」であるかもしれないというわけではなく、charsetがキャラクタの特定の系列を表すために八重奏の1つ以上の系列を提供するかもしれないので。
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.
この定義が、charsetsがさまざまな異なった方法で定義されるのを許容することを意図します、charsetsとして使用されるのにISO2022のテクニックを使用するものなどの複雑なテーブル切り換え方法への米国-ASCIIなどの簡単な単一のテーブルマッピングから。 しかしながら、charset名に関連している定義は、実行されるためにマッピングを完全に指定しなければなりません。 特に、正確なマッピングを決定する外部のプロフィール情報の使用は受入れられません。
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.
歴史的な注意: 「文字の組」という用語は、元々、キャラクタを選抜するためにただ一つの八重奏から小さいキャラクタと簡単な1〜1つのマッピングの米国-ASCIIと成るISO-8859-1としてそのような簡単な計画を記述するのにMIMEに使用されました。 計画をコード化するマルチ八重奏キャラクタと切り換えのテクニックで、状況ははるかに複雑になります。 そういうものとして、今期の定義は改訂されて、過程の変換局面と用語自体の両方を強調するのがそれが結局ちょうど1セットのキャラクタでないと強調するために"charset"に変わったということでした。 IETFにおける使用のための標準の用語の仕様と同様にこれらの問題の議論はRFC2130に現れます。
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].
Coded文字コード(CCS)は1セットの抽象的なキャラクタから1セットの整数までマッピングです。 コード化文字集合に関する例は、ISO10646[ISO-10646]と、米国-ASCII[米国-ASCII]と、ISO-8859シリーズ[ISO-8859]です。
Freed & Postel Best Current Practice [Page 2] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[2ページ]RFC2278Charset登録1998年1月
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.
Coded文字コードかいくつかのコード化文字集合から1セットの八重奏までキャラクターEncoding Scheme(CES)はマッピングです。 与えられたCESは独身のCCSに通常関連しています。 例えば、UTF-8はISO10646だけに適用します。
3. Registration Requirements
3. 登録要件
Registered charsets are expected to conform to a number of requirements as described below.
登録されたcharsetsが以下で説明されるように多くの要件に従うと予想されます。
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.
登録されたcharsetsは上に与えられた"charset"の定義に一致しなければなりません。 さらに、MIME内容タイプにおける使用のために「テキスト」トップレベルタイプの下で意図するcharsetsはRFC2045で説明されたそのタイプにおける制限に一致しなければなりません。 すべての登録されたcharsetsが、それらが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 MUSTが彼らの登録に彼らに基づいているCCSとCESを含んでいて組み立てられるすべてのcharsetsがほかの場所に現れる彼らの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.
安定して、オープンに利用可能な仕様ですべての登録されたcharsetsを指定しなければなりません。 仕様が安定していてオープンに利用可能でないcharsetsの登録は禁じられます。
3.2. New Charsets
3.2. 新しいCharsets
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.
この登録メカニズムは完全に新しいcharsetsの定義のための手段であることを意図しません。 これは登録手続がそのような仕事のための適切なレビューmechanisimsを含んでいないという事実のためです。
As such, only charsets defined by other processes and standards bodies, or specific profiles of such charsets, are eligible for registration.
登録に、他の過程と標準化団体によって定義されたcharsets、またはそのようなcharsetsの特定のプロフィールだけが適任です。
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.
すべての登録されたcharsetsに1つ以上の名前を割り当てなければなりません。 同じcharsetにおいて複数の名前が受入れられますが、複数の名前が割り当てられるなら、charsetに、ただ一つの第一の名前を特定しなければなりません。 他のすべての名前が第一の名前のための別名であると考えられて、第一の名前の使用は別名のどれかの使用より好ましいです。
Freed & Postel Best Current Practice [Page 3] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[3ページ]RFC2278Charset登録1998年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.
それぞれの割り当てられた名前は唯一単一のcharsetを特定しなければなりません。 すべてのcharset名が、MIME内容タイプcharsetパラメタの値として使用に適しなければならなくて、したがって、MIMEパラメタ値の構文に従わなければなりません。 「テキスト」メディアタイプにおいて、登録される特定のcharsetが使用に適しないでも、これは適用されます。
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:
最終的に、使用のために「テキスト」メディアタイプに登録されるcharsetsはMIMEのコード化された単語[RFC-2047、RFC-2184]とMIMEの拡張パラメタ値[RFC-2184]におけるcharset分野の、より制限している構文に従う第一の名前を持たなければなりません。 そのような名前のための結合したABNF定義は以下の通りです:
mime-charset = 1*<Any CHAR except SPACE, CTLs, and cspecials>
SPACE、CTLs、およびcspecials>以外の1*<パントマイム-charset=Any CHAR
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.) SPACEは<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.
Charsetsは実際のcharsetsとして機能しなければなりません: メディアタイプとして、または、別のタイプの別々の実体の収集としてコード化される転送として考えられるほうがよいものの登録は許されていません。 例えば、charsetとして理論的にHTMLを考えることができましたが、charsetとしてメディアタイプとそういうものとしてそれを示すことができないので、それは本当により良いです考えられた。
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.
与えられたプロトコルにおける多くのcharsetsの使用は相互運用性を妨げるかもしれません。 しかしながら、正式書類のないことの多くの使用、そして/または、unlabelled charsetsは相互運用性をさらにも妨げます。
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.
したがって、大きい共同体に貴重な重要な機能性を加えるだけであるなら、charsetは登録されるべきであり、ORはそれであるなら大きい共同体の既存の習慣を記録します。 2番目の理由で登録されたcharsetsが制限されたか専門化している使用の存在として明らかにマークされるべきであり、インターネットメッセージで先の二国間条約で使用されるだけであるべきであることに注意してください。
3.6. Publication Requirements
3.6. 公表要件
Charset registrations can be published in RFCs, however, RFC publication is not required to register a new charset.
RFCsでCharset登録証明書を発行できて、しかしながら、RFC公表は、新しいcharsetを登録するのに必要ではありません。
Freed & Postel Best Current Practice [Page 4] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[4ページ]RFC2278Charset登録1998年1月
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.
charsetの登録は仕様が適切であるというIANA、IESG、IETF、または証明さえによる裏書き、承認、または推薦を含意しません。 それが予想される、特定用途のための声明が時々発行されて、それが実現を推薦するということであるために望んでいるその適用性、およびサポート、それらの文脈で特に役に立つと判明したcharsets。
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].
また、ユニークな列挙された整数値をそれぞれの登録されたcharsetに割り当てなければなりません。 これらの"MIBenum"値は[RFC-1759]を、定義されて、Printer MIBで使用されます。
A MIBenum value for each charset will be assigned by IANA at the time of registration.
各charsetのための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.
以下の手順は新しいcharsetsのレビューと承認のために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 」メーリングリストに提案されたcharset登録を送ってください。 このメーリングリストは提案されたcharset登録証明書を見直す唯一の目的のために確立されました。 提案されたcharsetsを正式に登録しないで、使用してはいけません。 登録が完全になるまで、RFC2045で指定された「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週間の期間にわたってcharsetの定義と選ぶという名前のコメントとフィードバックに請求することです。
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
2週間の期間が経過して、登録提案者がそのコンセンサスが達成されたと確信しているとき、IANAとcharset評論家に登録申請を提出するべきです。 charset評論家(IETF Applications Areaディレクターによって任命される)は、登録を求める要求を承認するか、またはそれを拒絶します。 拒絶はリストで上げられた重要な反論か外部的に上げられた反論で起こるかもしれません。 charset評論家が、登録が十分重要であって、論議を呼ぶと考えるなら、コメントのための最後の呼び出しは完全なIETFに発行されるかもしれません。 charset
Freed & Postel Best Current Practice [Page 5] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[5ページ]RFC2278Charset登録1998年1月
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.
また、それが適切に見えて、charsetの仕様のレベルが適切であるときに、評論家は標準化過程処理を推薦するかもしれません(登録の前または後に)。
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.
charset登録がレビューに合格するか、または首尾よくIESGに上告されたならば、IANAはcharsetを登録して、MIBenum値を割り当てて、登録を共同体に利用可能にするでしょう。
5. Location of Registered Charset List
5. 登録されたCharsetリストの位置
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]).
Charset登録証明書は" ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets "という公開FTPファイルに掲示されるでしょう、そして、すべての登録されたcharsetsが定期的に発行された「規定番号」RFC[現在のRFC-1700]に記載されるでしょう。 また、charsetの記述は、Informational RFCとして" rfc-editor@isi.edu "にそれを送ることによって、発行されるかもしれません(RFC作者[RFC-2223]に指示に従ってください)。
6. Registration Template
6. 登録テンプレート
To: ietf-charsets@iana.org Subject: Registration of new charset
To: ietf-charsets@iana.org Subject: 新しいcharsetの登録
Charset name(s):
Charsetは(s)を命名します:
(All names must be suitable for use as the value of a MIME content- type parameter.)
(すべての名前がMIME内容型引数の値として使用に適しているに違いありません。)
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.)
(charsetがオープンにそんなに正確に利用可能でなければならないので、仕様は登録されていることについて説明します。 charsetがCCSとCESの構成と定義されるなら、これらのdefintionsに含まれなければならないか、または参照をつけなければなりません。)
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Freed & Postel Best Current Practice [Page 6] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[6ページ]RFC2278Charset登録1998年1月
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.
この登録手順がどんな種類の登録されたcharsetsを使うプロトコルで既に存在するものとかなり異なったセキュリティ問題も提起するのが知られません。
8. References
8. 参照
[ISO-2022]
International Standard -- Information Processing -- Character
Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th
ed.
[ISO-2022]国際規格--情報Processing--キャラクターCode StructureとExtension Techniques、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、ISO8859-1: 1987、最初の教育。 - 第2部: ローマ字No.2、ISO8859-2: 1987、最初の教育。 - パート3: ローマ字No.3、ISO8859-3: 1988、最初の教育。 - パート4: ローマ字No.4、ISO8859-4: 1988、最初の教育。 - パート5: ラテン/キリル文字、ISO8859-5: 1988、最初の教育。 - パート6: ラテン語の、または、アラビアのAlphabet、ISO8859-6: 1987、最初の教育。 - パート7: ラテン語の、または、ギリシアのAlphabet、ISO8859-7: 1987、最初の教育。 - パート8: ラテン語の、または、ヘブライのAlphabet、ISO8859-8: 1988、最初の教育。 - パート9: ローマ字No.5、ISO/IEC8859-9: 1989、最初の教育。 国際規格--情報技術--8ビットの単一のバイトコード化された図形文字セット--パート10: ローマ字No.6、ISO/IEC8859-10: 1992、最初の教育。
[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/IEC10646-1: 1993(E)、「情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部:、」 「構造的、そして、基本的な多言語飛行機」、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]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
[RFC-1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC-1700] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
Freed & Postel Best Current Practice [Page 7] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[7ページ]RFC2278Charset登録1998年1月
[RFC-1759]
Smith, R., Wright, F., Hastings, T., Zilles, S., and J.
Gyllenskog, "Printer MIB", RFC 1759, March 1995.
1995年3月の[RFC-1759]スミスとR.とライトとF.とヘイスティングズとT.とZilles、S.とJ.Gyllenskog、「プリンタMIB」RFC1759。
[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]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC-2046]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[RFC-2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、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を分けます」。 「インターネットメッセージヘッダーの非アスキーテキストの表現」、RFC2047、1996年11月。
[RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.とAlvestrandとH.とアトキンソンとR.とクリスピン、M.とP.スバンベルク、「IAB文字コードワークショップからのレポート」RFC2130(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]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2184、8月1997日
[US-ASCII]
Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
Freed & Postel Best Current Practice [Page 8] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[8ページ]RFC2278Charset登録1998年1月
9. Authors' Addresses
9. 作者のアドレス
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
ネッド解放されたInnosoft国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。
Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: ned.freed@innosoft.com
以下に電話をしてください。 +1 626 919、3600Fax: +1 3614年の626 919メール: ned.freed@innosoft.com
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 USA
ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292米国
Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: Postel@ISI.EDU
以下に電話をしてください。 +1 310 822、1511Fax: +1 6714年の310 823メール: Postel@ISI.EDU
Freed & Postel Best Current Practice [Page 9] RFC 2278 Charset Registration January 1998
最も良い現在の解放されるのとポステルの練習[9ページ]RFC2278Charset登録1998年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Freed & Postel Best Current Practice [Page 10]
最も良い現在の解放されるのとポステルのPractice[10ページ]
一覧
スポンサーリンク
