2.1 The Inline Disposition Type Inline (行内) 配置型

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.

本体部分がメッセージの表示で自動的に表示されることを意図しているなら、「inline」 (行内) として印をつけるのが良いです。 Inline の本体部分はその出現順に提示され、普通の意味の複数部分メッセージに準じるのが良いです。

2.2 The Attachment Disposition Type (Attachment (添付) 配置型

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.

本体部分はメイル・メッセージの主要な本体とは区別されることを示すため、「attachment」 (添付) と印をつけることができます。 これは自動的に表示されるのは望ましくなく、利用者の何らかの操作で表示されるのが良いです。 MUA は画像端末では代わりに添付を表す絵を利用者に提示しても良いですし、あるいは文字端末では利用者が表示や保管を選択できる添付物の表を 見せるのも良いでしょう。

2.3 The Filename Parameter Filename (ファイル名) パラメーター

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 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 は、示されたファイル名を盲信して使わないことが重要です。 示されたファイル名について、受信側のファイル系統の慣習に沿っているか、既存のファイルを上書きしてしまわないか、安全上の問題を起こさないかを確認 (後の安全性に関してを参照。) し、 (必要なら変更) するべきです。

The receiving MUA should not 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 は filename 引数中にみられるディレクトリ経路情報を尊重するべきではありません。 ファイル名は最後の部分だけを使うのが良いです。 ディレクトリ経路の指定は別の Content-Disposition 引数として将来定義されるかもしれませんが、この原案ではその予定はありません。

Current [RFC 1521] [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] (注 : 修正漏れで、 RFC 2045 であるべきはず。) `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.

現在の MIME の文保言うは引数値を US-ASCII に制限しています (から、 Content-Disposition ファイル名も制限されます)。 ファイル名に任意の文字集合を認めることは非常に望ましいことであると認識していますが、 それに必要な機構を定義することはこの文書の適用範囲外です。 基本 MIME value 仕様がいつの日か改訂されて非 US-ASCII 文字を使うことが認められることを期待しまして、 その時には同じ機構が Content-Disposition filename 引数中で使うべきです。

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.

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

filename 引数が示されていることは実装が実体を分離したファイルとして書き出すことを強制するものではありません。 実装が、利用者が別途要求しない限り実体を通常のメイル流の一部としておくことは全くもって認められます。 ですから、この引数はどんな MIME 実体でも、たとえ inline のものであっても使うことができます。 それらは通常はファイルには書き出しませんが、 受信した利用者がその部分をファイルに書き出すことを選んだときにファイル名を提供するのに使うことができるでしょう。

2.4 2.8 Future Extensions and Unrecognized Disposition Types 拡張と認識出来ない配置型

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

新しい引数や配置型が必要になった時には、 Internet 登録番号事務局 (IANA) に、RFC 1521 の附属書 E このメモの第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-token が使えるので、実装は全く登録されていない配置型やパラメーターにも遭遇するかもしれません。

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.

認識出来ないパラメーターは無視するのがよいです。 認識出来ない配置型は「attachment」として扱うのがよいです。 ここで認識出来ない型に「attachment」を選ぶのは、新しい配置型の Content-Disposition 頭を使うことになる送信者はおそらく何か inline 表現より込み入ったことを狙っているだろうからです。

Unless noted otherwise in the definition of a parameter, Content-Disposition parameters are valid for all dispositions. (In contrast to [RFC 1521] 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-Disposition パラメーターは全ての配置型について有効です。 (対照的に MIME 内容型 (content-type) パラメーターは内容型毎を基本としています。) ですから例えば「filename」パラメーターは、配置型自体が認識出来ないものであっても依然としてその部分を書き出す時に使うべきファイルの名前を意味します。

2.9 Content-Disposition and Multipart Content-Disposition と多部分

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-Disposition 頭が多部分本体部分で使われるときは、 個々の小部分ではなく多部分全体に適用されます。 小部分の配置型は多部分自体が提示されるまでは調べる必要はありません。 多部分が表示される時には、小部分の配置が反映されるべきです。

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.

inline 配置が使われるときは、多部分は通常のように表示するべきです。 しかし、 attachment 小部分は表示するためには利用者の動作が必要となるべきです。

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.

attachment 配置が使われる時には、多部分の表現は陽な利用者の動作なしに進めるべきではありません。 ひとたび利用者が多部分を表示すると選んだ時には、 個々の小部分配置を調べて小部分をどう表現するかを決定するべきです。

2.6 2.10 Content-Disposition and the Main Message Content-Disposition と主メッセージ

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

Content-Disposition を RFC 822 メッセージの主本体に使うことは認められます、

3. Examples 例

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

ここに利用者に即座に表示されることを意図した JPEG 画像を含んだ本体部分の例を示します。

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

<jpeg data>

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" とするべきです。 受信した利用者は蓄積ファイルの最終編集日を modification-date 引数の日付とすることも選ぶかもしれません。

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.

次は「attachment」配置を複数部分本体で使う例です。 利用者は text-part-1 をすぐに見るのが望ましく、 multipart-2 を表示すのには何らかの動作を取るべきです。 multipart-2 を表示する動作をとった後、利用者は text-part-2 をすぐに見ることが出来るでしょう。 そして jpeg-1 を表示するのには動作が必要でしょう。 亜部は分かりやすいように字下げしていますが、実際のメッセージではこうは字下げしません。

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

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

          Some text goes here 何か文章がここに来る

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

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

            Some more text here. 何か文章が更にここに来る。

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

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