5.2.3.1. General External-Body Parameters 一般 external-body パラメーター

The parameters that may be used with any "message/external-body" are:

どの "message/external-body" とも使えるパラメーターは、次の通りです。

    (1)   ACCESS-TYPE -- A word indicating the supported access
          mechanism by which the file or data may be obtained.
          This word is not case sensitive.  Values include, but
          are not limited to, "FTP", "ANON-FTP", "TFTP", 
          "LOCAL-FILE", and "MAIL-SERVER".  Future values, except for
          experimental values beginning with "X-", must be
          registered with IANA, as described in RFC 2048.
          This parameter is unconditionally mandatory and MUST be
          present on EVERY "message/external-body".

ファイルやデータを得ることが出来る, 対応接続方式を示す言葉。 この言葉は大文字・小文字を区別しません。値は "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE", "MAIL-SERVER" を含みますが、これに限りません。 "X-" で始まる実験用値を除く 将来の値は、 RFC 2048 で説明する通り IANA で登録しなければなりません。 このパラメーターは無条件に必須で、各 "message/external-body" に必ずなければなりません。

    (2)   EXPIRATION -- The date (in the RFC 822 "date-time"
          syntax, as extended by RFC 1123 to permit 4 digits in
          the year field) after which the existence of the
          external data is not guaranteed.  This parameter may be
          used with ANY access-type and is ALWAYS optional.

それ以降外部データの存在が保証されなくなる日付 (RFC 822 の "date-time" 構文の、 RFC 1123 で4桁年号を使えるように 拡張したもので)。このパラメーターはどの access-type でも使うことが出来て、常に省略可能です。

    (3)   SIZE -- The size (in octets) of the data.  The intent
          of this parameter is to help the recipient decide
          whether or not to expend the necessary resources to
          retrieve the external data.  Note that this describes
          the size of the data in its canonical form, that is,
          before any Content-Transfer-Encoding has been applied
          or after the data have been decoded.  This parameter
          may be used with ANY access-type and is ALWAYS
          optional.

データの大きさ (オクテットで)。このパラメーターの意図は、 外部データを取り出すのに必要な資源を費やすかどうか 受取人が決めるのを助けることです。なお、ここでは 正規形のデータの大きさ、つまり CTE を施す前や データを復号した後のものを記述します。このパラメーターはどの access-type でも使うことが出来て、常に省略可能です。

    (4)   PERMISSION -- A case-insensitive field that indicates
          whether or not it is expected that clients might also
          attempt to overwrite the data.  By default, or if
          permission is "read", the assumption is that they are
          not, and that if the data is retrieved once, it is
          never needed again.  If PERMISSION is "read-write",
          this assumption is invalid, and any local copy must be
          considered no more than a cache.  "Read" and 
          "Read-write" are the only defined values of permission.  This
          parameter may be used with ANY access-type and is
          ALWAYS optional.

クライアントがデータを上書きしようとも出来るかどうかを示す、 大文字・小文字を区別しない領域。既定値または permission が "read" の場合、出来ないと仮定し、データを一度取り出せば、 二度とまた取り出す必要はありません。 PERMISSION が "read-write" の場合は、この仮定は出来ず、 local な複製はキャッシュ以上の 何者でもないと考えなければなりません。 "Read" と "Read-write" だけが定義された permission の値です。このパラメーターはどの access-type でも使うことが出来て、常に省略可能です。

The precise semantics of the access-types defined here are described in the sections that follow.

ここで定義した access-typeの正確な意味は、以降の節で説明します。

5.2.3.2. The 'ftp' and 'tftp' Access-Types

An access-type of FTP or TFTP indicates that the message body is accessible as a file using the FTP [RFC-959] or TFTP [RFC-783] protocols, respectively. For these access-types, the following additional parameters are mandatory:

FTP や TFTP の access-type は、メッセージ本文がそれぞれ FTP や TFTP のプロトコルを使って接続出来ることを示します。これらの access-type には、次の追加のパラメーターが必須です。

(1) NAME -- The name of the file that contains the actual body data.

実際の本文データを含むファイルの名前

(2) SITE -- A machine from which the file may be obtained, using the given protocol. This must be a fully qualified domain name, not a nickname.

指定されたプロトコルを使ってファイルを得ることが出来る機械。 これは愛称ではなく、完全修飾ドメイン名でなければなりません。

(3) Before any data are retrieved, using FTP, the user will generally need to be asked to provide a login id and a password for the machine named by the site parameter. For security reasons, such an id and password are not specified as content-type parameters, but must be obtained from the user.

データを取り出す前に、 FTP を使う場合、 site パラメーターで名前指定された機械のログイン識別子と合言葉 を示すよう利用者に尋ねる必要が通常あります。 安全性の理由から、この識別子と合言葉は content-type パラメーター として指定しませんが、利用者から得なければなりません。

In addition, the following parameters are optional:

加えて、次の省略可能なパラメーターを使用出来ます。

(1) DIRECTORY -- A directory from which the data named by NAME should be retrieved.

NAME で名前指定されたデータを取り出すディレクトリ。

(2) MODE -- A case-insensitive string indicating the mode to be used when retrieving the information. The valid values for access-type "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the TFTP protocol [RFC-783]. The valid values for access-type "FTP" are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a decimal integer, typically 8. These correspond to the representation types "A" "E" "I" and "L n" as specified by the FTP protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid values for MODE and that "OCTET" or "IMAGE" or "LOCAL8" should be used instead. IF MODE is not specified, the default value is "NETASCII" for TFTP and "ASCII" otherwise.

情報を取り出すときに使う状態を示す、大文字・小文字を区別しない文字列。 Access-type "TFTP" で可能な値は、 "NETASCII", "OCTET", "MAIL" で、 TFTP プロトコルで規定されています。 Access-type "FTP" で有効な値は、 "ASCII", "EBCDIC", "IMAGE", "LOCALn" (ここで "n" は整数値で、典型的には 8) です。これらは FTP プロトコルで規定された 表現形 "A" "E" "I" "L n" に対応します。なお、 "BINARY" と "TENEX" は MODE では妥当な値ではなく、 "OCTET" か "IMAGE" か "LOCAL8" を代わりに使うべきです。 MODE が指定されていない場合、既定値は TFTP では "NETASCII", そうでなければ "ASCII" です。

RFC 1341 では、

MODE -- A transfer mode for retrieving the information, e.g. "image".

これだけの定義でした。ですから、 "BINARY", "TENEX" は実際に 使われていた値かもしれません。 ]]

5.2.3.3. The 'anon-ftp' Access-Type

The "anon-ftp" access-type is identical to the "ftp" access type, except that the user need not be asked to provide a name and password for the specified site. Instead, the ftp protocol will be used with login "anonymous" and a password that corresponds to the user's mail address.

"anon-ftp" access-type は、 "ftp" 接続型と同等ですが、 利用者は指定されたサイトの名前と合言葉を尋ねられることはありません。 代わりに、 ftp プロトコルは login "anonymous" と、 利用者のメイル・アドレスに対応する合言葉を使います。

5.2.3.4. The 'local-file' Access-Type

An access-type of "local-file" indicates that the actual body is accessible as a file on the local machine. Two additional parameters are defined for this access type:

"local-file" の access-type は、実際の本文が local 機械の ファイルとして接続可能であることを示します。2つの追加のパラメーターを この接続型に定義します。

RFC 1521

An access-type of "afs" indicates that the file is accessible via the global AFS file system.

"afs" の access-type は、ファイルが広域 AFS ファイル系から 入手可能であることを示します。、

]]

    (1)   NAME -- The name of the file that contains the actual
          body data.  This parameter is mandatory for the
          "local-file" access-type.

実際の本文データを含むファイルの名前。このパラメーターは "local-file" access-type には必須です。

    (2)   SITE -- A domain specifier for a machine or set of
          machines that are known to have access to the data
          file.  This optional parameter is used to describe the
          locality of reference for the data, that is, the site
          or sites at which the file is expected to be visible.
          Asterisks may be used for wildcard matching to a part
          of a domain name, such as "*.bellcore.com", to indicate
          a set of machines on which the data should be directly
          visible, while a single asterisk may be used to
          indicate a file that is expected to be universally
          available, e.g., via a global file system.

データ・ファイルへの接続があると知られている機械あるいは 機械の集合のドメイン指定子。この省略可能なパラメーターは、 データの参照の local さ、つまりファイルが可視状態にあると 思われるサイトを指定するのに使います。米印は、 "*.bellcore.com" のようにドメイン名の部分に合致するワイルドカードに使うことが出来て、 データが直接可視である機械の集合を示しますし、単一の米印は ファイルが普遍的に利用可能 (例: 広域ファイル系を通して。) であることを示すのに使うことが出来ます。

5.2.3.5. The 'mail-server' Access-Type

The "mail-server" access-type indicates that the actual body is available from a mail server. Two additional parameters are defined for this access-type:

"Mail-server" access-type は、実際の本文がメイル・サーバーから 入手可能であることを示します。2つの追加のパラメーターを この access-type に定義します。

    (1)   SERVER -- The addr-spec of the mail server from which
          the actual body data can be obtained.  This parameter
          is mandatory for the "mail-server" access-type.

実際の本文データを得ることが出来るメイル・サーバーの addr-spec。このパラメーターは "mail-server" access-type には必須です。

    (2)   SUBJECT -- The subject that is to be used in the mail
          that is sent to obtain the data.  Note that keying mail
          servers on Subject lines is NOT recommended, but such
          mail servers are known to exist.  This is an optional
          parameter.

データを得る為に送信するメイルに使われる subject。 Subject 行をメイル・サーバーの鍵にするのは推奨しませんが、 そうしたメイル・サーバーが存在することが知られています。 これは省略可能なパラメーターです。

 Because mail servers accept a variety of syntaxes, some of which is
   multiline, the full command to be sent to a mail server is not
   included as a parameter in the content-type header field.  Instead,
   it is provided as the "phantom body" when the media type is
   "message/external-body" and the access-type is mail-server.

メイル・サーバーは複数行とか種種の構文を受け付けますから、 メイル・サーバーに送る完全な命令は content-type 頭領域のパラメーターに含めません。代わりに、媒体型が "message/external-body" で access-type が mail-server の際には「見かけの本文」を利用出来ます。

   Note that MIME does not define a mail server syntax.  Rather, it
   allows the inclusion of arbitrary mail server commands in the phantom
   body.  Implementations must include the phantom body in the body of
   the message it sends to the mail server address to retrieve the
   relevant data.

なお、 MIME はメイル・サーバーの構文を定義しません。 むしろ、任意のメイル・サーバー命令を見かけの本文に含めることが 出来ます。実装は、見かけの本文を、 適切なデータを得る為に、メイル・サーバー・アドレスに送る メッセージの本文中に含めなければなりません。

   Unlike other access-types, mail-server access is asynchronous and
   will happen at an unpredictable time in the future.  For this reason,
   it is important that there be a mechanism by which the returned data
   can be matched up with the original "message/external-body" entity.
   MIME mail servers must use the same Content-ID field on the returned
   message that was used in the original "message/external-body"
   entities, to facilitate such matching.

他の access-type とは異なり、 mail-server 接続は非同期で、 将来の予期せぬ時に起こり得ます。この理由から、返送されたデータを 元の "message/external-body" 実体に対応させることが出来る方法が あることが重要になります。 MIME メイル・サーバーは、この一致確認んのため、 返送メッセージに元の "message/external-body" 実体で使われたのと同じ Content-ID 領域を使わなければなりません。

5.2.3.6. External-Body Security Issues

"Message/external-body" entities give rise to two important security issues:

"message/external-body" 実体は、2つの重大な安全性問題を起こします。

    (1)   Accessing data via a "message/external-body" reference
          effectively results in the message recipient performing
          an operation that was specified by the message
          originator.  It is therefore possible for the message
          originator to trick a recipient into doing something
          they would not have done otherwise.  For example, an
          originator could specify a action that attempts
          retrieval of material that the recipient is not
          authorized to obtain, causing the recipient to
          unwittingly violate some security policy.  For this
          reason, user agents capable of resolving external
          references must always take steps to describe the
          action they are to take to the recipient and ask for
          explicit permisssion prior to performing it.

"message/external-body" 参照を通してデータに接続することは、 実質的に、メッセージ作成者が指定した処理をメッセージ受信者が行う ことになります。ですから、作成者が、受信者がそうでもなければ しないだろうことを受信者にさせることが可能です。例えば、 作成者は受信者が得る権限の無いものを得ようとして、 受信者が無意識に安全性の方針を破ることになる行動を指定する ことが出来ます。この理由から、外部参照を解決する能力のある利用者代理者は、 必ず起こそうとしている行動を受信者に説明する段階を踏んで、 行う前に明示的な許可を求めなければなりません。

          The 'mail-server' access-type is particularly
          vulnerable, in that it causes the recipient to send a
          new message whose contents are specified by the
          original message's originator.  Given the potential for
          abuse, any such request messages that are constructed
          should contain a clear indication that they were
          generated automatically (e.g. in a Comments: header
          field) in an attempt to resolve a MIME
          "message/external-body" reference.

'mail-server' access-type は、元のメッセージの送信者 が指定した内容の新しいメッセージを受信者が送信することになりますから、 特に脆弱です。乱用の可能性があるので、そうして組み立てられる 要求メッセージには、 MIME "message/external-body" 参照の 解決のために自動的に生成されたことの明示を (例: Comments: 頭領域中に) 含めるべきです。

    (2)   MIME will sometimes be used in environments that
          provide some guarantee of message integrity and
          authenticity.  If present, such guarantees may apply
          only to the actual direct content of messages -- they
          may or may not apply to data accessed through MIME's
          "message/external-body" mechanism.  In particular, it
          may be possible to subvert certain access mechanisms
          even when the messaging system itself is secure.

          It should be noted that this problem exists either with
          or without the availabilty of MIME mechanisms.  A
          casual reference to an FTP site containing a document
          in the text of a secure message brings up similar
          issues -- the only difference is that MIME provides for
          automatic retrieval of such material, and users may
          place unwarranted trust is such automatic retrieval
          mechanisms.

5.2.3.7. Examples and Further Explanations 例と補足説明

   When the external-body mechanism is used in conjunction with the
   "multipart/alternative" media type it extends the functionality of
   "multipart/alternative" to include the case where the same entity is
   provided in the same format but via different accces mechanisms.
   When this is done the originator of the message must order the parts
   first in terms of preferred formats and then by preferred access
   mechanisms.  The recipient's viewer should then evaluate the list
   both in terms of format and access mechanisms.

   With the emerging possibility of very wide-area file systems, it
   becomes very hard to know in advance the set of machines where a file
   will and will not be accessible directly from the file system.
   Therefore it may make sense to provide both a file name, to be tried
   directly, and the name of one or more sites from which the file is
   known to be accessible.  An implementation can try to retrieve remote
   files using FTP or any other protocol, using anonymous file retrieval
   or prompting the user for the necessary name and password.  If an
   external body is accessible via multiple mechanisms, the sender may
   include multiple entities of type "message/external-body" within the
   body parts of an enclosing "multipart/alternative" entity.

   However, the external-body mechanism is not intended to be limited to
   file retrieval, as shown by the mail-server access-type.  Beyond
   this, one can imagine, for example, using a video server for external
   references to video clips.

   The embedded message header fields which appear in the body of the
   "message/external-body" data must be used to declare the media type
   of the external body if it is anything other than plain US-ASCII
   text, since the external body does not have a header section to
   declare its type.  Similarly, any Content-transfer-encoding other
   than "7bit" must also be declared here.  Thus a complete
   "message/external-body" message, referring to an object in PostScript
   format, might look like this:

     From: Whomever
     To: Someone
     Date: Whenever
     Subject: whatever
     MIME-Version: 1.0
     Message-ID: <id1@host.com>
     Content-Type: multipart/alternative; boundary=42
     Content-ID: <id001@guppylake.bellcore.com>
     
     --42
     Content-Type: message/external-body; name="BodyFormats.ps";
                   site="thumper.bellcore.com"; mode="image";
                   access-type=ANON-FTP; directory="pub";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
     
     Content-type: application/postscript
     Content-ID: <id42@guppylake.bellcore.com>
     
     --42
     Content-Type: message/external-body; access-type=local-file;
                   name="/u/nsb/writing/rfcs/RFC-MIME.ps";
                   site="thumper.bellcore.com";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
     
     Content-type: application/postscript
     Content-ID: <id42@guppylake.bellcore.com>
     
     --42
     Content-Type: message/external-body;
                   access-type=mail-server
                   server="listserv@bogus.bitnet";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
     
     Content-type: application/postscript
     Content-ID: <id42@guppylake.bellcore.com>
     
     get RFC-MIME.DOC
     
     --42--

   Note that in the above examples, the default Content-transfer-
   encoding of "7bit" is assumed for the external postscript data.

   Like the "message/partial" type, the "message/external-body" media
   type is intended to be transparent, that is, to convey the data type
   in the external body rather than to convey a message with a body of
   that type.  Thus the headers on the outer and inner parts must be
   merged using the same rules as for "message/partial".  In particular,
   this means that the Content-type and Subject fields are overridden,
   but the From field is preserved.

   Note that since the external bodies are not transported along with
   the external body reference, they need not conform to transport
   limitations that apply to the reference itself. In particular,
   Internet mail transports may impose 7bit and line length limits, but
   these do not automatically apply to binary external body references.
   Thus a Content-Transfer-Encoding is not generally necessary, though
   it is permitted.

   Note that the body of a message of type "message/external-body" is
   governed by the basic syntax for an RFC 822 message.  In particular,
   anything before the first consecutive pair of CRLFs is header
   information, while anything after it is body information, which is
   ignored for most access-types.

RFC 1521

The formal grammar for content-type header fields for data of type message is given by:

   message-type := "message" "/" message-subtype

   message-subtype := "rfc822"
                   / "partial" 2#3partial-param
                   / "external-body" 1*external-param
                   / extension-token

   partial-param :=     (";" "id" "=" value)
              /  (";" "number" "=" 1*DIGIT)
              /  (";" "total" "=" 1*DIGIT)
         ; id & number required; total  required  for  last part

   external-param :=   (";" "access-type" "=" atype)
              / (";" "expiration" "=" date-time)
                   ; Note that date-time is quoted
              / (";" "size" "=" 1*DIGIT)
              / (";"  "permission"  "="  ("read"  /  "read-write"))
                   ; Permission is case-insensitive
              / (";" "name" "="  value)
              / (";" "site" "=" value)
              / (";" "dir" "=" value)
              / (";" "mode" "=" value)
              / (";" "server" "=" value)
              / (";" "subject" "=" value)
          ; access-type required;others required based on access-type

   atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
                  / "afs" / "mail-server" / extension-token
                  ; Case-insensitive

]]