[1] [[MIME]] の [DFN[[CODE(MIME)[multipart/related]]]]
[[媒体型]]は、関連する[[実体]]を1つにまとめるための仕組みです。
[[HTML]] 文書とその中で参照されている[[画像]]のように、
意味的に1つの[[文書]]であっても物理的には複数の[[実体]]で表されていることがよくあります。
そのような場合を MIME で統一的に扱うために
[CODE(MIME)[multipart/related]] が開発されました。

[16] [[HTMLメール]]の形式として広く利用されています。それ以外の用途でも [[MIME]]
や [[HTTP]] でしばしば利用されますが、広く受け入れられた用法は無いようです。

* 仕様書

[REFS[
- [2] [RFC-REL]
== [[RFC 1872]] ([[IETF]] [[実験的]]) <urn:ietf:rfc:1872>
== [[RFC 2112]] ([[IETF]] [[提案標準]]) <urn:ietf:rfc:2112>
== [[RFC 2387]] ([[IETF]] [[原案標準]]) <urn:ietf:rfc:2387>
- [[RFC 3458]] ([CODE(822)[[[Message-Context]]]]) <urn:ietf:rfc:3458>
-- [CSECTION[6.2.4. multimedia-message]]
- [[RFC 3459]] ([CODE(MIME)[[[Content-Disposition]]]]
[CODE(MIME)[[[handling]]]] 引数) <urn:ietf:rfc:3459>
-- [CSECTION[12.2 multipart/related]]
]REFS]

* 構文

[3] 構文は [[MIME]] の [CODE(MIME)[[[multipart/[VAR[*]]]]]]
共通のものを使用しています。

[5] [CODE(MIME)[multipart/related]] 内の[[本体部分]]の中で中心的な役割を果たすのが[DFN[[RUBYB[根] [root]]]] ([DFN[[RUBYB[開始] [start]]]]) 部分
です。根は [CODE(MIME)[start]] 引数で指定されますが、
引数が省略されれば一番最初の本体部分の実体となります。

[7] [CODE(MIME)[multipart/related]] が入れ子になることも認められています
[SRC[RFC-REL]]。

* 引数

[4] [CODE(MIME)[multipart/related]] には次の[[引数]]があります。
,引数名	,引数値	,既定値	,説明	,状態	,出典
,[CODE(MIME)[[[boundary]]]]	,	,(必須)	,多部分境界	,IETF 原案標準	,[[MIME]]
,[CODE(MIME)[[[start]]]]	,[[内容ID]]	,(最初の実体)	,根実体	,IETF 原案標準	,[RFC-REL]
,[CODE(MIME)[[[start-info]]]]	,	,	,追加情報	,IETF 原案標準	,[RFC-REL]
,[CODE(MIME)[[[type]]]]	,[[媒体型]]	,(必須)	,根媒体型	,IETF 原案標準	,[RFC-REL]

[CODE(MIME)[multipart/related]] の定義 [SRC[RFC-REL]]
には明記されていませんが、当然 [CODE(MIME)[[[boundary]]]]
引数が必要なはずです。

* 意味

[6] [CODE(MIME)[multipart/related]] 実体
(に含まれる各本体部分) の意味の解釈・レンダリングは
[CODE(MIME)[type]] 引数によって識別される[[媒体型]]によります。

[7] '''[CODE(MIME)[[[Content-Disposition]]]] との関係''':
第2版の [[RFC 2112]] 以後 [CODE(MIME)[Content-Disposition]]
との関係も規定されています。 [CODE(MIME)[Content-Disposition]]
の配置型 ([CODE(MIME)[[[inline]]]] や [CODE(MIME)[[[attachment]]]])
は、 [CODE(MIME)[multipart/related]] 未対応の[[利用者エージェント]]のために指定できますが、
[CODE(MIME)[multipart/related]] 対応の利用者エージェントは無視しなければなりません
[WEAK[(レンダリングは [CODE(MIME)[type]] 引数で指定された媒体型の側で決まります)]]。
しかし、 [CODE(MIME)[[[filename]]]] 引数などの情報は利用して構いません。

[[#comment]]


* 応用

[10] [CODE(MIME)[multipart/related]] の中には (根部分も含めて)
任意の[[媒体型]]を使うことができます。登録簿や審査も特にありません。
しかし、解釈・レンダリングのされ方を統一したり、
[CODE(MIME)[[[start-info]]]] 引数を実用的にしたりするためには何らかの標準が必要です。
[CODE(MIME)[multipart/related]] の定義 [SRC[RFC-REL]]
では媒体型登録の時に説明するのがいいと言っています。

[8] 実例のあるもの:
,*[CODE(MIME)[[[type]]]]	,*[CODE(MIME)[[[start-info]]]]	,*説明	,*状態	,*出典
,[CODE(MIME)[[[multipart/alternative]]]]	,	,	,IETF 標準化過程	,[MHTML]
,[CODE(MIME)[[[application/beep+xml]]]]	,	,[[BEEP]] 弾頭	,IETF 標準化過程 (例)	,[APEX] (例)
,[CODE(MIME)[[[text/calendar]]]]	,	,[[iCalendar]] 添付	,IETF 標準化過程 (例)	,[iCal] (例)
,[CODE(MIME)[[[application/dicom]]]]	,	,[[DICOM]]	,IETF 情報提供	,[DICOM]
,[CODE(MIME)[[[text/directory]]]]	,	,[[ディレクトリ]]	,IETF 標準化過程	,[Directory]
,[CODE(MIME)[[[text/html]]]]	,	,[[HTML文書]]	,IETF 標準化過程	,"[MHTML], [CID] (例)"
,[CODE(MIME)[[[application/sdp]]]]	,	,[[セッション記述]]	,IETF 標準化過程 (例)	,[PINT]
,[CODE(MIME)[[[message/tracking-status]]]]	,	,メッセージ追跡状況	,IETF 提案標準	,[MTQP]
,[CODE(MIME)[[[application/vnd.pwg-xhtml-print]]]]	,	,[[XHTML文書]]	,IETF 情報提供 (例)	,[Multiplexed]
,[CODE(MIME)[[[applicatiin/xml]]]]	,	,[[SOAP]]/[[BEEP]]	,IETF 提案標準	,[SOAP/BEEP]
,[CODE(MIME)[[[text/xml]]]]	,	,[[SOAP]] 添付	,W3C 会員提出 Note	,[SOAP Attach]
,[CODE(MIME)[[[application/xop+xml]]]]	,根部分の媒体型 [CODE(MIME)[[[type]]]] 引数と同じ	,[[XOP]]	,W3C 勧告	,[XOP]

出典:
- [MHTML] [[RFC 2110]] <urn:ietf:rfc:2110>,
[[RFC 2557]] <urn:ietf:rfc:2557>
- [CID] [[RFC 2111]] <urn:ietf:rfc:2111>, [[RFC 2392]] <urn:ietf:rfc:2392>
- [PINT] [[RFC 2348]] <urn:ietf:rfc:2348>
- [Directory] [[RFC 2425]] <urn:ietf:rfc:2425>
- [iCal] [[RFC 2446]] <urn:ietf:rfc:2446>
- [SOAP Attach] [CITE[SOAP Messages with Attachments]]
<http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211>
- [SOAP/BEEP] [[RFC 3288]] <urn:ietf:rfc:3288>
- [Multiplexed] [[RFC 3391]] <urn:ietf:rfc:3391>
- [XOP] [CITE[XML-binary Optimized Packaging]]
<http://www.w3.org/TR/2005/REC-xop10-20050125/>
- [DICOM] [[RFC 3240]] <urn:ietf:rfc:3240>
- [APEX] [[RFC 3340]] <urn:ietf:rfc:3340>,
[[RFC 3341]] <urn:ietf:rfc:3341>,
[[RFC 3343]] <urn:ietf:rfc:3343>
- [MTQP] [[RFC 3886]] <urn:ietf:rfc:3886>,
[[RFC 3887]] <urn:ietf:rfc:3887>
- [CITE[SOAP Message Transmission Optimization Mechanism]]
<http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/>

[[#comment]]


* よくある間違い

[13] [CODE(MIME)[multipart/related]] の [CODE(MIME)[[[type]]]]
引数は必須ですが、省略されることがあります。
そういう例を出している [[RFC]] まであります [SRC[PINT]]。
値は[[媒体型]] (引数なし) ですが、媒体型 (狭義)
を省略して媒体亜型だけしか指定していない例を出している RFC
があります [SRC[MTQP]]。媒体型 (狭義) と媒体亜型の間の
[CODE(char)[/]] は [CODE(ABNF)[[[tspecials]]]] に含まれるので、
[CODE(ABNF)[[[token]]]] に含めることができません。つまり、
[CODE(MIME)[type]] 引数は常に引用符で括った[[引用文字列]]でなければなりませんが、
そうでない例を出している RFC があります。

[14] [CODE(MIME)[multipart/related]] と [CODE(MIME)[[[Content-ID]]]]
や [CODE(URI)[[[cid]]:]] URI が併用されることはよくありますが (>>11)、
その時に[[内容ID]] として不正な [[URI参照]]を使うことがあります。
そういう例を出している [[RFC]] や [[W3C]] [[勧告]] [SRC[XOP]]
まであります。

[19] [CITE@en[RFC 6047 - iCalendar Message-Based Interoperability Protocol (iMIP)]] ([TIME[2011-03-13 15:32:14 +09:00]] 版) <http://tools.ietf.org/html/rfc6047#section-4.3>

ここに示されている例は [CODE(MIME)@en[[[multipart/related]]]] を 
[CODE(MIME)@en[[[type]]]] なしで使っています。

* 不適切なメッセージへの対処

[15] 本来 [CODE(MIME)[[[multipart/related]]]]
を使うべきではないのに、誤って [CODE(MIME)[[[multipart/related]]]]
が使われることがあります。例えば根メッセージが
[CODE(MIME)[[[text/plain]]]] だとすると、
他の[[本体部分]]への[[参照]]は含まれ得ませんから、
間違って [CODE(MIME)[[[multipart/related]]]]
と札付けされてしまっていると思われます。

このような場合、[[利用者]]が[[メッセージ]]内の情報にアクセスできないと不便です。
根メッセージの[[媒体型]]が ([CODE(MIME)[[[multipart/related]]]]
で使うものとして) 対応しているもの以外であれば、
[[利用者エージェント]]は知らないものとして
[WEAK[(つまり [CODE(MIME)[[[multipart/mixed]]]] のように)]]
処理するべきです。また、そうでない場合であっても、
根メッセージ以外を表示する手段を[[利用者エージェント]]の[[界面]]として用意しておくと便利でしょう。

[[#comment]]


* 関連

[9] [[RFC 1867]] ([[HTML]] [[フォーム]]による[[ファイル]]の[[うp]])
は、 [CODE(MIME)[[[multipart/form-data]]]] は用法と応用が随分
[CODE(MIME)[multipart/related]] とは異なるから使わなかったと述べています
[SRC[RFC 1867 5.11]]。

[10] [CODE(MIME)[[[application/vnd.pwg-multiplexed]]]]
は [CODE(MIME)[multipart/related]] と似たような目的の異なった構文を持つ[[媒体型]]です。

[11] [CODE(MIME)[multipart/related]] 内の各実体を相互に参照する方法は特別には規定されていませんが、
[CODE(MIME)[[[cid]]:]] [[URI scheme]] を使って実体の
[CODE(MIME)[[[Content-ID]]]] によって参照する方法が良く採られます。

[12] [CODE(MIME)[multipart/related]] を [[MIME]]
で転送する場合、 MIME の規定により [CODE(MIME)[[[Content-Transfer-Encoding]]]]
を使ってはいけません [WEAK[([CODE(MIME)[[[Base64]]]] などを使うことはできません)]]。
[CODE(MIME)[multipart/related]] の中身の各実体には使用できます。

[[#comment]]


* メモ

[17] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
([TIME[2009-09-12 07:37:40 +09:00]] 版)
<http://tools.ietf.org/html/rfc5621#section-7>

[18] [CITE@EN[XForms 1.1]]
([TIME[2009-10-20 22:51:54 +09:00]] 版)
<http://www.w3.org/TR/2009/REC-xforms-20091020/#serialize-multipart>

[20] [CITE@en[WICD Mobile 1.0]]
( ([TIME[2010-08-17 16:50:39 +09:00]] 版))
<http://www.w3.org/TR/WICDMobile/#packaging>

[21] [CITE@en[WICD Mobile 1.0]]
( ([TIME[2010-08-17 16:50:39 +09:00]] 版))
<http://www.w3.org/TR/WICDMobile/#packaging>

[22] [CITE@en[draft-gregorio-atompub-multipart-04 - AtomPub Multipart Media Resource Creation]]
( ([TIME[2014-03-10 15:46:59 +09:00]] 版))
<https://tools.ietf.org/html/draft-gregorio-atompub-multipart-04>

[23] [CITE@en[RFC 4662 - A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists]]
( ([TIME[2014-06-15 09:36:33 +09:00]] 版))
<http://tools.ietf.org/html/rfc4662#section-5>

[24] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
( ([TIME[2014-09-14 07:55:49 +09:00]] 版))
<http://tools.ietf.org/html/rfc5621#section-7>

[25] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
( ([TIME[2014-09-14 07:55:49 +09:00]] 版))
<http://tools.ietf.org/html/rfc5621#section-8.2>

[26] [CITE@ja[Loading Data Into BigQuery - Google BigQuery — Google Cloud Platform]]
( ([TIME[2014-12-18 02:33:02 +09:00]] 版))
<https://cloud.google.com/bigquery/loading-data-into-bigquery>

[27] [CITE@ja[Loading Data with a POST Request - Google BigQuery — Google Cloud Platform]]
( ([TIME[2014-12-18 02:33:03 +09:00]] 版))
<https://cloud.google.com/bigquery/loading-data-post-request>

[28] [CITE@en[Upload Files - Drive REST API — Google Developers]]
([TIME[2015-04-17 02:17:08 +09:00]] 版)
<https://developers.google.com/drive/web/manage-uploads>

[29] [[Chrome]] では [CODE(MIME)@en[[[multipart/related]]]] へのリンクが
([CODE(HTTP)[[[204]]]] [[応答]]のように) 無反応になります。何か条件次第で開けるのかもしれません。 [TIME[2015-05-10T15:35:58.500Z]]


[30] [CITE[HTMLメールでmultipart/relatedパートを入れないとGmailなどの受信側でDKIM認証が失敗する - igreks開発日記]]
([TIME[2015-01-23 11:49:47 +09:00]] 版)
<http://www.igreks.jp/dev/2014/11/htmlmultipartrelatedgmaildkim.html>

[31] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
([TIME[2015-06-21 16:17:31 +09:00]] 版)
<https://tools.ietf.org/html/rfc5621>

[FIG(quote)[
[FIGCAPTION[
[32] [CITE@en[Loading Data with a POST Request - BigQuery — Google Cloud Platform]]
([[Google]] 著, [TIME[2015-09-17 06:50:38 +09:00]] 版)
<https://cloud.google.com/bigquery/loading-data-post-request>
]FIGCAPTION]

> If you have metadata that you want to send along with the data to upload, you can make a single multipart/related request.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[33] [CITE@en[Loading Data with a POST Request - BigQuery — Google Cloud Platform]]
([[Google]] 著, [TIME[2015-09-17 06:50:38 +09:00]] 版)
<https://cloud.google.com/bigquery/loading-data-post-request>
]FIGCAPTION]

> The body of the request is formatted as a multipart/related content type '''['''RFC2387''']''' and contains exactly two parts. The parts are identified by a boundary string, and the final boundary string is followed by two hyphens.
> Each part of the multipart request needs an additional Content-Type header:
> Metadata part: Must come first, and Content-Type must match one of the accepted metadata formats.
> Media part: Must come second, and Content-Type must match one the method's accepted media MIME types.
> See the API reference for each method's list of accepted MIME types and size limits for uploaded files.

]FIG]
