RFC2978 日本語訳

Network Working Group                                         N. Freed
Request for Comments: 2978                                    Innosoft
BCP: 19                                                      J. Postel
Obsoletes: 2278                                                    ISI
Category: Best Current Practice                           October 2000

ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2978Innosoft BCP: 19 J.ポステルは以下を時代遅れにします。 2278年のISIカテゴリ: 最も良い現在の練習2000年10月

                  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 (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   Multipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046,
   RFC-2047, RFC-2184) and various other Internet protocols are capable
   of using many different charsets.  This in turn means that the
   ability to label different charsets is essential.

マルチパーパスインターネットメールエクステンション(MIME)(RFC-2045、RFC-2046、RFC-2047、RFC-2184)と他の様々なインターネットプロトコルは多くの異なったcharsetsを使用できます。 これは、異なったcharsetsをラベルする能力が不可欠であることを順番に意味します。

   Note: The charset 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 to a particular application is a protocol
   issue, not a registration issue, and is not dealt with by this
   registration procedure.

以下に注意してください。 charset登録手順は、唯一与えられたcharsetの種名か名前を関連づけて、MIMEテキストオブジェクトで与えられたcharsetを使用できるかどうかしるしを与えるために存在しています。 特定用途への与えられた登録されたcharsetの一般的な適用性と適切さは、特に、登録問題ではなく、プロトコル問題であり、この登録手順で対処されていません。

1.  Definitions and Notation

1. 定義と記法

   The following sections define terms used in this document.

以下のセクションは本書では使用される用語を定義します。

1.1.  Requirements Notation

1.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 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[1ページ]RFC2978IANA Charset登録手順2000年10月

1.2.  Character

1.2. キャラクター

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

組織に使用される1セットの要素、コントロール、またはデータの表現のメンバー。

1.3.  Charset

1.3. Charset

   The term "charset" (referred to as a "character set" in previous
   versions of this document) 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.  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がさまざまな異なった方法で定義されるのを許容することを意図します、米国-ASCIIなどの簡単な単一のテーブルマッピングから複雑なISO2022のテクニックを使用するものなどのテーブル切り換え方法まで。 しかしながら、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に現れます。

1.4.  Coded Character Set

1.4. コード化文字集合

   A Coded Character Set (CCS) is a one-to-one 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セットの整数まで1〜1つのマッピングです。 コード化文字集合に関する例は、ISO10646[ISO-10646]と、米国-ASCII[米国-ASCII]と、ISO-8859シリーズ[ISO-8859]です。

Freed & Postel           Best Current Practice                  [Page 2]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[2ページ]RFC2978IANA Charset登録手順2000年10月

1.5.  Character Encoding Scheme

1.5. キャラクターコード化計画

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

Coded文字コードかいくつかのコード化文字集合から1セットの八重奏系列までキャラクターEncoding Scheme(CES)はマッピングです。 与えられたCESは時々独身のCCSに関連しています。 例えば、UTF-8はISO10646だけに適用します。

2.  Charset Registration Requirements

2. Charset登録要件

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

登録されたcharsetsが以下で説明されるように多くの要件に従うと予想されます。

2.1.  Required Characteristics

2.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
   text.

登録されたcharsetsは上に与えられた"charset"の定義に一致しなければなりません。 さらに、MIME内容タイプにおける使用のために「テキスト」トップレベルタイプの下で意図するcharsetsはRFC2045で説明されたそのタイプにおける制限に一致しなければなりません。 すべての登録されたcharsetsが、それらがMIMEテキストにおける使用に適しているかどうかに注意しなければなりません。

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

または、1CCSの構成と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の登録は禁じられます。

2.2.  New Charsets

2.2. 新しいCharsets

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

この登録メカニズムは完全に新しいcharsetsのデザインと定義のための手段であることを意図しません。 これは登録手続がそのような仕事のための適切なレビューメカニズムを含んでいないという事実のためです。

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

登録に、そのようなcharsetsのそのようなものか他の工程で定義されたcharsetsと標準化団体か、特定のプロフィールか組み合わせだけが適任であるときに。

2.3.  Naming Requirements

2.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

すべての登録されたcharsetsに1つ以上の名前を割り当てなければなりません。 同じcharsetにおいて複数の名前が受入れられますが、複数の名前が割り当てられるなら、charsetに、ただ一つの第一の名前は受入れられるに違いありません。

Freed & Postel           Best Current Practice                  [Page 3]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[3ページ]RFC2978IANA Charset登録手順2000年10月

   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.

特定にされる。 他のすべての名前が第一の名前のための別名であると考えられて、第一の名前の使用は別名のどれかの使用より好ましいです。

   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が使用に適しないでも、これは適用されます。

   All charsets MUST be assigned a name that provides a display string
   for the associated "MIBenum" value defined below.  These "MIBenum"
   values are defined by and used in the Printer MIB [RFC-1759].  Such
   names MUST begin with the letters "cs" and MUST contain no more than
   40 characters (including the "cs" prefix) chosen from from the
   printable subset of US-ASCII.  Only one name beginning with "cs" may
   be assigned to a single charset.  If no name of this form is
   explicitly defined IANA will assign an alias consisting of "cs"
   prepended to the primary charset name.

以下で定義された関連"MIBenum"値に表示ストリングを提供する名前をすべてのcharsetsに割り当てなければなりません。 これらの"MIBenum"値は[RFC-1759]を、定義されて、Printer MIBで使用されます。 そのような名前は、「Cs」という文字で始まらなければならなくて、米国-ASCIIの印刷可能な部分集合から選ばれた40文字(「Cs」接頭語を含んでいる)未満を含まなければなりません。 「Cs」で始まる1つの名前だけを単一のcharsetに割り当ててもよいです。 このフォームの名前が全く明らかに定義されないと、IANAは第一のcharset名にprependedされた「Cs」から成る別名を割り当てるでしょう。

   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*mime-charset-chars
     mime-charset-chars = ALPHA / DIGIT /
                "!" / "#" / "$" / "%" / "&" /
                "'" / "+" / "-" / "^" / "_" /
                "`" / "{" / "}" / "~"
     ALPHA        = "A".."Z"    ; Case insensitive ASCII Letter
     DIGIT        = "0".."9"    ; Numeric digit

パントマイム-charsetは1*パントマイム-charset雑用パントマイムcharset雑用=アルファー/ DIGIT /“!"と等しいです。 /「#」/「$」/「%」/“&"/、「'、「/「+」/「-」/"^"/"_"/「'「/「「/」」 /「~」アルファー=「A」」。'」「Z」。 大文字と小文字を区別しないASCII Letter DIGIT=「0インチ。」9" ; 数値ケタ

2.4.  Functionality Requirement

2.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としてメディアタイプとそういうものとしてそれを示すことができないので、それは本当により良いです考えられた。

2.5.  Usage and Implementation Requirements

2.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 unlabeled charsets hampers interoperability even more.

与えられたプロトコルにおける多くのcharsetsの使用は相互運用性を妨げるかもしれません。 しかしながら、多くの正式書類のない、そして/または、ラベルされていないcharsetsの使用は相互運用性をさらにも妨げます。

Freed & Postel           Best Current Practice                  [Page 4]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[4ページ]RFC2978IANA Charset登録手順2000年10月

   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が制限されたか専門化している使用の存在として明らかにマークされるべきであり、インターネットメッセージで先の二国間条約で使用されるだけであるべきであることに注意してください。

2.6.  Publication Requirements

2.6. 公表要件

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

Charset登録証明書はRFCsで発行されるかもしれなくて、しかしながら、RFC公表は、新しいcharsetを登録するのに必要ではありません。

   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。

   Charset registrations SHOULD include a specification of mapping from
   the charset into ISO 10646 if specification of such a mapping is
   feasible.

そのようなマッピングの仕様が可能であるなら、Charset登録証明書SHOULDはcharsetからのマッピングの仕様をISO10646に含めます。

2.7.  MIBenum Requirements

2.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.  MIBenum values are not assigned by the person
   registering the charset.

各charsetのためのMIBenum値は登録時点で、IANAによって割り当てられるでしょう。 MIBenum値はcharsetを登録する人によって割り当てられません。

3.  Charset Registration Procedure

3. Charset登録手順

   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によって実行されました。 これは、正規の標準規格の過程ではなく、むしろ共同体コメントを許容することを意図する行政手続と過度の時間遅れなしでチェックする正気です。

3.1.  Present the Charset to the Community

3.1. Charsetを共同体に寄贈してください。

   Send the proposed charset registration to the "ietf-
   charsets@iana.org" mailing list.  (Information about joining this
   list is available on the IANA Website, http://www.iana.org.)  This
   mailing list has been established for the sole purpose of reviewing

「ietf charsets@iana.org 」メーリングリストに提案されたcharset登録を送ってください。 (このリストを接合することに関する情報はIANA Website、 http://www.iana.org で利用可能です。) このメーリングリストは論評する唯一の目的のために確立されました。

Freed & Postel           Best Current Practice                  [Page 5]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[5ページ]RFC2978IANA Charset登録手順2000年10月

   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.

charset登録証明書を提案しました。 提案されたcharsetsを正式に登録しないで、使用してはいけません。 登録が完全になるまで、RFC2045で指定された「x」接頭語は使用できます。

   The posting of a charset to the list initiates a two week public
   review process.

リストへのcharsetの任命は2週間の公開レビューの過程に着手します。

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

公共の任命の意図はそれのためにcharsetの定義と選ぶという名前のコメントとフィードバックに請求することです。

3.2.  Charset Reviewer

3.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とcharset評論家に登録申請を提出するべきです。 charset評論家(IETF Applications Areaディレクターによって任命される)は、登録を求める要求を承認するか、またはそれを拒絶します。 拒絶はリストで上げられた重要な反論か外部的に上げられた反論で起こるかもしれません。 charset評論家が、登録が十分重要であって、論議を呼ぶと考えるなら、コメントのための最後の呼び出しは完全なIETFに発行されるかもしれません。 また、それが適切に見えて、charsetの仕様のレベルが適切であるときに、charset評論家は標準化過程処理を推薦するかもしれません(登録の前または後に)。

   The charset reviewer must reach a decision and post it to the ietf-
   charsets mailing list within two weeks.  Decisions made by the
   reviewer may be appealed to the IESG.

charset評論家は、2週間以内に決断を下して、ietf- charsetsメーリングリストにそれを掲示しなければなりません。 評論家によってされた決定はIESGに上告されるかもしれません。

3.3.  IANA Registration

3.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値を割り当てて、登録を共同体に利用可能にするでしょう。

4.  Location of Registered Charset List

4. 登録された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-1543]).

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-1543]に指示に従ってください)。

Freed & Postel           Best Current Practice                  [Page 6]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[6ページ]RFC2978IANA Charset登録手順2000年10月

5.  Charset Registration Template

5. Charset登録テンプレート

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

To: ietf-charsets@iana.org Subject: 新しいcharsetの登録[名前]

     Charset name:

Charsetは以下を命名します。

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

(すべての名前がMIMEの満足している型引数の値として使用に適しているに違いありません。)

     Charset aliases:

Charset別名:

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

(また、すべての別名もMIMEの満足している型引数の値として使用に適しているに違いありません。)

     Suitability for use in MIME text:

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 one or more CCS's and a CES then these
     definitions MUST either be included or referenced.)

(charsetがオープンにそんなに正確に利用可能でなければならないので、仕様は登録されていることについて説明します。 charsetが1CCSとCESの構成と定義されるなら、これらの定義に含まれなければならないか、または参照をつけなければなりません。)

     ISO 10646 equivalency table:

ISO10646同等テーブル:

     (A URI to a specification of how to translate from
     this charset to ISO 10646 and vice versa SHOULD be
     provided.)

これからどう翻訳するかに関する仕様へのURIは逆もまた同様です、ISO10646とSHOULDにcharsetされます。(提供する、)

     Additional information:

追加情報:

     Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

     Intended usage:

意図している用法:

     (One of COMMON, LIMITED USE or OBSOLETE)

(1つ、コモン使用か時代遅れで制限されて、

6.  Security Considerations

6. セキュリティ問題

   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を使うプロトコルで既に存在するものとかなり異なったセキュリティ問題も提起するのが知られません。

Freed & Postel           Best Current Practice                  [Page 7]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[7ページ]RFC2978IANA Charset登録手順2000年10月

7.  Changes made since RFC 2278

7. 変化は以来、RFCを2278にしました。

   Inclusion of a mapping to ISO 10646 is now recommended for all
   registered charsets.  The registration template has been updated to
   include this as well as a place to indicate whether or not the
   charset is suitable for use in MIME text.

ISO10646へのマッピングの包含は現在、すべての登録されたcharsetsのために推薦されます。 charsetがMIMEテキストにおける使用に適しているかどうかを示す場所と同様にこれを含むように登録テンプレートをアップデートしました。

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:1998, 1st ed.
         - Part 2: Latin Alphabet No. 2, ISO 8859-2:1999, 1st ed.
         - Part 3: Latin Alphabet No. 3, ISO 8859-3:1999, 1st ed.
         - Part 4: Latin Alphabet No. 4, ISO 8859-4:1998, 1st ed.
         - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1999, 2nd ed.
         - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1999, 1st ed.
         - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
         - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1999, 1st ed.
         - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1999, 2nd ed.
         International Standard -- Information Technology -- 8-bit
         Single-Byte Coded Graphic Character Sets
         - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1998, 2nd ed.
         International Standard -- Information Technology -- 8-bit
         Single-Byte Coded Graphic Character Sets
         - Part 13: Latin Alphabet No. 7, ISO/IEC 8859-10:1998, 1st ed.
         International Standard -- Information Technology -- 8-bit
         Single-Byte Coded Graphic Character Sets
         - Part 14: Latin Alphabet No. 8 (Celtic), ISO/IEC
         8859-10:1998, 1st ed.
         International Standard -- Information Technology -- 8-bit
         Single-Byte Coded Graphic Character Sets
         - Part 15: Latin Alphabet No. 9, ISO/IEC 8859-10:1999,
         1st ed.

[ISO-8859] 世界規格--情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1、ISO8859-1: 1998、最初の教育。 - 第2部: ローマ字No.2、ISO8859-2: 1999、最初の教育。 - パート3: ローマ字No.3、ISO8859-3: 1999、最初の教育。 - パート4: ローマ字No.4、ISO8859-4: 1998、最初の教育。 - パート5: ラテン/キリル文字、ISO8859-5: 1999、2番目の教育。 - パート6: ラテン語の、または、アラビアのAlphabet、ISO8859-6: 1999、最初の教育。 - パート7: ラテン語の、または、ギリシアのAlphabet、ISO8859-7: 1987、最初の教育。 - パート8: ラテン語の、または、ヘブライのAlphabet、ISO8859-8: 1999、最初の教育。 - パート9: ローマ字No.5、ISO/IEC8859-9: 1999、2番目の教育。 国際規格--情報技術--8ビットの単一のバイトコード化された図形文字セット--パート10: ローマ字No.6、ISO/IEC8859-10: 1998、2番目の教育。 国際規格--情報技術--8ビットの単一のバイトコード化された図形文字セット--パート13: ローマ字No.7、ISO/IEC8859-10: 1998、最初の教育。 国際規格--情報技術--8ビットの単一のバイトコード化された図形文字セット--パート14: ローマ字No.8(ケルト族の)、ISO/IEC8859-10: 1998、最初の教育。 国際規格--情報技術--8ビットの単一のバイトコード化された図形文字セット--パート15: ローマ字No.9、ISO/IEC8859-10: 1999、最初の教育。

   [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。

Freed & Postel           Best Current Practice                  [Page 8]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[8ページ]RFC2978IANA Charset登録手順2000年10月

   [RFC-1590] Postel, J., "Media Type Registration Procedure", RFC
              1590,March 1994.

[RFC-1590] ポステル、J.、「メディアは登録手順をタイプする」RFC1590、1994年3月。

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

[RFC-1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。

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

[RFC-1759] スミスとR.とライトとF.とヘイスティングズとT.とZillesとS.と1995年の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日

   [RFC-2468] Cerf, V., "I Remember IANA", RFC 2468, October 1998.

[RFC-2468] サーフ、V.、「私はIANAを覚えている」RFC2468、1998年10月。

   [RFC-2278] Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", BCP 19, RFC 2278, January 1998.

解放された[RFC-2278]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2278、1998年1月。

   [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 9]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[9ページ]RFC2978IANA Charset登録手順2000年10月

10.  Authors' Addresses

10. 作者のアドレス

   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

ジョン・ポステル

   Sadly, Jon Postel, the co-author of this document, passed away on
   October 16, 1998 [RFC-2468].  Any omissions or errors are solely the
   responsibility of the remaining co-author.

悲しげに、ジョン・ポステル(このドキュメントの共著者)は1998年10月16日[RFC-2468]に亡くなりました。 どんな省略や誤りも唯一残っている共著者の責任です。

Freed & Postel           Best Current Practice                 [Page 10]

RFC 2978          IANA Charset Registration Procedures      October 2000

最も良い現在の解放されるのとポステルの練習[10ページ]RFC2978IANA Charset登録手順2000年10月

11.  Full Copyright Statement

11. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Freed & Postel           Best Current Practice                 [Page 11]

最も良い現在の解放されるのとポステルのPractice[11ページ]