RFC4289 日本語訳

Network Working Group                                           N. Freed
Request for Comments: 4289                              Sun Microsystems
BCP: 13                                                       J. Klensin
Obsoletes: 2048                                            December 2005
Category: Best Current Practice

ネットワークワーキンググループN.はコメントを求める要求を解放しました: 4289サン・マイクロシステムズBCP: 13 J.Klensinは以下を時代遅れにします。 2048 2005年12月のカテゴリ: 最も良い現在の習慣

        Multipurpose Internet Mail Extensions (MIME) Part Four:
                        Registration Procedures

マルチパーパスインターネットメールエクステンション(MIME)パートFour: 登録手順

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.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document specifies IANA registration procedures for MIME
   external body access types and content-transfer-encodings.

このドキュメントはMIMEの外部のボディーアクセス型と満足している転送encodingsにIANA登録手順を指定します。

Freed & Klensin          Best Current Practice                  [Page 1]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[1ページ]RFC4289は登録2005年12月にまねます。

Table of Contents

目次

   1. Introduction ....................................................2
   2. External Body Access Types ......................................3
      2.1. Registration Requirements ..................................3
         2.1.1. Naming Requirements ...................................3
         2.1.2. Mechanism Specification Requirements ..................3
         2.1.3. Publication Requirements ..............................4
         2.1.4. Security Requirements .................................4
      2.2. Registration Procedure .....................................4
         2.2.1. Present the Access Type to the Community ..............4
         2.2.2. Access Type Reviewer ..................................4
         2.2.3. IANA Registration .....................................5
      2.3. Location of Registered Access Type List ....................5
      2.4. IANA Procedures for Registering Access Types ...............5
   3. Transfer Encodings ..............................................5
      3.1. Transfer Encoding Requirements .............................6
         3.1.1. Naming Requirements ...................................6
         3.1.2. Algorithm Specification Requirements ..................6
         3.1.3. Input Domain Requirements .............................6
         3.1.4. Output Range Requirements .............................6
         3.1.5. Data Integrity and Generality Requirements ............7
         3.1.6. New Functionality Requirements ........................7
         3.1.7. Security Requirements .................................7
      3.2. Transfer Encoding Definition Procedure .....................7
      3.3. IANA Procedures for Transfer Encoding Registration .........8
      3.4. Location of Registered Transfer Encodings List .............8
   4. Security Considerations .........................................8
   5. IANA Considerations .............................................8
   6. Acknowledgements ................................................8
   7. References ......................................................9
   A.  Changes Since RFC 2048 .........................................9

1. 序論…2 2. 外部のボディーアクセス型…3 2.1. 登録要件…3 2.1.1. 要件を命名します…3 2.1.2. メカニズム仕様書要求事項…3 2.1.3. 公表要件…4 2.1.4. セキュリティ要件…4 2.2. 登録手順…4 2.2.1. 共同体にアクセス型を提示してください…4 2.2.2. タイプ評論家にアクセスしてください…4 2.2.3. IANA登録…5 2.3. 登録されたアクセス型の並びの位置…5 2.4. 登録するためのIANA手順はタイプにアクセスします…5 3. Encodingsを移してください…5 3.1. 要件をコード化して、移してください…6 3.1.1. 要件を命名します…6 3.1.2. アルゴリズム仕様書要求事項…6 3.1.3. ドメイン要求性を入力してください…6 3.1.4. 範囲要件を出力してください…6 3.1.5. データの保全と一般性要件…7 3.1.6. 新しい機能性要件…7 3.1.7. セキュリティ要件…7 3.2. 定義手順をコード化して、移してください…7 3.3. 登録をコード化する転送のためのIANA手順…8 3.4. 登録された転送Encodingsリストの位置…8 4. セキュリティ問題…8 5. IANA問題…8 6. 承認…8 7. 参照…9 RFC2048以来A.は変化します…9

1.  Introduction

1. 序論

   Recent Internet protocols have been carefully designed to be easily
   extensible in certain areas.  In particular, MIME [RFC2045] is an
   open-ended framework and can accommodate additional object types,
   charsets, and access methods without any changes to the basic
   protocol.  A registration process is needed, however, to ensure that
   the set of such values is developed in an orderly, well-specified,
   and public manner.

最近のインターネットプロトコルは、ある一定の領域で容易に広げることができるように入念に設計されています。 MIME[RFC2045]は、特に、制限のないフレームワークであり、基本プロトコルへの少しも変化なしで追加オブジェクト・タイプ、charsets、およびアクセス法に対応できます。 しかしながら、登録手続が、そのような値のセットが規則的で、よく指定されて、公共の方法で発展するのを保証するのに必要です。

   This document defines registration procedures that use the Internet
   Assigned Numbers Authority (IANA) as a central registry for these
   values.

このドキュメントはこれらの値に、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用する登録手順を定義します。

Freed & Klensin          Best Current Practice                  [Page 2]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[2ページ]RFC4289は登録2005年12月にまねます。

   Note:

以下に注意してください。

      Registration of media types and charsets for use in MIME are
      specified in separate documents [RFC4288] [RFC2978] and are not
      addressed here.

メディアの登録がタイプして、MIMEにおける使用のためのcharsetsは別々のドキュメント[RFC4288][RFC2978]で指定されて、ここで扱われません。

1.1.  Conventions Used in This Document

1.1. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  External Body Access Types

2. 外部のボディーアクセス型

   [RFC2046] defines the message/external-body media type, whereby a
   MIME entity can act as pointer to the actual body data in lieu of
   including the data directly in the entity body.  Each
   message/external-body reference specifies an access type, which
   determines the mechanism used to retrieve the actual body data.  RFC
   2046 defines an initial set of access types but allows for the
   registration of additional access types to accommodate new retrieval
   mechanisms.

[RFC2046]は外部のメッセージ/ボディーメディアタイプを定義します。(直接実体本体にデータを含んでいることの代わりにMIME実体は指針としてタイプで実際のボディーデータに機能できます)。 それぞれの外部のメッセージ/ボディー参照はアクセス型を指定します。(そのアクセス型は、メカニズムが以前はよく実際のボディーデータを検索していたと決心しています)。 RFC2046は、1人の始発のアクセス型を定義しますが、追加アクセス型の登録が新しい回収機構に対応するのを許容します。

2.1.  Registration Requirements

2.1. 登録要件

   New access type specifications MUST conform to the requirements
   described below.

新しいアクセス型仕様は以下で説明された要件に従わなければなりません。

2.1.1.  Naming Requirements

2.1.1. 要件を命名します。

   Each access type MUST have a unique name.  This name appears in the
   access-type parameter in the message/external-body content-type
   header field and MUST conform to MIME content type parameter syntax.

各アクセス型には、ユニークな名前がなければなりません。 この名前は、外部のメッセージ/ボディーcontent typeヘッダーフィールドにおけるアクセス型パラメタに現れて、MIME content typeパラメタ構文に従わなければなりません。

2.1.2.  Mechanism Specification Requirements

2.1.2. メカニズム仕様書要求事項

   All of the protocols, transports, and procedures used by a given
   access type MUST be described, either in the specification of the
   access type itself or in some other publicly available specification,
   in sufficient detail for the access type to be implemented by any
   competent implementor.  Use of secret and/or proprietary methods in
   access types is expressly prohibited.  The restrictions imposed by
   [RFC2026] on the standardization of patented algorithms must be
   respected as well.

アクセス型自身の仕様かある他の公的に利用可能な仕様で与えられたアクセス型によって用いられたプロトコル、輸送、および手順のすべてについて説明しなければなりません、どんな有能な作成者もアクセス型を実装することができるくらい詳細に。 アクセス型における秘密の、そして/または、独占であるメソッドの使用は明白に禁止されています。 また、[RFC2026]によって特許をとられたアルゴリズムの標準化に課された制限を尊敬しなければなりません。

Freed & Klensin          Best Current Practice                  [Page 3]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[3ページ]RFC4289は登録2005年12月にまねます。

2.1.3.  Publication Requirements

2.1.3. 公表要件

   All access types MUST be described by an RFC.  The RFC may be
   informational rather than standards-track, although standards-track
   review and approval are encouraged for all access types.

RFCはすべてのアクセス型を説明しなければなりません。 標準化過程レビューと承認はすべてのアクセス型のために奨励されますが、RFCは標準化過程よりむしろ情報であるかもしれません。

2.1.4.  Security Requirements

2.1.4. セキュリティ要件

   Any known security issues that arise from the use of the access type
   MUST be completely and fully described.  It is not required that the
   access type be secure or that it be free from risks, but it is
   required that the known risks be identified.  Publication of a new
   access type does not require an exhaustive security review, and the
   security considerations section is subject to continuing evaluation.
   Additional security considerations SHOULD be addressed by publishing
   revised versions of the access type specification.

アクセス型の使用から起こるどんな知られている安全保障問題についても完全に、そして完全に説明しなければなりません。 アクセス型が安全であるか、またはそれにはリスクがないのが必要ではありませんが、知られている危険が特定されるのが必要です。 新しいアクセス型の公表は評価を続けているレビュー、およびセキュリティ問題部を条件としている徹底的なセキュリティを必要としません。 追加担保問題SHOULD、アクセス型仕様の出版改訂版で、扱われてください。

2.2.  Registration Procedure

2.2. 登録手順

   Registration of a new access type starts with the publication of the
   specification as an Internet Draft.

新しいアクセス型の登録はインターネットDraftとして仕様の公表から始まります。

2.2.1.  Present the Access Type to the Community

2.2.1. 共同体にアクセス型を提示してください。

   A proposed access type specification is sent to the
   "ietf-types@iana.org" mailing list for a two-week review period.
   This mailing list has been established for the purpose of reviewing
   proposed access and media types.  Proposed access types are not
   formally registered and must not be used.

2週間のレビューの期間、" ietf-types@iana.org "メーリングリストに提案されたアクセス型仕様を送ります。 このメーリングリストは提案されたアクセスとメディアタイプを見直す目的のために確立されました。 提案されたアクセス型を、正式に示さないで、使用してはいけません。

   The intent of the public posting is to solicit comments and feedback
   on the access type specification and a review of any security
   considerations.

公共の任命の意図はアクセス型仕様とどんなセキュリティ問題のレビューのコメントとフィードバックにも請求することです。

2.2.2.  Access Type Reviewer

2.2.2. アクセス型評論家

   When the two-week period has passed, the access type reviewer, who is
   appointed by the IETF Applications Area Director(s), either forwards
   the request to iana@iana.org or rejects it because of significant
   objections raised on the list.

2週間の期間が経過したとき、リストで上げられた重要な反論のために、アクセス型評論家(IETF Applications Areaディレクターによって任命される)は、要求を iana@iana.org に転送するか、またはそれを拒絶します。

   Decisions made by the reviewer must be posted to the ietf-types
   mailing list within 14 days.  Decisions made by the reviewer may be
   appealed to the IESG as specified in [RFC2026].

14日以内にietf-タイプメーリングリストに評論家によってされた決定を掲示しなければなりません。 評論家によってされた決定は[RFC2026]の指定されるとしてのIESGに上告されるかもしれません。

Freed & Klensin          Best Current Practice                  [Page 4]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[4ページ]RFC4289は登録2005年12月にまねます。

2.2.3.  IANA Registration

2.2.3. IANA登録

   Provided that the access type either has passed review or has been
   successfully appealed to the IESG, the IANA will register the access
   type and make the registration available to the community.  The
   specification of the access type must also be published as an RFC.

アクセス型がレビューに合格したか、または首尾よくIESGに上告されたならば、IANAはアクセス型を示して、登録を共同体に利用可能にするでしょう。 また、RFCとしてアクセス型の仕様を発表しなければなりません。

2.3.  Location of Registered Access Type List

2.3. 登録されたアクセス型の並びの位置

   Access type registrations are listed by the IANA on the following web
   page:

アクセス型登録証明書は以下のウェブページのIANAによって記載されています:

     http://www.iana.org/assignments/access-types

http://www.iana.org/assignments/access-types

2.4.  IANA Procedures for Registering Access Types

2.4. アクセス型を示すためのIANA手順

   The identity of the access type reviewer is communicated to the IANA
   by the IESG.  The IANA then only acts either in response to access
   type definitions that are approved by the access type reviewer and
   forwarded to the IANA for registration, or in response to a
   communication from the IESG that an access type definition appeal has
   overturned the access type reviewer's ruling.

アクセス型評論家のアイデンティティはIESGによってIANAに伝えられます。 IANAが次に、アクセス型評論家によって承認されて、登録のためにIANAに送られるアクセス型定義に対応して行動するだけですか、またはアクセス型定義上告がひっくり返したIESGからのコミュニケーションに対応してアクセス型評論家は支配的です。

3.  Transfer Encodings

3. 転送Encodings

   Transfer encodings are transformations applied to MIME media types
   after conversion to the media type's canonical form.  Transfer
   encodings are used for several purposes:

転送encodingsはメディアタイプの標準形への変換の後にMIMEメディアタイプに適用された変換です。 転送encodingsはいくつかの目的に使用されます:

   o  Many transports, especially message transports, can only handle
      data consisting of relatively short lines of text.  There can be
      severe restrictions on what characters can be used in these lines
      of text.  Some transports are restricted to a small subset of US-
      ASCII, and others cannot handle certain character sequences.
      Transfer encodings are used to transform binary data into a
      textual form that can survive such transports.  Examples of this
      sort of transfer encoding include the base64 and quoted-printable
      transfer encodings defined in [RFC2045].

o 多くの輸送(特にメッセージ転送)がテキストの比較的短い系列から成るデータを扱うことができるだけです。 テキストのこれらの系列にどんなキャラクタを使用できるかに関する厳しい制限があることができます。 いくつかの輸送が米国ASCIIの小さい部分集合に制限されます、そして、他のものはあるキャラクタシーケンスを扱うことができません。 転送encodingsは、バイナリ・データをそのような輸送を乗り切ることができる原文のフォームに変えるのに使用されます。 この種類の転送コード化に関する例は[RFC2045]で定義されたbase64と引用されて印刷可能な転送encodingsを含んでいます。

   o  Image, audio, video, and even application entities are sometimes
      quite large.  Compression algorithms are often effective in
      reducing the size of large entities.  Transfer encodings can be
      used to apply general-purpose non-lossy compression algorithms to
      MIME entities.

o イメージ、オーディオ、ビデオ、およびアプリケーション実体さえ時々かなり大きいです。 圧縮アルゴリズムは大きい実体のサイズを減少させるのにおいてしばしば効果的です。 汎用非非可逆圧縮アルゴリズムをMIME実体に適用するのに転送encodingsを使用できます。

   o  Transport encodings can be defined as a means of representing
      existing encoding formats in a MIME context.

o MIME文脈で形式をコード化しながら存在を表す手段と輸送encodingsを定義できます。

Freed & Klensin          Best Current Practice                  [Page 5]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[5ページ]RFC4289は登録2005年12月にまねます。

   IMPORTANT:  The standardization of a large number of different
   transfer encodings is seen as a significant barrier to widespread
   interoperability and is expressly discouraged.  Nevertheless, the
   following procedure has been defined in order to provide a means of
   defining additional transfer encodings, should standardization
   actually be justified.

重要: 多くの異なった転送encodingsの規格化は、重要なバリアと広範囲の相互運用性に考えられて、明白にお勧めできないです。 それにもかかわらず、以下の手順は追加転送encodingsを定義する手段を提供するために定義されました、標準化が実際に正当化されるなら。

3.1.  Transfer Encoding Requirements

3.1. 要件をコード化して、移してください。

   Transfer encoding specifications MUST conform to the requirements
   described below.

仕様をコード化する転送は以下で説明された要件に従わなければなりません。

3.1.1.  Naming Requirements

3.1.1. 要件を命名します。

   Each transfer encoding MUST have a unique name.  This name appears in
   the Content-Transfer-Encoding header field and MUST conform to the
   syntax of that field.

それぞれの転送コード化には、ユニークな名前がなければなりません。 この名前は、Content転送コード化ヘッダーフィールドに現れて、その分野の構文に従わなければなりません。

3.1.2.  Algorithm Specification Requirements

3.1.2. アルゴリズム仕様書要求事項

   All of the algorithms used in a transfer encoding (e.g., conversion
   to printable form, compression) MUST be described in their entirety
   in the transfer encoding specification.  Use of secret and/or

仕様をコード化する転送で転送コード化に使用されるアルゴリズムのすべてについて全体として説明しなければなりません(例えば、印刷可能なフォーム、圧縮への変換)。 そして/または秘密の使用。

   proprietary algorithms in standardized transfer encodings is
   expressly prohibited.  The restrictions imposed by [RFC2026] on the
   standardization of patented algorithms MUST be respected as well.

標準化された転送encodingsの独占アルゴリズムは明白に禁止されています。 また、[RFC2026]によって特許をとられたアルゴリズムの標準化に課された制限を尊敬しなければなりません。

3.1.3.  Input Domain Requirements

3.1.3. 入力ドメイン要求性

   All transfer encodings MUST be applicable to an arbitrary sequence of
   octets of any length.  Dependence on particular input forms is not
   allowed.

すべての転送encodingsがどんな長さの八重奏の気紛れな順番にも適切であるに違いありません。 特定の入力形式への依存は許容されていません。

   It should be noted that the 7bit and 8bit encodings do not conform to
   this requirement.  Aside from the undesirability of having
   specialized encodings, the intent here is to forbid the addition of
   additional encodings similar to, or redundant with, 7bit and 8bit.

7ビットと8ビットのencodingsがこの要件に一致していないことに注意されるべきです。 encodingsを専門にした不適性は別としてここの意図が追加encodings同様の追加がそうするのを禁じることであったまたは余分であることで、7ビットと8に噛み付きました。

3.1.4.  Output Range Requirements

3.1.4. 出力範囲要件

   There is no requirement that a particular transfer encoding produce a
   particular form of encoded output.  However, the output format for
   each transfer encoding MUST be fully and completely documented.  In
   particular, each specification MUST clearly state whether the output
   format always lies within the confines of 7bit or 8bit or is simply
   pure binary data.

特定の転送コード化が特定の形式のコード化された出力を起こすという要件が全くありません。 しかしながら、それぞれの転送コード化のための出力書式を完全に、そして完全に記録しなければなりません。 特に、各仕様は、出力形式がいつも7ビットか8ビットの境界に属すか、単に純粋なバイナリ・データであるかを明確に述べなければなりません。

Freed & Klensin          Best Current Practice                  [Page 6]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[6ページ]RFC4289は登録2005年12月にまねます。

3.1.5.  Data Integrity and Generality Requirements

3.1.5. データの保全と一般性要件

   All transfer encodings MUST be fully invertible on any platform; it
   MUST be possible for anyone to recover the original data by
   performing the corresponding decoding operation.  Note that this
   requirement effectively excludes all forms of lossy compression as
   well as all forms of encryption from use as a transfer encoding.

すべての転送encodingsがどんなプラットホームでも完全にinvertibleでなければなりません。 だれでも操作を解読しながら対応を実行することによってオリジナルのデータを回復するのは、可能であるに違いありません。 事実上、この要件が転送コード化として使用からのすべての形式の暗号化と同様にすべてのフォームの非可逆圧縮を除くことに注意してください。

3.1.6.  New Functionality Requirements

3.1.6. 新しい機能性要件

   All transfer encodings MUST provide some sort of new functionality.
   Some degree of functionality overlap with previously defined transfer
   encodings is acceptable, but any new transfer encoding MUST also
   offer something no other transfer encoding provides.

すべての転送encodingsがある種の新しい機能性を提供しなければなりません。 以前に定義された転送encodingsとの機能性オーバラップがいくらかの許容できますが、また、どんな新しい転送コード化もコード化が供給しない他の転送を全く何かに提供しなければなりません。

3.1.7.  Security Requirements

3.1.7. セキュリティ要件

   To the greatest extent possible, transfer encodings SHOULD NOT
   contain known security issues.  Regardless, any known security issues
   that arise from the use of the transfer encoding MUST be completely
   and fully described.  If additional security issues come to light
   after initial publication and registration, they SHOULD be addressed
   by publishing revised versions of the transfer encoding
   specification.

可能な最大限まで、転送encodings SHOULDは知られている安全保障問題を含んでいません。 不注意に、転送コード化の使用から起こるどんな知られている安全保障問題についても完全に、そして完全に説明しなければなりません。 問題は追加担保であるなら初期の公表と登録の後に明るみに出て、それらはSHOULDです。転送の出版改訂版で、仕様をコード化しながら、扱われてください。

3.2.  Transfer Encoding Definition Procedure

3.2. 定義手順をコード化して、移してください。

   Definition of a new transfer encoding starts with the publication of
   the specification as an Internet Draft.  The draft MUST define the
   transfer encoding precisely and completely, and it MUST also provide
   substantial justification for defining and standardizing a new
   transfer encoding.  This specification MUST then be presented to the
   IESG for consideration.  The IESG can:

インターネットDraftとして仕様の公表で始めをコード化する新しい転送の定義。 草稿は転送コード化を正確に、そして完全に定義しなければなりません、そして、また、それは新しい転送コード化を定義して、標準化するためのかなりの正当化を提供しなければなりません。 そして、考慮のためにこの仕様をIESGに提示しなければなりません。 IESGはそうすることができます:

   o  reject the specification outright as being inappropriate for
      standardization,

o 標準化に不適当であるとして仕様を完全に拒絶してください。

   o  assign the specification to an existing IETF working group for
      further work,

o さらなる仕事のために既存のIETFワーキンググループに仕様を配属してください。

   o  approve the formation of an IETF working group to work on the
      specification in accordance with IETF procedures, or

o またはIETF手順によると、仕様に取り組むためにIETFワーキンググループの構成を承認してください。

   o  accept the specification as-is for processing as an individual
      standards-track submission.

o 処理に、仕様が個々の標準化過程服従としてそのままであると受け入れてください。

   Transfer encoding specifications on the standards track follow normal
   IETF rules for standards-track documents.  A transfer encoding is

転送コード化仕様は標準化過程の上で標準化過程文書のための正常なIETF規則に従います。 転送コード化はそうです。

Freed & Klensin          Best Current Practice                  [Page 7]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[7ページ]RFC4289は登録2005年12月にまねます。

   considered to be defined and available for use once it is on the
   standards track.

標準化過程の上にそれがいったんあると、使用に定義されていて利用可能であると考えられます。

3.3.  IANA Procedures for Transfer Encoding Registration

3.3. 登録をコード化する転送のためのIANA手順

   There is no need for a special procedure for registering Transfer
   Encodings with the IANA.  All legitimate transfer encoding
   registrations MUST appear as a standards-track RFC, so it is the
   IESG's responsibility to notify the IANA when a new transfer encoding
   has been approved.

IANAにTransfer Encodingsを登録するための特別な手順の必要は全くありません。 登録証明書をコード化するすべての正統の転送が標準化過程RFCとして現れなければならないので、それは新しい転送コード化が承認されたときIANAに通知するIESGの責任です。

3.4.  Location of Registered Transfer Encodings List

3.4. 登録された転送Encodingsリストの位置

   The list of transfer encoding registrations can be found at:

以下で登録証明書をコード化する転送のリストを見つけることができます。

     http://www.iana.org/assignments/transfer-encodings

http://www.iana.org/assignments/transfer-encodings

4.  Security Considerations

4. セキュリティ問題

   Security requirements for access types are discussed in Section
   2.1.4.  Security requirements for transfer encodings are discussed in
   Section 3.1.7.

セクション2.1.4でアクセス型のためのセキュリティ要件について議論します。 セクション3.1.7で転送encodingsのためのセキュリティ要件について議論します。

5.  IANA Considerations

5. IANA問題

   The sole purpose of this document is to define IANA registries for
   access types and transfer encodings.  The IANA procedures for these
   registries are specified in Section 2.4 and Section 3.3 respectively.

このドキュメントの唯一の目的は、アクセス型のためにIANA登録を定義して、encodingsを移すことです。 これらの登録へのIANA手順はセクション2.4とセクション3.3でそれぞれ指定されます。

6.  Acknowledgements

6. 承認

   The current authors would like to acknowledge their debt to the late
   Dr. Jon Postel, whose general model of IANA registration procedures
   and specific contributions shaped the predecessors of this document
   [RFC2048].  We hope that the current version is one with which he
   would have agreed but, as it is impossible to verify that agreement,
   we have regretfully removed his name as a co-author.

現在の作者はIANA登録手順と特定の貢献の一般的なモデルがこのドキュメント[RFC2048]の前任者を形成した故ジョン・ポステル博士に彼らの負債を承認したがっています。 最新版が彼が同意したでしょうが、その協定について確かめるのが不可能であるので私たちが残念ながら共著者として彼の名前を取り除いたものであることを願っています。

Freed & Klensin          Best Current Practice                  [Page 8]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[8ページ]RFC4289は登録2005年12月にまねます。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

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

解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

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

解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。

7.2.  Informative References

7.2. 有益な参照

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

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

解放された[RFC2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。

   [RFC2978]  Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", BCP 19, RFC 2978, October 2000.

解放された[RFC2978]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。

Freed & Klensin          Best Current Practice                  [Page 9]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[9ページ]RFC4289は登録2005年12月にまねます。

Appendix A.  Changes Since RFC 2048

RFC2048以来の付録A.変化

   o  Media type registration procedures are now described in a separate
      document [RFC4288].

o メディアタイプ登録手順は現在、別々のドキュメント[RFC4288]で説明されます。

   o  The various URLs and addresses in this document have been changed
      so they all refer to iana.org rather than isi.edu.  Additionally,
      many of the URLs have been changed to use HTTP; formerly they used
      FTP.

o 本書では様々なURLとアドレスを変えたので、彼らは皆、isi.eduよりむしろiana.orgについて言及します。 さらに、HTTPを使用するためにURLの多くを変えました。 以前、彼らはFTPを使用しました。

   o  Much of the document has been clarified in the light of
      operational experience with these procedures.

o ドキュメントの多くがこれらの手順の運用経験の見地からはっきりさせられました。

   o  Several of the references in this document have been updated to
      refer to current versions of the relevant specifications.

o 関連仕様の最新版について言及するために本書ではいくつかの参照をアップデートしました。

   o  The option of assigning the task of working on a new transfer
      encoding to an existing working group has been added to the list
      of possible actions the IESG can take.

o 既存のワーキンググループにコード化される新しい転送に働くタスクを割り当てるオプションをIESGが取ることができる可能な行動のリストに追加してあります。

   o  Security considerations and IANA considerations sections have been
      added.

o セキュリティ問題とIANA問題部は加えられます。

   o  Registration of charsets for use in MIME is specified in [RFC2978]
      and is no longer addressed by this document.

o MIMEにおける使用のためのcharsetsの登録は、[RFC2978]で指定されて、もうこのドキュメントによって扱われません。

Authors' Addresses

作者のアドレス

   Ned Freed
   Sun Microsystems
   3401 Centrelake Drive, Suite 410
   Ontario, CA  92761-1205
   USA

ネッドはサン・マイクロシステムズ3401Centrelakeドライブ、Suite410オンタリオ、カリフォルニア92761-1205米国を解放しました。

   Phone: +1 909 457 4293
   EMail: ned.freed@mrochek.com

以下に電話をしてください。 +1 4293年の909 457メール: ned.freed@mrochek.com

   John C. Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140

マサチューセッツAve、ジョンC.Klensin1770#322ケンブリッジ、MA 02140

   EMail: klensin+ietf@jck.com

メール: klensin+ ietf@jck.com

Freed & Klensin          Best Current Practice                 [Page 10]

RFC 4289                   MIME Registration               December 2005

解放されるのとKlensinの最も良い現在の習慣[10ページ]RFC4289は登録2005年12月にまねます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

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

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

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

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

Freed & Klensin          Best Current Practice                 [Page 11]

解放されるのとKlensinの最も良い現在の習慣[11ページ]