RFC1590 日本語訳

Network Working Group                                          J. Postel
Request for Comments: 1590                                           ISI
Updates: 1521                                                 March 1994
Category: Informational

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 1590のISIアップデート: 1521 1994年3月のカテゴリ: 情報

                   Media Type Registration Procedure

メディアは登録手順をタイプします。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   Several protocols allow the use of data representing different
   "media" such as text, images, audio, and video, and within such media
   different encoding styles, such as (in video) jpeg, gif, ief, and
   tiff.  The Multimedia Internet Message Extensions (MIME) protocol [1]
   defined several initial types of multimedia data objects, and a
   procedure for registering additional types with the Internet Assigned
   Numbers Authority (IANA).  Several questions have been raised about
   the requirements and administrative procedure for registering MIME
   content-type and subtypes, and the use of these Media Types for other
   applications.  This document addresses these issues and specifies a
   procedure for the registration of new Media Types (content-
   type/subtypes).  It also generalizes the scope of use of these Media
   Types to make it appropriate to use the same registrations and
   specifications with other applications.

いくつかのプロトコルがテキストや、イメージや、オーディオや、ビデオなどの異なった「メディア」を表すデータの使用を許します、そして、そのようなメディアの中では、異なったコード化は(ビデオの)jpegなどのようにgif、ief、およびいさかいを流行に合わせます。 MultimediaインターネットMessage Extensions(MIME)プロトコル[1]はインターネットAssigned民数記Authority(IANA)と共にいくつかの初期のタイプのマルチメディアデータ・オブジェクト、および追加タイプを示すための手順を定義しました。 いくつかの疑問がMIME content typeと血液型亜型を登録するための要件と行政手続、およびこれらのメディアTypesの他のアプリケーションの使用に関して引き起こされました。 このドキュメントは、新しいメディアTypes(内容タイプ/血液型亜型)の登録にこれらの問題を扱って、手順を指定します。 また、それは、他のアプリケーションで同じ登録証明書と仕様を使用するのを適切にするようにこれらのメディアTypesで役に立つ範囲を一般化します。

1. Introduction

1. 序論

   RFC 1521 [1] defines a procedure for the registration of new data
   types for use with the Multimedia Internet Message Extensions (MIME).
   This registration mechanism was designed to make the identifiers for
   a given data type available for use and to prevent naming conflicts.
   With the growth of new multi-media protocols and access mechanisms,
   this process has the promise of forming a unified general
   registration service for Internet Protocols.  These types, previously
   called "MIME Types", are now called "Media Types".

RFC1521[1]はMultimediaインターネットMessage Extensions(MIME)との使用のための新しいデータ型の登録のための手順を定義します。 この登録メカニズムは、与えられたデータ型のための識別子を使用に利用可能にして、闘争を命名するのを防ぐように設計されました。 新しいマルチメディアプロトコルとアクセス機構の成長によって、このプロセスには、インターネットプロトコルのための統一された一般的な登録サービスを形成する約束があります。 これらの以前に「MIMEの種類」と呼ばれたタイプは現在、「メディアタイプ」と呼ばれます。

   The registration process for Media Types (content-type/subtypes) was
   initially defined in the context of the asynchronous mail
   environments.  In this mail environment, there is a need to limit the
   number of possible Media Types to increase the likelihood of
   interoperability when the capabilities of the remote mail system are
   not known.  As Media Types are used in new environments, where the

メディアTypes(content type/血液型亜型)のための登録手続は初めは、非同期なメール環境の文脈で定義されました。 このメール環境には、リモートメールシステムの能力が知られていないとき、相互運用性の可能性を広げるために可能なメディアTypesの数を制限する必要があります。 メディアTypesは中古のコネ新しい環境、どこです。

IANA                                                            [Page 1]

RFC 1590           Media Type Registration Procedure          March 1994

IANA[1ページ]RFC1590メディアは1994年の手順行進のときに登録をタイプします。

   proliferation of Media Types is not a hindrance to interoperability,
   the original procedure is excessively restrictive and needs to be
   generalized.

メディアTypesの増殖が相互運用性への妨害でなく、元の手順は、過度に制限していて、一般化される必要があります。

   This document addresses the specific questions raised and provides an
   administrative procedure for the registration of Media Types.  This
   procedure also address the registration requirements needed for the
   mapping of Object Identifiers (OIDs) for X.400 MHS use to Media
   Types.

このドキュメントは、提起された具体的な質問を扱って、メディアTypesの登録のための行政手続を提供します。 また、この手順は、登録がX.400 MHS使用にObject Identifiers(OIDs)に関するマッピングに必要である要件であるとメディアTypesに扱います。

2. Media Type Registration Procedure

2. メディアは登録手順をタイプします。

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

以下の手順は新しいメディアTypesのレビューと承認のためにIANAによって実装されました。 これは、正規の標準規格プロセスではなく、むしろ共同体コメントを許容することを意図する行政手続と過度の時間遅れなしでチェックする正気です。

2.1 Present the Request for Registration to the Community

2.1は登録を求める要求を共同体に提示します。

   Send a proposed Media Type (content-type/subtype) to the "ietf-
   types@cs.utk.edu" mailing list.  This mailing list has been
   established for the sole purpose of reviewing proposed Media Types.
   Proposed content-types are not formally registered and must use the
   "x-" notation for the subtype name.

提案されたメディアType(content type/「副-タイプ」)を「ietf types@cs.utk.edu 」メーリングリストに送ってください。 このメーリングリストは提案されたメディアTypesを見直す唯一の目的のために確立されました。 提案されたcontent typeは、正式に登録されないで、「副-タイプ」名に「x」記法を使用しなければなりません。

   The intent of the public posting is to solicit comments and feedback
   on the choice of content-type/subtype name, the unambiguity of the
   references with respect to versions and external profiling
   information, the choice of which OIDs to use, and a review of the
   security considerations section.  It should be noted that the
   proposed Media Type does not need to make sense for every possible
   application.  If the Media Type is intended for a limited or specific
   use, this should be noted in the submission.

公共の任命の意図はcontent type/「副-タイプ」名の選択、バージョンと外部のプロフィール情報に関する参照の「非-あいまいさ」、選択、どのOIDsを使用するかをおよびセキュリティ問題部のレビューのコメントとフィードバックに請求することです。 提案されたメディアTypeがあらゆる可能なアプリケーションのために理解できる必要はないことに注意されるべきです。 メディアであるなら、Typeは制限されたか特定の使用のために意図して、服従でこれに注意するべきです。

2.2 Submit the Content Type to the IANA for Registration

2.2は登録のためにIANAにcontent typeを提出します。

   After two weeks, submit the proposed Media Type to the IANA for
   registration.  The request and supporting documentation should be
   sent to "iana@isi.edu".  Provided a reasonable review period has
   elapsed, the IANA will register the Media Type, assign an OID under
   the IANA branch, and make the Media Type registration available to
   the community.

2週間後に、登録のために提案されたメディアTypeをIANAに提出してください。 " iana@isi.edu "に要求と解説文書を送るべきです。 妥当なレビューの期間が経過したなら、IANAはメディアTypeを登録して、IANA支店の下でOIDを割り当てて、メディアを共同体に利用可能なType登録にするでしょう。

IANA                                                            [Page 2]

RFC 1590           Media Type Registration Procedure          March 1994

IANA[2ページ]RFC1590メディアは1994年の手順行進のときに登録をタイプします。

   The Media Type registrations will be posted in the anonymous FTP
   directory "ftp.isi.edu:in-notes/media-types" and the Media Type will
   be listed in the periodically issued "Assigned Numbers" RFC [2].  The
   Media Type description may be published as an Informational RFC by
   sending it to "rfc-editor@isi.edu" (please follow the instructions to
   RFC authors [3]).

メディアType登録証明書は「ftp.isi.edu: 注意の/メディアタイプ」という公開FTPディレクトリとメディアで掲示されて、Typeが定期的に発行された「規定番号」RFC[2]に記載されるということでしょう。 メディアType記述は、Informational RFCとして" rfc-editor@isi.edu "にそれを送ることによって、発行されるかもしれません。(RFC作者[3])に指示に従ってください。

3. Clarifications On Specific Issues

3. 特定の問題における明確化

3.1 MIME Requirements for a Limited Number of Content-Types

3.1 限られた数のコンテントタイプのためのMIME要件

   Issue:  In the asynchronous mail environment, where information on
   the capabilities of the remote mail agent is not available to the
   sender, maximum interoperability is attained by restricting the
   number of content-types used to those "common" content-types expected
   to be widely implemented.  This was asserted as a reason to limit the
   number of possible content-types and resulted in a registration
   process with a significant hurdle and delay for those registering
   content-types.

以下を発行してください。 非同期なメール環境で、広く実装されると予想されたそれらの「一般的な」content typeに使用されるcontent typeの数を制限することによって、最大限のインターオペラビリティに達します。そこでは、送付者には、リモートメールエージェントの能力の情報が利用可能ではありません。 これは、可能なcontent typeの数を制限する理由として断言されて、それらのための重要なハードルと遅れがcontent typeを登録している登録手続をもたらしました。

   Comment:  The need for "common" content-types formats does not
   require limiting the registration of new content-types.  This
   restriction may, in fact, hinder interoperability by causing separate
   registration authorities for specific applications which may register
   values in conflict with or otherwise incompatible with each other.
   If a limited set of content-types recommended for a particular
   application, that should be asserted by a separate applicability
   statement specific for the application and/or environment.

コメント: 「一般的な」content type形式の必要性は、登録を制限するのを新しいcontent typeを要求しません。 この制限は衝突するかもしれません。事実上、そうでなければ、中に値を示すかもしれない特定のアプリケーションのために別々の登録局を引き起こすのによる後方の相互運用性は互いと非互換な状態で衝突します。 特定用途のために推薦されたcontent typeの限られたセットであるなら、それはアプリケーション、そして/または、環境に、特定の別々の適用性証明によって断言されるべきです。

3.2 Requirements for a Published Specification

3.2 広められた仕様のための要件

   Issue:  Content-Type registration requires an RFC specifying the data
   format or a reference to a published specification of the data
   stream.  This requirement may be overly restrictive for the use of
   content-type registration for file attachments and distribution
   because a public specification may not be available for a number of
   widely used and exchanged objects.

以下を発行してください。 コンテントタイプ登録はデータの形式を指定するRFCかデータ・ストリームの広められた仕様の参照を必要とします。 公共の仕様が多くの広く使用されて、交換されたオブジェクトに利用可能でないかもしれないので、content type登録のファイルアタッチメントと分配の使用において、この要件はひどく制限しているかもしれません。

   Comment:  MIME required the documentation of a specific content-type
   to allow the unambiguous identification of a defined type.  This
   intent is met by the identification of a particular software package
   and version when registering the content-type and is allowed for
   registration.  The appropriateness of using a Media Type with an
   unavailable specification should not be an issue in the registration.

コメント: MIMEは、定義されたタイプの明確な同定を許容するために特定のcontent typeのドキュメンテーションを必要としました。 この意図は、content typeを登録するとき、特定のソフトウェアパッケージとバージョンの識別で満たされて、登録のために許容されています。 入手できない仕様があるメディアTypeを使用する適切さは登録で問題であるべきではありません。

IANA                                                            [Page 3]

RFC 1590           Media Type Registration Procedure          March 1994

IANA[3ページ]RFC1590メディアは1994年の手順行進のときに登録をタイプします。

3.3 Identification of Security Considerations

3.3 セキュリティ問題の識別

   Issue:  The registration process requires the identification of any
   known security problems with the content-type.

以下を発行してください。 登録手続はcontent typeに関するどんな知られている警備上の問題の識別も必要とします。

   Comment:  It is not required that the content-type be secure or that
   it be free from risks, but that the known risks be identified.
   Publication of a content-type does not require an exhaustive security
   review, and the security considerations section is subject to
   continuing evaluation.  Additional security considerations should be
   periodically published in an RFC by IANA.

コメント: content typeが安全であるか、それにはリスクがありませんが、または知られている危険が特定されるのが必要ではありません。 content typeの公表は評価を続けているレビュー、およびセキュリティ問題部を条件としている徹底的なセキュリティを必要としません。 追加担保問題はRFCで定期的にIANAによって発行されるはずです。

3.4. Recommendations and Standards Status

3.4. 推薦と規格状態

   Issue:  The registration of a data type does not imply endorsement,
   approval, or recommendation by IANA or IETF or even certification
   that the specification is adequate.

以下を発行してください。 データ型の登録は仕様が適切であるというIANA、IETFまたは証明さえによる裏書き、承認、または推薦を含意しません。

   Comment: To become Internet Standards, protocol, data objects, or
   whatever must go through the IETF standards process.  This is too
   difficult and to lengthly a process for the convenient and practical
   need to register Media Types.  It is expected that applicability
   statements for particular applications will be published from time to
   time that recommend implementation of, and support for, data types
   that have proven particularly useful in those contexts.

コメント: インターネットStandards、プロトコル、データ・オブジェクト、または何でもになるのはIETF標準化過程に直面しなければなりません。 これは難し過ぎます、そして、プロセスが便利で実用的ために長さであることはレジスタメディアTypesに難しくなければなりません。 それが予想される、特定用途のための声明が時々発行されて、それが実装を推薦するということであるために望んでいるその適用性、およびサポート、それらの文脈で特に役に立つと判明したデータ型。

4. Security Considerations

4. セキュリティ問題

   This memo does not address specific security issues but outlines a
   security review process for Media Types.

このメモは特定のセキュリティに問題を扱うのではなく、メディアTypesのためにセキュリティ吟味の過程をアウトラインに扱います。

5. Acknowledgements

5. 承認

   Most of the words in this RFC were written by other people --
   primarily John Klensin and Greg Vaudreuil -- and my contribution has
   been to slightly modify some sentences, delete some phrases, and to
   rearrange some paragraphs.  This means that i am responsible for all
   the bad ideas and mangled English, and they deserve the credit (and
   rightly) all the good ideas.

このRFCの単語の大部分は他の人々(主としてジョンKlensinとグレッグ・ボードルイ)によって書かれました、そして、私の貢献はいくつかの文をわずかに変更するために、数個の句を削除してください、そして、いくつかを再配列するのが短い記事を書くということです。 これは、私がすべての悪い考えと台無しにされたイギリス人に責任があることを意味します、そして、それらはクレジット(正しい)に値します。すべての名案。

IANA                                                            [Page 4]

RFC 1590           Media Type Registration Procedure          March 1994

IANA[4ページ]RFC1590メディアは1994年の手順行進のときに登録をタイプします。

6. Author's Address

6. 作者のアドレス

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

ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292

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

以下に電話をしてください。 310-822-1511 Fax: 310-823-6714 メールしてください: Postel@ISI.EDU

7. References

7. 参照

   [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, Bellcore,
       Innosoft, September 1993.

[1] Borenstein N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。

   [3] Postel,J., "Instructions to RFC Authors", RFC 1543,
       USC/Information Sciences Institute, October 1993.

[3] ポステル、J.、「指示、RFCが書く、」、RFC1543、科学が設けるUSC/情報、10月1993日

IANA                                                            [Page 5]

RFC 1590           Media Type Registration Procedure          March 1994

IANA[5ページ]RFC1590メディアは1994年の手順行進のときに登録をタイプします。

Appendix A -- IANA Registration Procedures for Media Types

付録A--メディアタイプのためのIANA登録手順

   MIME has been carefully designed to have extensible mechanisms, and
   it is expected that the set of content-type/subtype pairs and their
   associated parameters will grow significantly with time.  Several
   other MIME fields, notably character set names, access-type
   parameters for the message/external-body type, and possibly even
   Content-Transfer-Encoding values, are likely to have new values
   defined over time.

MIMEは広げることができるメカニズムを持つように入念に設計されています、そして、時間に応じてcontent type/「副-タイプ」組と彼らの関連パラメタのセットがかなり成長すると予想されます。 他のいくつかのMIME分野、著しく文字集合名(外部のメッセージ/ボディータイプ、およびContentがことによるとコード化を移してさえいる値のためのさえアクセス型パラメタ)は時間がたつにつれて定義された新しい値を持っていそうです。

   In general, parameters in the content-type header field are used to
   convey supplemental information for various content types, and their
   use is defined when the content-type and subtype are defined.  New
   parameters should not be defined as a way to introduce new
   functionality.

一般に、content typeヘッダーフィールドにおけるパラメタは様々なcontent typeのための補足的情報を伝えるのに使用されます、そして、content typeと「副-タイプ」が定義されるとき、彼らの使用は定義されます。 新しい機能性を紹介する方法と新しいパラメタを定義するべきではありません。

   In order to ensure that the content-type and subtype (that is Media
   Type) values are developed in an orderly, well-specified, and public
   manner, MIME and other applications use the registration process for
   Media Types defined in this RFC which uses the Internet Assigned
   Numbers Authority (IANA) as a central registry for such values.

content typeと「副-タイプ」(それはメディアTypeである)値が規則的で、よく指定されて、公共の方法で開発されるのを確実にして、MIMEと他のアプリケーションはTypesがそのような値に、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用するこのRFCで定義したメディアに登録手続を使用します。

   In order to simplify and standardize this Media Type registration
   process, this appendix gives templates for the registration of new
   values with IANA.  Each of these is given in the form of an email
   message template, to be filled in by the registering party.

このメディアType登録手続を簡素化して、標準化するために、この付録はIANAとの新しい値の登録のためのテンプレートを与えます。 登録パーティーによって記入されるように、メールメッセージテンプレートの形でそれぞれのこれらを与えます。

   Registration of New Content-type/subtype Values:

新しい文書内容/「副-タイプ」値の登録:

   Note that MIME is generally expected to be extended by subtypes.  If
   a new fundamental top-level type is needed, its specification must be
   published as an RFC or submitted in a form suitable to become an RFC,
   and be subject to the Internet standards process.

一般に、血液型亜型によってMIMEが広げられると予想されることに注意してください。 新しい基本的なトップレベルタイプを必要とするなら、仕様をRFCとして発表しなければならないか、またはRFCになって、インターネット標準化過程を受けることがあるのにおいて適当なフォームで提出しなければなりません。

IANA                                                            [Page 6]

RFC 1590           Media Type Registration Procedure          March 1994

IANA[6ページ]RFC1590メディアは1994年の手順行進のときに登録をタイプします。

      ==================================================================

==================================================================

      To:  IANA@isi.edu
      Subject:  Registration of new Media Type content-type/subtype

To: IANA@isi.edu Subject: 新しいメディアType content type/「副-タイプ」の登録

      Media Type name:

メディアTypeは以下を命名します。

      (If the above is not an existing top-level Media Type, please
      explain why an existing type cannot be used.)

(上記が既存のトップレベルメディアTypeでないなら、なぜ既存のタイプを使用できないか説明してください。)

      Media subtype name:

メディア「副-タイプ」は以下を命名します。

      Required parameters:

必要なパラメタ:

      Optional parameters:

任意のパラメタ:

      Encoding considerations:

問題をコード化します:

      Security considerations:

セキュリティ問題:

      Published specification:

広められた仕様:

      (The published specification must be an Internet RFC or RFC-to-be
      if a new top-level type is being defined, and must be a publicly
      available specification in any case.)

(広められた仕様は、新しいトップレベルタイプが定義されているなら、インターネットRFCか未来のRFCでなければならなく、どのような場合でも、公的に利用可能な仕様であるに違いありません。)

      Person & email address to contact for further information:

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

      ==================================================================

==================================================================

IANA                                                            [Page 7]

IANA[7ページ]