Edit

Page

Page title:

Page body:

* 仕様書

[REFS[
- [6] '''[CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-5.2.3>'''
- [2] [CITE[RFC Errata Report]] ([TIME[2015-05-14 17:06:47 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=2046>
]REFS]

* 意味

[7] [CODE(MIME)@en[[[message/external-body]]]] は、
実際の本体データが含まれず、参照だけ含まれていることを示します [SRC[>>6]]。

[20] [CODE(MIME)@en[[[message/external-body]]]] はその参照するデータを「透過的」
に表すもので、外部参照するメッセージ自身を表すものではありません [SRC[>>6]]。

;; [CODE(MIME)@en[[[message/partial]]]] も参照。

* 構文

[8] [[本体]]は、カプセル化されたメッセージの[[ヘッダー]]と、[[空行]]です。
その後に [[phantom body]] を含めることもできます。 [SRC[>>6]]

[FIG(railroad)[
= [[ヘッダー]]
= [[空行]]
= [[phantom body]]
]FIG]

;; [10] ここの[[ヘッダー]] (カプセル化されたヘッダー) は、これを含む外側[[MIME実体]]の[[ヘッダー]]とは別です。
外部実体の参照方法を記述するのは、外側[[MIME実体]]の[[ヘッダー]]の
[CODE(MIME)@en[[[Content-Type:]]]] です。こちらの[[ヘッダー]]は、
取得される[[実体]]の[[ヘッダー]]です。

[11] カプセル化されたヘッダーには、 [CODE(MIME)@en[[[Content-ID:]]]]
[[ヘッダー]]がなければ[['''なりません''']] [SRC[>>6]]。

;; [12] これは[[キャッシュ]]に使うことができますし、
[CODE[[[access-type]]]] 依存の方法で使われることがあります [SRC[>>6]]。

[9] [DFN[[[phantom body]]]] は、ほとんどの場合は無視されますが、
[CODE[[[access-type]]]] によっては補助情報を含めることができます [SRC[>>6]]。

;; [23] [[ヘッダー]]は、 [[phantom body]] に適用されるものではなく、
外部データを記述するものです。例えば [CODE(MIME)@en[[[Content-Tranfer-Encoding:]]]]
を指定しても、それは [[phantom body]] について記述したことにはなりません。

* 引数

[15] 次の[[引数]]があります。
[FIG(short list)[
- [CODE(MIME)@en[[[access-type]]]]
- [CODE(MIME)@en[[[directory]]]]
- [CODE(MIME)@en[[[expiration]]]]
- [CODE(MIME)@en[[[mode]]]]
- [CODE(MIME)@en[[[name]]]]
- [CODE(MIME)@en[[[permission]]]]
- [CODE(MIME)@en[[[server]]]]
- [CODE(MIME)@en[[[site]]]]
- [CODE(MIME)@en[[[size]]]]
- [CODE(MIME)@en[[[subject]]]]
]FIG]

,dir	,value	,(ディレクトリ名)	,?	,[MIME]
,url	,value	,URL	,url	,RFC 2017

dir パラメーターは、 RFC 1521 の BNF にだけ定義されています。
directory の誤植みたいですが、仕方無いので実装は
これにも対応していた方が良いかもしれません。

local-file, aftp では、 site パラメーターの値は
domain / aste-domain

[16] [CODE(MIME)@en[[[access-type]]]] は必須です [SRC[>>6]]。

* CTE

[13] [CODE(MIME)@en[[[message/external-body]]]] [[実体]]は、 [[CTE]]
が [CODE(MIME)@en[[[7bit]]]] でなければ[['''なりません''']] [SRC[>>6]]。

;; [14] 参照されている[[実体]]の制約ではありません。

* アクセス型

[1] [CODE(MIME)@en[[[message/external-body]]]] の参照先は、
[CODE(MIME)@en[[[access-type]]]] [[引数]]の値 ([[アクセス型]]) により決まります。

;; [[アクセス型]]を参照。

* "Content-ID" 接続型

RFC 1873 <urn:ietf:rfc:1873> 
(訳 <http://suika.fam.cx/~wakaba/document/rfc-ja/rfc1873-ja>)
で定義されています。

''同じメッセージ中''の他の他部分実体を参照するのに使います。

パラメーターは定義されていません。 RFC 1873 では必須のパラメーター
無しとなっていますが、当然 access-type が必要です。

参照先 CID は、 message/external-body の''外側の実体の頭''
の [[Content-ID:領域]]に書くようです。 external-body 内部の
頭ではありません。

しかし、 MIME (RFC 1521, 2046) によれば、内部の頭での
CID 領域が必須です。実装は外側に CID が無い場合に、
内側に CID がないか確認して、あればそれを使うのが良さげです。

逆に、送信側実装は、外側と同じ CID を内側にも入れると
良いかもしれませんけど、よく分かりません。
(外側 CID は本来的には、 message/external-body 実体の
ID なんですよね? だからそこを参照先 CID に使うのが
間違ってるような。)

* "URL" 接続型

RFC 2017 <urn:ietf:rfc:2017> で定義されてます。 BNF は次の通り。

= URL-parameter := <"> URL-word *(*LWSP-char URL-word) <">
= URL-word := token ; Must not exceed 40 characters in length

RFC 2017 から抜粋。

[PRE[
    (1)   A check is made to make sure that all occurrences of
          SPACE, CTLs, double quotes, backslashes, and 8-bit
          characters in the URL string are already encoded using
          the URL encoding scheme specified in RFC 1738. Any
          unencoded occurrences of these characters must be
          encoded.  Note that the result of this operation is
          nothing more than a different representation of the
          original URL.
]PRE]

URL 文字列中の SPACE, CTL, 二重引用符, 逆斜線, 8ビット文字
が既に RFC 1738 で規定されている URL 符号化方式で符号化されているか
確認する。符号化されていないこれらの文字があれば、符号化
しなければなりません。この捜査の結果は元の URL の違った表現に
過ぎないことに注意して下さい。

[[訳注: SP / CTL / <"> / "\" / %x80-FF は、 URI/URL]]
中では(URI 符号化しないと)使えません。けど、実際にはしばしば
そういうのが使われてます。 ("URL" 接続型では使われてないとは
思いますが・・・。) ですから、この確認はほとんどの場合で必須です。]]

(2)   The resulting URL string is broken up into substrings
of 40 characters or less.

結果の URL 文字列を40文字以下の小文字列に分割する。

[PRE[
    (3)   Each substring is placed in a URL-parameter string as a
          URL-word, separated by one or more spaces.  Note that
          the enclosing quotes are always required since all URLs
          contain one or more colons, and colons are tspecial
          characters [RFC 1521].
]PRE]

各小文字列を URL-parameter 文字列中に、
一つ以上の間隔で区切られた URL-word として入れる。
URL は1つ以上のコロンを含み、コロンは tspecial 文字ですから、
囲み引用符は常に必要であることに注意して下さい。

Extraction of the URL string from the URL-parameter is even simpler:
The enclosing quotes and any linear whitespace are removed and the
remaining material is the URL string.

URL 文字列を URL-parameter から取り出すのはより簡単です。
囲んでいる引用符と行空白間隔を取り除けば、残ったものが
URL 文字列です。

(引用・翻訳ここまで)

RFC 2017 は RFC 2231 の方法が規定される前ですから、こうした仕様に
なってます。ですが、現在では普通に URL を(実際の)パラメーター値
とする RFC 2231 方式の拡張パラメーターにするのが良いかもしれません。

空白を入れつつも RFC 2231 方式で分割するのは、
みっともないのであまり宜しくないと思います。けど、解釈する
実装はそういうのにも対応するべきでしょう。

特に HTTP なんかだと、 URL と実際のデータが一対一対応していないことが
よくあります。 RFC 2017 によると、取り寄せたデータと
external-body 本文に書いてある content-type が一致する場合のみ
そのデータを使える (正しいと見なせる) としています。

実装は、場合によっては CT だけでなくて Content-Language とかも
同様の扱いにするのが良いと思われます。それから、取り寄せ時に HTTP
なら [[Accept:領域]]や[[Accept-Language:領域]]を使うようにする
のが良いと思います。

* 処理

[17] 処理方法は、[[アクセス型]]によります。

[21] [CODE(MIME)@en[[[message/external-body]]]] を含むメッセージの「外側」
ヘッダーと、参照される「内側」ヘッダーは、
[CODE(MIME)@en[[[message/partial]]]] と同じ規則により併合しなければなりません [SRC[>>6]]。

[18] 受信した[[利用者エージェント]]が自動的に処理すると、
受信者が意図しない行為を[[送信者]]が指示できてしまうかもしれません。
従って[[利用者エージェント]]は明示的に[[受信者]]の確認を得てから取得するべきです。
[SRC[>>6]]

[19] 悪意のある送信者は、受信者の行為を追跡する意図を持っているかもしれませんから、
注意が必要です。

* 例

RFC 1486, 1528 に例が載ってます。 (別に external-body の例として
載ってるわけではありませんけどねー)

[PRE[
      MIME-Version: 1.0
      Content-Type: multipart/alternative;
              boundary="----- =_aaaaaaaaaa0"
      Content-Description:  pointers to ftp and e-mail access
]PRE]

[PRE[
      ------- =_aaaaaaaaaa0
      Content-Type: message/external-body;
              access-type="mail-server";
              server="archive-server@ftp.ics.uci.edu"
]PRE]

[PRE[
      Content-Type: application/octet-stream; type="tar";
              x-conversions="x-compress"
      Content-ID: <4599.735726126.1@dbc.mtview.ca.us>
]PRE]

[PRE[
      mimesend mrose/tpc/rp.tar.Z
]PRE]

[PRE[
      ------- =_aaaaaaaaaa0
      Content-Type: message/external-body;
              access-type="anon-ftp"; name="rp.tar.Z";
              directory="mrose/tpc"; site="ftp.ics.uci.edu"
]PRE]

[PRE[
      Content-Type: application/octet-stream; type="tar";
              x-conversions="x-compress"
      Content-ID: <4599.735726126.2@dbc.mtview.ca.us>
]PRE]

[PRE[
       ------- =_aaaaaaaaaa0--
]PRE]

CID の例

[PRE[
            MIME-Version: 1.0
            Content-Type: Multipart/Mixed;
               boundary=tiger-lily
]PRE]

[PRE[
            --tiger-lily
            Content-Type: image/jpeg
            Content-ID: <950323.1552@XIson.com>
]PRE]

[PRE[
            AAAcdb...
            --tiger-lily
            Content-type: Message/External-Body;
               access-type=content-id
            Content-ID: <950323.1552@XIson.com>
            Content-Description:
               This body part is duplicated by reference
]PRE]

[PRE[
            --tiger-lily--
]PRE]

RFC 1521, 2046 では message/external-body の内側の頭で
CID が必須です。ですから、最終部分は次のようにするのが
正しいことになります。

[PRE[
            --tiger-lily
            Content-type: Message/External-Body;
               access-type=content-id
            Content-ID: <950323.1552@XIson.com>
            Content-Description:
               This body part is duplicated by reference
            
            Content-ID: <some.content.id@external.body.example>
            --tiger-lily--
]PRE]

上の "Content-ID" 接続型の説明も参照してください。

URL の例

[PRE[
     Content-type: message/external-body; access-type=URL;
                   URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/
                        8/9/10/11/12/13/14/15/16/17/18/20/21/
                        file.html"
]PRE]

[PRE[
     Content-type: text/html
     Content-Transfer-Encoding: binary
]PRE]

[PRE[
     THIS IS NOT REALLY THE BODY!
]PRE]

なお、これは RFC 1521/2046 的には間違いです。 (上の例参照)

RFC 2231 の方法を使うと、

[PRE[
        Content-Type: message/external-body; access-type=URL;
          URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
]PRE]

は次のようにも表せます。

[PRE[
        Content-Type: message/external-body; access-type=URL;
         URL*0="ftp://";
         URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
]PRE]

* その他

** RFC 1864 ([[Content-MD5:領域]])

The Content-MD5 header may
also be placed in the encapsulated headers of an object of type
message/external-body, to be used to verify that the retreived and
decoded data are the same data that were initially referenced.

Content-MD5 頭は、 message/external-body 型の物体のカプセル化された頭
にも置くことが出来ます。取り出して復号したデータが最初に参照していた
データと同じ物であるかを確認するのに使います。

** RFC 1867 (HTML の FORM) 5.7 Remote files with third-party transfer 第3者転送を使った遠隔ファイル

[PRE[
   In some scenarios, the user operating the client software might want
   to specify a URL for remote data rather than a local file. In this
   case, is there a way to allow the browser to send to the client a
   pointer to the external data rather than the entire contents? This
   capability could be implemented, for example, by having the client
   send to the server data of type "message/external-body" with
   "access-type" set to, say, "uri", and the URL of the remote data in
   the body of the message.
]PRE]

幾つかの筋書きでは、クライアント・ソフトウェアを操作する利用者
は遠隔データに local ファイルではなく遠隔データの URL
を指定したいと思うかもしれません。この場合、閲覧者が
クライアントに内容全体ではなく外部データ参照を送る方法はあるでしょうか。
この機能は。例えばクライアントがサーバーにデータを型
"message/external-body" で "access-type" を "uri" にして、
メッセージの本文中に遠隔データの URL を入れることで実装出来ます。

* 非互換性

RFC 1341 と 1521/2046 では、内側の Content-ID についての規定が
違います。 (1341 では必須でない。) "Content-ID" 接続型
の節などを参照。

実際の外部実体を統合する場合の手順が、 RFC 1341/1521/2046
でそれぞれ微妙に違います。但し、 external-body
ではあまり影響はないでしょう。 [[message/partial媒体型]]参照。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[22] RFC 2046 5.2.3.  External-Body Subtype
]FIGCAPTION]

The external-body subtype indicates that the actual body data are not
included, but merely referenced.  In this case, the parameters
describe a mechanism for accessing the external data.

external-body 亜型は、実際の本文データが含まれておらず、単に参照されている
だけであることを示します。この場合、パラメーターに外部データに接続する
方法を指定します。

When a MIME entity is of type "message/external-body", it consists of
a header, two consecutive CRLFs, and the message header for the
encapsulated message.  If another pair of consecutive CRLFs appears,
this of course ends the message header for the encapsulated message.
However, since the encapsulated message's body is itself external, it
does NOT appear in the area that follows.  For example, consider the
following message:

MIME 実体が型 "message/external-body" である場合、これは頭, 2つの
連続した CRLF, カプセル化されたメッセージのメッセージ頭から
構成されます。更に連続した2つの CRLF が出現した場合、これは勿論
カプセル化されたメッセージの終端となります。しかし、カプセル化された
メッセージの本文自体は外部にあるので、続く領域には現れ'''ません'''。
例えば、次のメッセージを考えてみます。

Content-type: message/external-body;
                   access-type=local-file;
                   name="/u/nsb/Me.jpeg"

Content-type: image/jpeg
     Content-ID: <id42@guppylake.bellcore.com>
     Content-Transfer-Encoding: binary

THIS IS NOT REALLY THE BODY!

The area at the end, which might be called the "phantom body", is
ignored for most external-body messages.  However, it may be used to
contain auxiliary information for some such messages, as indeed it is
when the access-type is "mail-server".  The only access-type defined
in this document that uses the phantom body is "mail-server", but
other access-types may be defined in the future in other
specifications that use this area.

終わりのところの領域は、「見かけの本文」と呼びますが、ほとんどの
external-body メッセージでは無視します。しかし、これは
access-type が "mail-server" の時のように、メッセージの
補助情報を入れるのに使われるかもしれません。この文書の中で定義している
access-type で見掛けの本文を使うのは "mail-server" だけですが、
他の access-type が将来他の仕様書で、この領域を使うように
定義されるかもしれません。

The encapsulated headers in ALL "message/external-body" entities MUST
include a Content-ID header field to give a unique identifier by
which to reference the data.  This identifier may be used for caching
mechanisms, and for recognizing the receipt of the data when the
access-type is "mail-server".

'''すべて'''の "message/external-body" 実体のカプセル化された頭は、
データを参照するために与える唯一識別子を Content-ID 頭領域で
含めてい'''なければなりません'''。この識別子はキャッシュ機構で
使われるかもしれません。また、 access-type が "mail-server"
の場合のデータの受け取りの認知に使われるかもしれません。

Note that, as specified here, the tokens that describe external-body
data, such as file names and mail server commands, are required to be
in the US-ASCII character set.

なお、ここで規定する通り、 external-body を説明するファイル名や
メイル・サーバー命令のような字句は、 US-ASCII 文字集合である
必要があります。

If this proves problematic in practice, a new mechanism may be
required as a future extension to MIME, either as newly defined
access-types for "message/external-body" or by some other mechanism.

これが実際に問題があると認められる場合は、新しい機構が MIME
の将来の拡張か、新しい "message/external-body" の access-type 
の定義か、その他の機構が必要かもしれません。

As with "message/partial", MIME entities of type 
"message/external-body" MUST have a content-transfer-encoding of 7bit 
(the default). In particular, even in environments that support binary 
or 8bit transport, the use of a content-transfer-encoding of "8bit" or
"binary" is explicitly prohibited for entities of type
"message/external-body".

"message/partial" 同様、型 "message/external-body" の MIME 実体は、
7bit (既定値) の cte で'''なければなりません'''。特に、
バイナリや8ビットの転送に対応した環境であっても、 "8bit"
や "binary" の cte の使用は、型 "message/external-body" については
明白に禁止します。

*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

]]
]FIG]

* メモ

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

[3]
にせ本体の頭として [SAMP(MIME)[X-Last-Modified: 19920514010000Z (1992 May 14 01:00:00 GMT)]] なんてのが入っているのを見つけました。
([[名無しさん]])

[4]
[CITE[MIME の External-Body で本文と添付ファイルを分離保存]] 
<http://sonic64.com/2005-08-29.html#2005-08-29-1>

偽頭部に[[ファイル名]]を記述する方法が無いとして
[CODE(MIME)@en[[[X-Original-File-Name]]]] 欄なるものを導入しているが、
[CODE(MIME)@en[[[Content-[VAR[*]]]]]] 以外の名前の欄は無効
[SRC[[[RFC 2046]]]] だから意味が無い。あと、
[CODE(MIME)@en[[[Content-Disposition]]]] [CODE(MIME)@en[[[filename]]]]
がちゃんとある。

あと、ここに出ている例は [CODE(MIME)@en[[[Content-ID]]]] が不正。

[5] [CITE@en[RFC 4483 - A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages]]
( ([TIME[2014-11-02 07:10:38 +09:00]] 版))
<http://tools.ietf.org/html/rfc4483>

[FIG(quote)[
[FIGCAPTION[
[24] [CITE@en[Fedora API Specification]]
([TIME[2017-04-21 23:55:21 +09:00]])
<https://fcrepo.github.io/fcrepo-specification/>
]FIGCAPTION]

> Implementations should support Content-Type: message/external-body extensions for request bodies for HTTP POST that would create LDP-NRs. This content-type requires a complete Content-Type header that includes the location of the external body, e.g Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\", as defined in '''['''RFC2017''']'''.

]FIG]

[25] 
[CITE[Welcome to Netscape Navigator 3.0]], [TIME[2024-08-16T11:50:24.000Z]], [TIME[2002-06-30T20:13:53.276Z]] <https://web.archive.org/web/20020630200918/http://wp.netscape.com/eng/mozilla/3.0/relnotes/windows-3.0.html#MIME>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)