RFC2183 日本語訳

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Updates: 1806                                                  S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

Troostがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2183年の新世紀の間のシステムアップデート: 1806秒間デルナーCategory: 標準化過程クアルコムは1997年8月にK.ムーア、テネシーのエディタ大学を法人組織にしました。

               Communicating Presentation Information in
                           Internet Messages:
                  The Content-Disposition Header Field

インターネットメッセージのプレゼンテーション情報を伝えます: 満足している気質ヘッダーフィールド

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This memo provides a mechanism whereby messages conforming to the
   MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
   2049] can convey presentational information.  It specifies the
   "Content-Disposition" header field, which is optional and valid for
   any MIME entity ("message" or "body part").  Two values for this
   header field are described in this memo; one for the ordinary linear
   presentation of the body part, and another to facilitate the use of
   mail to transfer files.  It is expected that more values will be
   defined in the future, and procedures are defined for extending this
    set of values.

このメモはMIME仕様[RFC2045、RFC2046、RFC2047、RFC2048、RFC2049]に従うメッセージがpresentational情報を伝えることができるメカニズムを提供します。 それは「満足している気質」ヘッダーフィールドを指定します。(どんなMIME実体(「メッセージ」か「身体の部分」)にも、それは、任意であって、有効です)。 このヘッダーフィールドのための2つの値がこのメモで説明されます。 身体の部分の普通の直線的なプレゼンテーション、およびファイルを移すためにメールの使用を容易にする別のもののためのもの。 より多くの値が将来定義されると予想されて、手順は、このセットの値を広げるために定義されます。

   This document is intended as an extension to MIME.  As such, the
   reader is assumed to be familiar with the MIME specifications, and
   [RFC 822].  The information presented herein supplements but does not
   replace that found in those documents.

このドキュメントは拡大としてMIMEに意図します。 そういうものとして、読者がMIME仕様、および[RFC822]によく知られさせると思われます。 情報は、ここに補足を提示しますが、それらのドキュメントで見つけられたそれを取り替えません。

   This document is a revision to the Experimental protocol defined in
   RFC 1806.  As compared to RFC 1806, this document contains minor
   editorial updates, adds new parameters needed to support the File
   Transfer Body Part, and references a separate specification for the
   handling of non-ASCII and/or very long parameter values.

このドキュメントはRFC1806で定義されたExperimentalプロトコルへの改正です。 RFC1806と比べて、このドキュメントは、小さい方の編集のアップデートを含んでいて、新しいパラメタが、File Transfer Body Part、および参照が非ASCIIの、そして/または、非常に長いパラメタ値の取り扱いのための別々の仕様であるとサポートする必要だったと言い足します。

Troost, et. al.             Standards Track                     [Page 1]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[1ページ]RFC2183

1.  Introduction

1. 序論

   MIME specifies a standard format for encapsulating multiple pieces of
   data into a single Internet message. That document does not address
   the issue of presentation styles; it provides a framework for the
   interchange of message content, but leaves presentation issues solely
   in the hands of mail user agent (MUA) implementors.

MIMEはただ一つのインターネットメッセージに複数のデータをカプセル化するのに標準書式を指定します。 そのドキュメントはプレゼンテーションスタイルの問題を扱いません。 それは、メッセージ内容の置き換えにフレームワークを提供しますが、唯一メールユーザエージェント(MUA)の作成者にプレゼンテーションを問題に任せます。

   Two common ways of presenting multipart electronic messages are as a
   main document with a list of separate attachments, and as a single
   document with the various parts expanded (displayed) inline. The
   display of an attachment is generally construed to require positive
   action on the part of the recipient, while inline message components
   are displayed automatically when the message is viewed. A mechanism
   is needed to allow the sender to transmit this sort of presentational
   information to the recipient; the Content-Disposition header provides
   this mechanism, allowing each component of a message to be tagged
   with an indication of its desired presentation semantics.

別々の付属、様々な部分があるただ一つのドキュメントがインラインを広くしたように(表示します)主なドキュメントとして複合電子メッセージを提示する2つの一般的な方法がリストと共にあります。 一般に、付属のディスプレイは受取人側のポジティブ・アクションを必要とするように解釈されます、メッセージを見るとき、自動的にインラインメッセージコンポーネントを表示しますが。 メカニズムが送付者がこの種類のpresentational情報を受取人に伝えるのを許容するのに必要です。 Content-気質ヘッダーはこのメカニズムを提供します、必要なプレゼンテーション意味論のしるしによってタグ付けををされるべきメッセージの各成分を許容して。

   Tagging messages in this manner will often be sufficient for basic
   message formatting. However, in many cases a more powerful and
   flexible approach will be necessary. The definition of such
   approaches is beyond the scope of this memo; however, such approaches
   can benefit from additional Content-Disposition values and
   parameters, to be defined at a later date.

タグ付けメッセージはこの様に基本的なメッセージ形式にしばしば十分です。 しかしながら、多くの場合、より強力でフレキシブルなアプローチは必要になるでしょう。 そのようなアプローチの定義はこのメモの範囲を超えています。 しかしながら、そのようなアプローチは、より後日定義されるために追加Content-気質値とパラメタの利益を得ることができます。

   In addition to allowing the sender to specify the presentational
   disposition of a message component, it is desirable to allow her to
   indicate a default archival disposition; a filename. The optional
   "filename" parameter provides for this.  Further, the creation-date,
   modification-date, and read-date parameters allow preservation of
   those file attributes when the file is transmitted over MIME email.

送付者がメッセージコンポーネントのpresentational気質を指定するのを許容することに加えて、彼女がデフォルトの記録保管所の気質を示すのを許容するのは望ましいです。 ファイル名。 任意の「ファイル名」パラメタはこれに備えます。 ファイルがMIMEメールの上に送られるとき、さらに、作成日付、変更期日、および日付を読んでいるパラメタはそれらのファイル属性の保存を許します。

   NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC 2119].

ネブラスカ: キーワードが解釈しなければならない、本書では現れるとき、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

2.  The Content-Disposition Header Field

2. 満足している気質ヘッダーフィールド

   Content-Disposition is an optional header field. In its absence, the
   MUA may use whatever presentation method it deems suitable.

満足している気質は任意のヘッダーフィールドです。 不在では、MUAはそれが適当であると考えるどんなプレゼンテーションメソッドも使用するかもしれません。

   It is desirable to keep the set of possible disposition types small
   and well defined, to avoid needless complexity. Even so, evolving
   usage will likely require the definition of additional disposition
   types or parameters, so the set of disposition values is extensible;
   see below.

小さく、不必要な複雑さを避けるためによく定義されているように可能な気質タイプのセットを維持するのは望ましいです。 たとえそうだとしても、用法を発展するのがおそらく追加気質タイプかパラメタの定義を必要とするので、気質値のセットは広げることができます。 以下を見てください。

Troost, et. al.             Standards Track                     [Page 2]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[2ページ]RFC2183

   In the extended BNF notation of [RFC 822], the Content-Disposition
   header field is defined as follows:

[RFC822]の拡張BNF記法では、Content-気質ヘッダーフィールドは以下の通り定義されます:

     disposition := "Content-Disposition" ":"
                    disposition-type
                    *(";" disposition-parm)

「気質:=「満足している気質」」:、」 気質タイプ*(「」、;、気質-parm)

     disposition-type := "inline"
                       / "attachment"
                       / extension-token
                       ; values are not case-sensitive

気質タイプ拡大:=「インライン」/「付属」/トークン。 値は大文字と小文字を区別していません。

     disposition-parm := filename-parm
                       / creation-date-parm
                       / modification-date-parm
                       / read-date-parm
                       / size-parm
                       / parameter

日付parmを変更日付作成日付気質-parm:=ファイル名-parm/parm/parm/読んでいる/サイズ-parm/パラメタ

     filename-parm := "filename" "=" value

ファイル名-parm:=「ファイル名」「=」価値

     creation-date-parm := "creation-date" "=" quoted-date-time

作成日付parm:=「作成日付」は引用された日付の時間と「等しいです」。

     modification-date-parm := "modification-date" "=" quoted-date-time

引用された日付の時間と「等しい」という変更日付parm:=「変更日付」

     read-date-parm := "read-date" "=" quoted-date-time

「-読まれて、デートしてください」という日付parmを読んでいる:=「=」引用された日付の時間

     size-parm := "size" "=" 1*DIGIT

サイズ-parm:=「サイズ」は1*ケタと「等しいです」。

     quoted-date-time := quoted-string
                      ; contents MUST be an RFC 822 `date-time'
                      ; numeric timezones (+HHMM or -HHMM) MUST be used

引用された日付の時間の:=引用文字列。 コンテンツはRFC822'日付-時間'であるに違いありません。 数値タイムゾーン(+ HHMMか-HHMM)を使用しなければなりません。

   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
   parameter value containing only non-`tspecials' characters SHOULD be
   represented as a single `token'.  A short parameter value containing
   only ASCII characters, but including `tspecials' characters, SHOULD
   be represented as `quoted-string'.  Parameter values longer than 78
   characters, or which contain non-ASCII characters, MUST be encoded as
   specified in [RFC 2184].

パラメタ値でLENGHTSに注意してください: Aは(長さの<は78のキャラクタと等しいです)パラメタ価値をショートします。非'tspecials'だけのキャラクタSHOULDを含んで、単一の'トークン'として表されてください。 短いパラメタは、唯一の含んでいるASCII文字を評価して、'tspecials'キャラクタ、SHOULDを含んでいるのを評価します。'引用文字列'として、表されます。 78のキャラクタ、または非ASCII文字を含むものをコード化しなければならないより長いパラメタ値は[RFC2184]で指定しました。

   `Extension-token', `parameter', `tspecials' and `value' are defined
   according to [RFC 2045] (which references [RFC 822] in the definition
   of some of these tokens).  `quoted-string' and `DIGIT' are defined in
   [RFC 822].

[RFC2045]に従って、'拡大トークン'、'パラメタ'、'tspecials'、および'値'は定義されます(これらのいくつかのトークンの定義におけるどの参照[RFC822])。 ''引用文字列'DIGIT'は[RFC822]で定義されます。

Troost, et. al.             Standards Track                     [Page 3]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[3ページ]RFC2183

2.1  The Inline Disposition Type

2.1 インライン気質タイプ

   A bodypart should be marked `inline' if it is intended to be
   displayed automatically upon display of the message.  Inline
   bodyparts should be presented in the order in which they occur,
   subject to the normal semantics of multipart messages.

メッセージのディスプレイのときに自動的に表示するのが意図しているなら、bodypartは'インライン'であるとマークされるべきです。 インラインbodypartsはそれらが複合メッセージの正常な意味論を条件として起こるオーダーに示されるべきです。

2.2  The Attachment Disposition Type

2.2 付属気質タイプ

   Bodyparts can be designated `attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user.  The MUA might instead present the user of a
   bitmap terminal with an iconic representation of the attachments, or,
   on character terminals, with a list of attachments from which the
   user could select for viewing or storage.

それらがメール・メッセージの本体から別々であり、彼らのディスプレイが自動であるべきでないことを示しますが、いくつか次第でユーザの動作を促進するために'付属'にBodypartsを指定できます。 または、MUAは代わりに文字端末でビットマップ端末のユーザに付属の映像的表象を与えるかもしれません、ユーザが見るかストレージのために選択できた付属のリストで。

2.3  The Filename Parameter

2.3 ファイル名パラメタ

   The sender may want to suggest a filename to be used if the entity is
   detached and stored in a separate file. If the receiving MUA writes
   the entity to a file, the suggested filename should be used as a
   basis for the actual filename, where possible.

実体が別々のファイルに取り外されて、保存されるなら、送付者は、使用されるためにファイル名を示したがっているかもしれません。 受信MUAがファイルに実体を書くなら、提案されたファイル名は実際のファイル名の基礎として可能であるところで使用されるべきです。

   It is important that the receiving MUA not blindly use the suggested
   filename.  The suggested filename SHOULD be checked (and possibly
   changed) to see that it conforms to local filesystem conventions,
   does not overwrite an existing file, and does not present a security
   problem (see Security Considerations below).

受信MUAが盲目的に提案されたファイル名を使用しないのは、重要です。 提案されたファイル名SHOULDはそれが地方のファイルシステムコンベンションに従うことを確認するためにチェックされて(そして、ことによると、変えます)、既存ファイルを上書きしないで、また警備上の問題を提示しません(以下のSecurity Considerationsを見てください)。

   The receiving MUA SHOULD NOT respect any directory path information
   that may seem to be present in the filename parameter.  The filename
   should be treated as a terminal component only.  Portable
   specification of directory paths might possibly be done in the future
   via a separate Content-Disposition parameter, but no provision is
   made for it in this draft.

受信MUA SHOULD NOTはファイル名パラメタに存在しているように思えるどんなディレクトリパス情報も尊敬します。 ファイル名は端末のコンポーネントだけとして扱われるべきです。 将来、ことによると別々のContent-気質パラメタでディレクトリパスの携帯用の仕様をするかもしれませんが、この草稿でそれに備えます。

   Current [RFC 2045] grammar restricts parameter values (and hence
   Content-Disposition filenames) to US-ASCII.  We recognize the great
   desirability of allowing arbitrary character sets in filenames, but
   it is beyond the scope of this document to define the necessary
   mechanisms.  We expect that the basic [RFC 1521] `value'
   specification will someday be amended to allow use of non-US-ASCII
   characters, at which time the same mechanism should be used in the
   Content-Disposition filename parameter.

現在[RFC2045]の文法はパラメタ値(そして、したがって、Content-気質ファイル名)を米国-ASCIIに制限します。 私たちは、気紛れな質を許容するすばらしい願わしさがファイル名でセットすると認めますが、それは、必要なメカニズムを定義するためにこのドキュメントの範囲を超えています。私たちは、Content-気質ファイル名パラメタで基本[RFC1521]の'値'仕様がいつか、非米国のASCII文字の使用を許すために改正されて、同じメカニズムがその時に使用されるべきであると予想します。

Troost, et. al.             Standards Track                     [Page 4]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[4ページ]RFC2183

   Beyond the limitation to US-ASCII, the sending MUA may wish to bear
   in mind the limitations of common filesystems.  Many have severe
   length and character set restrictions.  Short alphanumeric filenames
   are least likely to require modification by the receiving system.

米国-ASCIIへの制限を超えて、発信しているMUAは一般的なファイルシステムの制限を覚えておきたがっているかもしれません。多くには、厳しい長さと文字集合制限があります。 短い..英数字..ファイル名..最も..ありそう..必要..変更..受電方式

   The presence of the filename parameter does not force an
   implementation to write the entity to a separate file. It is
   perfectly acceptable for implementations to leave the entity as part
   of the normal mail stream unless the user requests otherwise. As a
   consequence, the parameter may be used on any MIME entity, even
   `inline' ones. These will not normally be written to files, but the
   parameter could be used to provide a filename if the receiving user
   should choose to write the part to a file.

ファイル名パラメタの存在は実装に別々のファイルに実体を強制的に書かせません。 実装が正常なメールストリームの一部として実体を残すのが、完全に許容できる、ユーザは別の方法で要求します。 結果として、パラメタはどんなMIME実体、'インライン'のものでさえも使用されるかもしれません。 これらは通常ファイルに書かれないでしょうが、受信ユーザが、ファイルに部分を書くのを選ぶなら、パラメタは、ファイル名を提供するのに使用されるかもしれません。

2.4 The Creation-Date parameter

2.4 Creation-日付のパラメタ

   The creation-date parameter MAY be used to indicate the date at which
   the file was created.  If this parameter is included, the paramter
   value MUST be a quoted-string which contains a representation of the
   creation date of the file in [RFC 822] `date-time' format.

作成日付のパラメタは、ファイルが作成された日付を示すのに使用されるかもしれません。 このパラメタが含まれているなら、paramter値は[RFC822]'日付-時間'形式における、ファイルの作成日付の表現を含む引用文字列でなければなりません。

   UNIX and POSIX implementors are cautioned that the `st_ctime' file
   attribute of the `stat' structure is not the creation time of the
   file; it is thus not appropriate as a source for the creation-date
   parameter value.

UNIXとPOSIX作成者が警告される、それ、'、第_ctime''スタットに関するファイル属性'構造はファイルの作成時間ではありません。 その結果、それは作成日付のパラメタ価値のためのソースとして適切ではありません。

2.5 The Modification-Date parameter

2.5 Modification-日付のパラメタ

   The modification-date parameter MAY be used to indicate the date at
   which the file was last modified.  If the modification-date parameter
   is included, the paramter value MUST be a quoted-string which
   contains a representation of the last modification date of the file
   in [RFC 822] `date-time' format.

変更日付のパラメタは、ファイルが最後に変更された日付を示すのに使用されるかもしれません。 変更日付のパラメタが含まれているなら、paramter値は[RFC822]'日付-時間'形式における、ファイルの最後の変更日付の表現を含む引用文字列でなければなりません。

2.6 The Read-Date parameter

2.6 Read-日付のパラメタ

   The read-date parameter MAY be used to indicate the date at which the
   file was last read.  If the read-date parameter is included, the
   parameter value MUST be a quoted-string which contains a
   representation of the last-read date of the file in [RFC 822] `date-
   time' format.

日付を読んでいるパラメタは、ファイルが最後に読まれた日付を示すのに使用されるかもしれません。 日付を読んでいるパラメタが含まれているなら、パラメタ値は[RFC822]'日付の時間'形式における、ファイルの最後に読んでいる期日の表現を含む引用文字列でなければなりません。

2.7 The Size parameter

2.7 Sizeパラメタ

   The size parameter indicates an approximate size of the file in
   octets.  It can be used, for example, to pre-allocate space before
   attempting to store the file, or to determine whether enough space
   exists.

サイズ・パラメータは八重奏における、ファイルの大体のサイズを示します。 例えば、ファイルを保存するか、または十分なスペースが存在するかどうか決定するのを試みる前に、プレ配分スペースにそれを使用できます。

Troost, et. al.             Standards Track                     [Page 5]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[5ページ]RFC2183

2.8  Future Extensions and Unrecognized Disposition Types

2.8 今後の拡大と認識されていない気質タイプ

   In the likely event that new parameters or disposition types are
   needed, they should be registered with the Internet Assigned Numbers
   Authority (IANA), in the manner specified in Section 9 of this memo.

そんなに新しいありそうなイベントでは、パラメタか気質タイプが必要であり、彼らはインターネットAssigned民数記Authorityに登録されるべきです(IANA)、このメモのセクション9で指定された方法で。

   Once new disposition types and parameters are defined, there is of
   course the likelihood that implementations will see disposition types
   and parameters they do not understand.  Furthermore, since x-tokens
   are allowed, implementations may also see entirely unregistered
   disposition types and parameters.

新しい気質タイプとパラメタがいったん定義されると、実装が、気質タイプとそれらがするパラメタが分からないのがわかるという見込みがもちろんあります。 その上、x-トークンが許容されているので、また、実装は完全に登録されていない気質タイプとパラメタを見るかもしれません。

   Unrecognized parameters should be ignored. Unrecognized disposition
   types should be treated as `attachment'. The choice of `attachment'
   for unrecognized types is made because a sender who goes to the
   trouble of producing a Content-Disposition header with a new
   disposition type is more likely aiming for something more elaborate
   than inline presentation.

認識されていないパラメタは無視されるべきです。 認識されていない気質タイプは'付属'として扱われるべきです。 新しい気質タイプでContent-気質ヘッダーをわざわざ作り出す送付者がおそらくインラインプレゼンテーションより何か入念なものを目指しているので、認識されていないタイプに関する'付属'の選択をします。

   Unless noted otherwise in the definition of a parameter, Content-
   Disposition parameters are valid for all dispositions.  (In contrast
   to MIME content-type parameters, which are defined on a per-content-
   type basis.) Thus, for example, the `filename' parameter still means
   the name of the file to which the part should be written, even if the
   disposition itself is unrecognized.

別の方法でパラメタの定義で注意されない場合、すべての気質に、Content気質パラメタは有効です。 (MIME content typeパラメタと対照して。)パラメタは満足しているタイプベースで定義されます。 このようにして、例えば、'ファイル名'パラメタはまだ部分が書かれているべきであるファイルの名前を意味しています、気質自体が認識されていなくても。

2.9  Content-Disposition and Multipart

2.9の満足している気質で複合です。

   If a Content-Disposition header is used on a multipart body part, it
   applies to the multipart as a whole, not the individual subparts.
   The disposition types of the subparts do not need to be consulted
   until the multipart itself is presented.  When the multipart is
   displayed, then the dispositions of the subparts should be respected.

Content-気質ヘッダーが複合身体の部分の上で使用されるなら、それは個々の下位区分ではなく、全体で複合に適用されます。 下位区分のタイプが複合自体まで相談されるために必要としない気質は提示されます。 複合を表示すると、下位区分の気質を尊敬するべきです。

   If the `inline' disposition is used, the multipart should be
   displayed as normal; however, an `attachment' subpart should require
   action from the user to display.

'インライン'の気質が使用されているなら、標準として複合を表示するべきです。 しかしながら、'付属'下位区分はユーザからディスプレイまでの動作を必要とするべきです。

   If the `attachment' disposition is used, presentation of the
   multipart should not proceed without explicit user action.  Once the
   user has chosen to display the multipart, the individual subpart
   dispositions should be consulted to determine how to present the
   subparts.

'付属'気質が使用されているなら、複合のプレゼンテーションは明白なユーザ動作なしで続くはずがありません。 ユーザが、複合を表示するのをいったん選ぶと、個々の下位区分気質は、下位区分を提示する方法を決定するために相談されるべきです。

Troost, et. al.             Standards Track                     [Page 6]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[6ページ]RFC2183

2.10  Content-Disposition and the Main Message

2.10 満足している気質と主なメッセージ

   It is permissible to use Content-Disposition on the main body of an
   [RFC 822] message.

[RFC822]メッセージの本体の上でContent-気質を使用するのは許されています。

3.  Examples

3. 例

   Here is a an example of a body part containing a JPEG image that is
   intended to be viewed by the user immediately:

ここに、aがあります。すぐにユーザによって見られるつもりであるJPEGイメージを含んでいて、ボディーに関する例は離れています:

        Content-Type: image/jpeg
        Content-Disposition: inline
        Content-Description: just a small picture of me

コンテントタイプ: jpeg Contentイメージ/気質: インラインContent-記述: まさしく私の小さい画像

         <jpeg data>

<jpegデータ>。

   The following body part contains a JPEG image that should be
   displayed to the user only if the user requests it. If the JPEG is
   written to a file, the file should be named "genome.jpg".  The
   recipient's user might also choose to set the last-modified date of
   the stored file to date in the modification-date parameter:

以下の身体の部分はユーザがそれを要求する場合にだけユーザに表示されるべきであるJPEGイメージを含んでいます。 JPEGがファイルに書かれるなら、ファイルは"genome.jpg"と命名されるべきです。 また、受取人のユーザは、変更日付のパラメタのこれまでの保存されたファイルの最後変更された期日を決めるのを選ぶかもしれません:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

コンテントタイプ: jpeg Contentイメージ/気質: 付属。 ファイル名はgenome.jpegと等しいです。 「水曜日、1997年2月12日16:29:51 -0500」という変更日付=。 満足している記述: ヒトゲノムの完全な地図

        <jpeg data>

<jpegデータ>。

   The following is an example of the use of the `attachment'
   disposition with a multipart body part.  The user should see text-
   part-1 immediately, then take some action to view multipart-2.  After
   taking action to view multipart-2, the user will see text-part-2
   right away, and be required to take action to view jpeg-1.  Subparts
   are indented for clarity; they would not be so indented in a real
   message.

↓これは複合身体の部分がある'付属'気質の使用に関する例です。 ユーザは、すぐに、テキストパート-1を見て、次に、複合2を見るために何らかの行動を取るべきです。 複合2を見るために行動を取った後に、ユーザは、すぐテキストパート2を見て、視点jpeg-1に行動を取らなければならないでしょう。 下位区分は明快ために字下がりにされます。 それらは本当のメッセージで非常に入り込まれないでしょう。

Troost, et. al.             Standards Track                     [Page 7]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[7ページ]RFC2183

        Content-Type: multipart/mixed; boundary=outer
        Content-Description: multipart-1

コンテントタイプ: 複合か混ぜられる。 境界は外側のContent-記述と等しいです: 複合1

        --outer
          Content-Type: text/plain
          Content-Disposition: inline
          Content-Description: text-part-1

--外側のコンテントタイプ: テキスト/明瞭なContent-気質: インラインContent-記述: テキストパート1

          Some text goes here

何らかのテキストがここに続きます。

        --outer
          Content-Type: multipart/mixed; boundary=inner
          Content-Disposition: attachment
          Content-Description: multipart-2

--外側のコンテントタイプ: 複合か混ぜられる。 境界は内側のContent-気質と等しいです: 付属Content-記述: 複合2

          --inner
            Content-Type: text/plain
            Content-Disposition: inline
            Content-Description: text-part-2

--内側のコンテントタイプ: テキスト/明瞭なContent-気質: インラインContent-記述: テキストパート2

            Some more text here.

ここのそれ以上のテキスト。

          --inner
            Content-Type: image/jpeg
            Content-Disposition: attachment
            Content-Description: jpeg-1

--内側のコンテントタイプ: jpeg Contentイメージ/気質: 付属Content-記述: jpeg-1

            <jpeg data>
          --inner--
        --outer--

内側の<jpegデータ>--外側--

4.  Summary

4. 概要

   Content-Disposition takes one of two values, `inline' and
   `attachment'.  `Inline' indicates that the entity should be
   immediately displayed to the user, whereas `attachment' means that
   the user should take additional action to view the entity.

満足している気質は2つの値、'インライン'、および'付属'の1つを取ります。 'インライン'は、実体がすぐにユーザに表示されるべきであるのを示しますが、'付属'は、ユーザが実体を見るために追加措置を取るべきであることを意味します。

   The `filename' parameter can be used to suggest a filename for
   storing the bodypart, if the user wishes to store it in an external
   file.

bodypartを保存するためにファイル名を示すのに'ファイル名'パラメタを使用できます、ユーザが外部のファイルにそれを保存したいなら。

Troost, et. al.             Standards Track                     [Page 8]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[8ページ]RFC2183

5.  Security Considerations

5. セキュリティ問題

   There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

ユーザがデータを交換する何時でもかかわった安全保障問題があります。 これらを最小にしてはいけない間、どちらも、1つのインスタンス以外に、このメモはそのことについては現状を変えません。

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard. Using UNIX as an example, some hazards
   would be:

このメモが送付者がファイル名を勧める方法を提供するので、受信MUAは、送付者が、ファイル名が危険を表さないことを提案したことに注意しなければなりません。 例としてUNIXを使用して、いくつかの危険は以下の通りでしょう。

   +    Creating startup files (e.g., ".login").

+ 始動を創設すると、(例えば、".login")はファイルされます。

   +    Creating or overwriting system files (e.g., "/etc/passwd").

+ システムファイル(例えば、"/etc/passwd")を作成するか、または上書きすること。

   +    Overwriting any existing file.

+ どんな既存ファイルも上書きすること。

   +    Placing executable files into any command search path
        (e.g., "~/bin/more").

「+ どんなコマンド検索経路にも実行可能なファイルを置く、(」 例えば、~/bin/more、」、)

   +    Sending the file to a pipe (e.g., "| sh").

「+ ファイルをパイプに送る、(」 | 例えば、sh、」、)

   In general, the receiving MUA should not name or place the file such
   that it will get interpreted or executed without the user explicitly
   initiating the action.

一般に、受信MUAは、ユーザなしで明らかに解釈されるか、またはそれが動作を開始しながら実行されるように、ファイルを命名するはずがありませんし、また置くはずがありません。

   It is very important to note that this is not an exhaustive list; it
   is intended as a small set of examples only.  Implementors must be
   alert to the potential hazards on their target systems.

これが完全なりストでないことに注意するのは非常に重要です。 それは小さいセットの例だけとして意図します。 作成者はそれらの目標システムの上の潜在的な危険に注意深いに違いありません。

6.  References

6. 参照

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

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

   [RFC 2184]
        Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
        Character Sets, Lanaguage, and Continuations", RFC 2184, August
        1997.

解放された[RFC2184]、N.、およびK.ムーア、「MIME Parameter価値とEncodedワーズ:」 「文字コード、Lanaguage、および続刊」、RFC2184、8月1997日

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

解放された[RFC2045]、N.、およびN.Borenstein、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式」、RFC2045、1996年12月。

Troost, et. al.             Standards Track                     [Page 9]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[9ページ]RFC2183

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

解放された[RFC2046]、N.、およびN.Borenstein、「パートTwoをまねてください(マルチパーパスインターネットメールエクステンション)」 「メディアタイプ」、RFC2046、1996年12月。

   [RFC 2047]
        Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for non-ASCII Text", RFC 2047,
        December 1996.

ムーア、[RFC2047]K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年12月。

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

解放された[RFC2048]、N.、Klensin、J.、およびJ.ポステル、「パートFourをまねてください(マルチパーパスインターネットメールエクステンション)」 「登録手順」、RFC2048、1996年12月。

   [RFC 2049]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part Five: Conformance Criteria and Examples", RFC
        2049, December 1996.

解放された[RFC2049]、N.、およびN.Borenstein、「パートFiveをまねてください(マルチパーパスインターネットメールエクステンション)」 「順応評価基準と例」、RFC2049、12月1996日

   [RFC 822]
        Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDEL, August 1982.

[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

7.  Acknowledgements

7. 承認

   We gratefully acknowledge the help these people provided during the
   preparation of this draft:

私たちは感謝して、これらの人々がこの草稿の準備の間に提供した助けを承諾します:

        Nathaniel Borenstein
        Ned Freed
        Keith Moore
        Dave Crocker
        Dan Pritchett

ナザニエル・Borensteinネッドはキース・ムーア・デーヴ・医者ダン・プリチェットを解放しました。

Troost, et. al.             Standards Track                    [Page 10]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[10ページ]RFC2183

8.  Authors' Addresses

8. 作者のアドレス

   You should blame the editor of this version of the document for any
   changes since RFC 1806:

あなたはRFC1806以来のどんな変化のためのドキュメントのこのバージョンのエディタも非難するべきです:

        Keith Moore
        Department of Computer Science
        University of Tennessee, Knoxville
        107 Ayres Hall
        Knoxville TN  37996-1301
        USA

キースムーアコンピュータサイエンス学部テネシー、ノクスビル107歌曲ホールノクスビルテネシー大学37996-1301米国

        Phone: +1 (423) 974-5067
        Fax: +1 (423) 974-8296
        Email: moore@cs.utk.edu

以下に電話をしてください。 +1 (423) 974-5067Fax: +1 (423) 974-8296 メールしてください: moore@cs.utk.edu

        The authors of RFC 1806 are:

RFC1806の作者は以下の通りです。

        Rens Troost
        New Century Systems
        324 East 41st Street #804
        New York, NY, 10017 USA

ニューヨーク、Rens Troost新世紀システム324の41番目の東通り#804ニューヨーク10017米国

        Phone: +1 (212) 557-2050
        Fax: +1 (212) 557-2049
        EMail: rens@century.com

以下に電話をしてください。 +1 (212) 557-2050Fax: +1 (212) 557-2049 メールしてください: rens@century.com

        Steve Dorner
        QUALCOMM Incorporated
        6455 Lusk Boulevard
        San Diego, CA 92121
        USA

スティーブ・デルナー・クアルコムの法人組織の6455ラスク・Boulevardカリフォルニア92121サンディエゴ(米国)

        EMail: sdorner@qualcomm.com

メール: sdorner@qualcomm.com

9. Registration of New Content-Disposition Values and Parameters

9. 新しい満足している気質値とパラメタの登録

   New Content-Disposition values (besides "inline" and "attachment")
   may be defined only by Internet standards-track documents, or in
   Experimental documents approved by the Internet Engineering Steering
   Group.

新しいContent-気質値(「インライン」と「付属」以外に)は単にインターネット標準化過程ドキュメント、またはインターネットEngineering Steering Groupによって承認されたExperimentalドキュメントで定義されるかもしれません。

Troost, et. al.             Standards Track                    [Page 11]

RFC 2183                  Content-Disposition                August 1997

et Troost、アル。 1997年8月の満足している気質の標準化過程[11ページ]RFC2183

   New content-disposition parameters may be registered by supplying the
   information in the following template and sending it via electronic
   mail to IANA@IANA.ORG:

新しい満足している気質パラメタは以下のテンプレートで情報を提供して、 IANA@IANA.ORG への電子メールを通してそれを送ることによって、示されるかもしれません:

     To: IANA@IANA.ORG
     Subject: Registration of new Content-Disposition parameter

To: IANA@IANA.ORG Subject: 新しいContent-気質パラメタの登録

     Content-Disposition parameter name:

満足している気質パラメタ名:

     Allowable values for this parameter:
          (If the parameter can only assume a small number of values,
          list each of those values.  Otherwise, describe the values
          that the parameter can assume.)
     Description:
          (What is the purpose of this parameter and how is it used?)

このパラメタのための許容量: (パラメタが少ない数の値を仮定できるだけであるなら、それぞれのそれらの値を記載してください。 さもなければ、パラメタが仮定できる値について説明してください。) 記述: (このパラメタの目的は何であるか、そして、それはどのように使用されますか?)

10. Changes since RFC 1806

10. RFC1806以来の変化

   The following changes have been made since the earlier version of
   this document, published in RFC 1806 as an Experimental protocol:

ExperimentalプロトコルとしてRFC1806で発表されたこのドキュメントの以前のバージョン以来以下の変更は行われています:

   +    Updated references to MIME documents.  In some cases this
        involved substituting a reference to one of the current MIME
        RFCs for a reference to RFC 1521; in other cases, a reference to
        RFC 1521 was simply replaced with the word "MIME".

+ MIMEドキュメントのアップデートされた参照。 いくつかの場合、これは、現在のMIME RFCsの1つのRFC1521の参照の参照を代入することを伴いました。 他の場合では、単にRFC1521の参照を「まねてください」という単語に取り替えました。

   +    Added  a section on registration procedures, since none of the
        procedures in RFC 2048 seemed to be appropriate.

RFC2048の手順のいずれも適切であるように思えなかったので、+は登録手順のセクションを加えました。

   +    Added new parameter types: creation-date, modification-date,
        read-date, and size.

+ 加えられた新しいパラメータの型: 変更日付の、そして、日付を読んでいる作成日付、およびサイズ。

   +    Incorporated a reference to draft-freed-pvcsc-* for encoding
        long or non-ASCII parameter values.

+はpvcsc*のコード化のために草稿無料である長いか非ASCIIのパラメタ値の参照を取り入れました。

   +    Added reference to RFC 2119 to define MUST, SHOULD, etc.
        keywords.

SHOULD、+ 定義するRFC2119の付記された参照はそうしなければならなくて、などはキーワードです。

Troost, et. al.             Standards Track                    [Page 12]

et Troost、アル。 標準化過程[12ページ]