ids/2/290.txt


[2] [[MIME]] の [DFN[[CODE(MIME)[multipart/alternative]] [[媒体型]]]]は、
同じ情報の複数の[Q[代替]]となる[[表現]]を1つにまとめるために使うことができる書式です。

[3] 例えば、[[電子メイル]]の[[宛先]]が正しくないことを伝える [[DSN]]
の[[メッセージ]]で、人間向けの説明文の[[日本語]]版と[[英語]]版を同時に含めることができます。
あるいは[[アニメーション]]画像を提供する時に、
[[MNG]] 版と [[GIF]] 版を提供し、受け取った側で使える方を使ってもらうということができます。

[4] 
本質的には同じものを表す複数の[[表現]]を提供する技術としては [[HTTP]]
の[[内容折衝]]が有名ですが、 [[HTTP]] は提供側 ([[鯖]])
と利用側 ([[利用者エージェント]]) が直接通信するので、
[[利用者エージェント]]が用意した情報を使って[[鯖]]側で折衝
([[表現]]の選択) を行います。それに対して[[送信者]]と[[受信者]]が時間的・空間的に離れている[[電子メイル]]では、
[[送信者]]が用意した選択肢を 
[CODE(MIME)[[[multipart/alternative]]]] 形式に詰め込み、
[[受信者]]がその中から好きなものを選ぶという方法を採っています。

[5] 仕様書:
= [DEL[[[RFC 1341]] ([[MIME]] 1[SUP[st]]) ([[IETF]] [[提案標準]]) <urn:ietf:rfc:1341>]]
= [DEL[[[RFC 1521]] ([[MIME]] 2[SUP[nd]]) ([[IETF]] [[原案標準]]) <urn:ietf:rfc:1521>]]
= [DEL[[[RFC 1766]] ([CODE(MIME)[differences]] 引数) ([[IETF]] [[提案標準]]) <urn:ietf:rfc:1766>]] ([[RFC 3282]] により[[廃止]])
= [[RFC 2046]] ([[MIME]] 3[SUP[rd]]) ([[IETF]] [[原案標準]]) <urn:ietf:rfc:2046>
-- [CSECTION@en[5.1.4.  Alternative Subtype]]


* 構文

[6] [CODE(MIME)[multipart/alternative]] の構文は、
他の [CODE(MIME)[[[multipart/[VAR[*]]]]]] [[媒体型]]と共通です。
[[本体]]の部分に複数の[[本体部分]]を [CODE(MIME)[[[boundary]]]]
[[引数]]で区切って並べます。

[8] 含まれる各[[本体部分]]の順序は、
後の方程[Q[オリジナル]]に近いものにします。例えば元々の [[PDF]]
版、それから作成した [[HTML]] 版、[RUBY[[[平文]]] @en[プレイン・テキスト]]版と
3つあれば、[[平文]]、 [[HTML]]、 [[PDF]] の順で並べます。

このような順序にするのは、 [[MIME]] に対応していない[[利用者エージェント]]で見た時に
(つまり[[平文]]として見た時に) できるだけ[Q[ごみ]]が[[利用者]]に見えないようにと配慮されたことによります。

[10]
テストメールです。
([[松本]] [windingbird@hotmail.com] [WEAK[2007-12-21 04:07:01 +00:00]])


[11]
上記間違えました。申し訳ありません。削除して頂けますでしょうか?
([[松本]] [windingbird@hotmail.com] [WEAK[2007-12-21 04:08:22 +00:00]])


[[#comment]]


** 引数

[7]
,引数名      ,引数値      ,既定値      ,説明 ,状態 ,出典
,[CODE(MIME)[[[boundary]]]]     ,       ,(必須)       ,境界文字列        ,[[IETF]] [[原案標準]]      ,[[MIME]]
,[CODE(MIME)[[[differences]]]]  ,       ,       ,違う点      ,廃止 ([[IETF]] [[提案標準]])     ,[[RFC 1766]]

[[#comment]]


* 仕様書から


** RFC 2046 (MIME 3[SUP[rd]]) 5.1.4.  Alternative Subtype

> The "multipart/alternative" type is syntactically identical to
"multipart/mixed", but the semantics are different.  In particular,
each of the body parts is an "alternative" version of the same
information.

[DFN[[CODE(MIME)[multipart/alternative]]]] 型は構文的には
[CODE(MIME)[[[multipart/mixed]]]] と同じですが、
意味的には異なります。特に、
各[[本体部分]]は同じ情報の[Q[代替]]版とします。

> Systems should recognize that the content of the various parts are
interchangeable.  Systems should choose the "best" type based on the
local environment and references, in some cases even through user
interaction.  As with "multipart/mixed", the order of body parts is
significant.  In this case, the alternatives appear in an order of
increasing faithfulness to the original content.  In general, the
best choice is the LAST part of a type supported by the recipient
system's local environment.

システムは各[[部分]]の[[内容]]は交換可能であることを認識するべきです。
システムは局所環境や場合によっては[[利用者]]との[[対話]]にも基づき、
[Q[最善]]な型を選ぶべきです。 [CODE(MIME)[[[multipart/mixed]]]]
と同じように[[本体部分]]の順序は意味を持ちます。この場合、
各選択肢は元の内容への忠実度の順に並べます。
通常、受信システムの局所環境で対応している型の'''最後'''の[[部分]]を選ぶのが最良です。

> "Multipart/alternative" may be used, for example, to send a message
in a fancy text format in such a way that it can easily be displayed anywhere:

[CODE(MIME)[multipart/alternative]] は例えば装飾付きの文章書式で[[メッセージ]]を送る時にどこでも簡単に表示できるようにするために使うことができます。

>
[PRE(822 example code)[
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
  ... plain text version of message goes here ...
--boundary42
Content-Type: text/enriched
  ... RFC 1896 text/enriched version of same message
      goes here ...
--boundary42
Content-Type: application/x-whatever
  ... fanciest version of same message goes here ...
--boundary42--
]PRE]

[PRE[
   In this example, users whose mail systems understood the
   "application/x-whatever" format would see only the fancy version,
   while other users would see only the enriched or plain text version,
   depending on the capabilities of their system.
]PRE]

[PRE[
   In general, user agents that compose "multipart/alternative" entities
   must place the body parts in increasing order of preference, that is,
   with the preferred format last.  For fancy text, the sending user
   agent should put the plainest format first and the richest format
   last.  Receiving user agents should pick and display the last format
   they are capable of displaying.  In the case where one of the
   alternatives is itself of type "multipart" and contains unrecognized
   sub-parts, the user agent may choose either to show that alternative,
   an earlier alternative, or both.
]PRE]

[PRE[
   NOTE: From an implementor's perspective, it might seem more sensible
   to reverse this ordering, and have the plainest alternative last.
   However, placing the plainest alternative first is the friendliest
   possible option when "multipart/alternative" entities are viewed
   using a non-MIME-conformant viewer.  While this approach does impose
   some burden on conformant MIME viewers, interoperability with older
   mail readers was deemed to be more important in this case.
]PRE]

[PRE[
   It may be the case that some user agents, if they can recognize more
   than one of the formats, will prefer to offer the user the choice of
   which format to view.  This makes sense, for example, if a message
   includes both a nicely- formatted image version and an easily-edited
   text version.  What is most critical, however, is that the user not
   automatically be shown multiple versions of the same data.  Either
   the user should be shown the last recognized version or should be
   given the choice.
]PRE]

[PRE[
   THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE:  Each part of a
   "multipart/alternative" entity represents the same data, but the
   mappings between the two are not necessarily without information
   loss.  For example, information is lost when translating ODA to
   PostScript or plain text.  It is recommended that each part should
   have a different Content-ID value in the case where the information
   content of the two parts is not identical.  And when the information
   content is identical -- for example, where several parts of type
   "message/external-body" specify alternate ways to access the
   identical data -- the same Content-ID field value should be used, to
   optimize any caching mechanisms that might be present on the
   recipient's end.  However, the Content-ID values used by the parts
   should NOT be the same Content-ID value that describes the
   "multipart/alternative" as a whole, if there is any such Content-ID
   field.  That is, one Content-ID value will refer to the
   "multipart/alternative" entity, while one or more other Content-ID
   values will refer to the parts inside it.
]PRE]


* "difference" パラメーター

RFC 1766 が定義していました。 multipart/alternative
で選択肢になっている各部分の差異について指定します。

RFC 1766 では値として、 one or more 個の "Content-Type" / "Content-Language"
/ iana-token が指定できるとされています。値は RFC
として出版されている頭領域名でなければなりません。
従って、値の大文字・小文字は区別しないのでしょう(明記されては
いません)。

「more」個の値を指定する例が示されていないので、どうするのか
わかりませんが、読点 (comma) 区切りと解するのが適当でしょうか。

RFC 1766 を廃止する RFC 3282 では、 differences
パラメーターは実際には使われなかったとして、
differences パラメーターも廃止しています。

値は IANA に登録することになってますが、それっぽい登録簿は
無いみたいです。


* 関連

[9] [CODE(MIME)[[[Content-ID]]:]] 
欄は[[実体]]の[[一意]]な識別子を与えるもので、
通常は[[実体]]ごとに異なるものとしなければなりませんが、
[CODE(MIME)[[[multipart/alternative]]]] 内の各[[本体部分]]の
[CODE(MIME)[Content-ID]] は同じものでも構わないとされています。

[[#comment]]


* メモ

[1]
引数 [CODE(MIME)[[[differences]]]] 
と似たようなのが [CODE(HTTP)[[[URI:]]]] 欄にもあったっけ。

[12] [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-4>
1	wakaba	1.1
2			[2] [[MIME]] の [DFN[[CODE(MIME)[multipart/alternative]] [[媒体型]]]]は、
3			同じ情報の複数の[Q[代替]]となる[[表現]]を1つにまとめるために使うことができる書式です。
4
5			[3] 例えば、[[電子メイル]]の[[宛先]]が正しくないことを伝える [[DSN]]
6			の[[メッセージ]]で、人間向けの説明文の[[日本語]]版と[[英語]]版を同時に含めることができます。
7			あるいは[[アニメーション]]画像を提供する時に、
8			[[MNG]] 版と [[GIF]] 版を提供し、受け取った側で使える方を使ってもらうということができます。
9
10			[4]
11			本質的には同じものを表す複数の[[表現]]を提供する技術としては [[HTTP]]
12			の[[内容折衝]]が有名ですが、 [[HTTP]] は提供側 ([[鯖]])
13			と利用側 ([[利用者エージェント]]) が直接通信するので、
14			[[利用者エージェント]]が用意した情報を使って[[鯖]]側で折衝
15			([[表現]]の選択) を行います。それに対して[[送信者]]と[[受信者]]が時間的・空間的に離れている[[電子メイル]]では、
16			[[送信者]]が用意した選択肢を
17			[CODE(MIME)[[[multipart/alternative]]]] 形式に詰め込み、
18			[[受信者]]がその中から好きなものを選ぶという方法を採っています。
19
20			[5] 仕様書:
21			= [DEL[[[RFC 1341]] ([[MIME]] 1[SUP[st]]) ([[IETF]] [[提案標準]]) <urn:ietf:rfc:1341>]]
22			= [DEL[[[RFC 1521]] ([[MIME]] 2[SUP[nd]]) ([[IETF]] [[原案標準]]) <urn:ietf:rfc:1521>]]
23			= [DEL[[[RFC 1766]] ([CODE(MIME)[differences]] 引数) ([[IETF]] [[提案標準]]) <urn:ietf:rfc:1766>]] ([[RFC 3282]] により[[廃止]])
24			= [[RFC 2046]] ([[MIME]] 3[SUP[rd]]) ([[IETF]] [[原案標準]]) <urn:ietf:rfc:2046>
25			-- [CSECTION@en[5.1.4. Alternative Subtype]]
26
27
28			* 構文
29
30			[6] [CODE(MIME)[multipart/alternative]] の構文は、
31			他の [CODE(MIME)[[[multipart/[VAR[*]]]]]] [[媒体型]]と共通です。
32			[[本体]]の部分に複数の[[本体部分]]を [CODE(MIME)[[[boundary]]]]
33			[[引数]]で区切って並べます。
34
35			[8] 含まれる各[[本体部分]]の順序は、
36			後の方程[Q[オリジナル]]に近いものにします。例えば元々の [[PDF]]
37			版、それから作成した [[HTML]] 版、[RUBY[[[平文]]] @en[プレイン・テキスト]]版と
38			3つあれば、[[平文]]、 [[HTML]]、 [[PDF]] の順で並べます。
39
40			このような順序にするのは、 [[MIME]] に対応していない[[利用者エージェント]]で見た時に
41			(つまり[[平文]]として見た時に) できるだけ[Q[ごみ]]が[[利用者]]に見えないようにと配慮されたことによります。
42
43			[10]
44			テストメールです。
45			([[松本]] [windingbird@hotmail.com] [WEAK[2007-12-21 04:07:01 +00:00]])
46
47
48			[11]
49			上記間違えました。申し訳ありません。削除して頂けますでしょうか?
50			([[松本]] [windingbird@hotmail.com] [WEAK[2007-12-21 04:08:22 +00:00]])
51
52
53			[[#comment]]
54
55
56			** 引数
57
58			[7]
59			,引数名 ,引数値 ,既定値 ,説明 ,状態 ,出典
60			,[CODE(MIME)[[[boundary]]]] , ,(必須) ,境界文字列 ,[[IETF]] [[原案標準]] ,[[MIME]]
61			,[CODE(MIME)[[[differences]]]] , , ,違う点 ,廃止 ([[IETF]] [[提案標準]]) ,[[RFC 1766]]
62
63			[[#comment]]
64
65
66			* 仕様書から
67
68
69			** RFC 2046 (MIME 3[SUP[rd]]) 5.1.4. Alternative Subtype
70
71			> The "multipart/alternative" type is syntactically identical to
72			"multipart/mixed", but the semantics are different. In particular,
73			each of the body parts is an "alternative" version of the same
74			information.
75
76			[DFN[[CODE(MIME)[multipart/alternative]]]] 型は構文的には
77			[CODE(MIME)[[[multipart/mixed]]]] と同じですが、
78			意味的には異なります。特に、
79			各[[本体部分]]は同じ情報の[Q[代替]]版とします。
80
81			> Systems should recognize that the content of the various parts are
82			interchangeable. Systems should choose the "best" type based on the
83			local environment and references, in some cases even through user
84			interaction. As with "multipart/mixed", the order of body parts is
85			significant. In this case, the alternatives appear in an order of
86			increasing faithfulness to the original content. In general, the
87			best choice is the LAST part of a type supported by the recipient
88			system's local environment.
89
90			システムは各[[部分]]の[[内容]]は交換可能であることを認識するべきです。
91			システムは局所環境や場合によっては[[利用者]]との[[対話]]にも基づき、
92			[Q[最善]]な型を選ぶべきです。 [CODE(MIME)[[[multipart/mixed]]]]
93			と同じように[[本体部分]]の順序は意味を持ちます。この場合、
94			各選択肢は元の内容への忠実度の順に並べます。
95			通常、受信システムの局所環境で対応している型の'''最後'''の[[部分]]を選ぶのが最良です。
96
97			> "Multipart/alternative" may be used, for example, to send a message
98			in a fancy text format in such a way that it can easily be displayed anywhere:
99
100			[CODE(MIME)[multipart/alternative]] は例えば装飾付きの文章書式で[[メッセージ]]を送る時にどこでも簡単に表示できるようにするために使うことができます。
101
102			>
103			[PRE(822 example code)[
104			From: Nathaniel Borenstein <nsb@bellcore.com>
105			To: Ned Freed <ned@innosoft.com>
106			Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
107			Subject: Formatted text mail
108			MIME-Version: 1.0
109			Content-Type: multipart/alternative; boundary=boundary42
110			--boundary42
111			Content-Type: text/plain; charset=us-ascii
112			... plain text version of message goes here ...
113			--boundary42
114			Content-Type: text/enriched
115			... RFC 1896 text/enriched version of same message
116			goes here ...
117			--boundary42
118			Content-Type: application/x-whatever
119			... fanciest version of same message goes here ...
120			--boundary42--
121			]PRE]
122
123			[PRE[
124			In this example, users whose mail systems understood the
125			"application/x-whatever" format would see only the fancy version,
126			while other users would see only the enriched or plain text version,
127			depending on the capabilities of their system.
128			]PRE]
129
130			[PRE[
131			In general, user agents that compose "multipart/alternative" entities
132			must place the body parts in increasing order of preference, that is,
133			with the preferred format last. For fancy text, the sending user
134			agent should put the plainest format first and the richest format
135			last. Receiving user agents should pick and display the last format
136			they are capable of displaying. In the case where one of the
137			alternatives is itself of type "multipart" and contains unrecognized
138			sub-parts, the user agent may choose either to show that alternative,
139			an earlier alternative, or both.
140			]PRE]
141
142			[PRE[
143			NOTE: From an implementor's perspective, it might seem more sensible
144			to reverse this ordering, and have the plainest alternative last.
145			However, placing the plainest alternative first is the friendliest
146			possible option when "multipart/alternative" entities are viewed
147			using a non-MIME-conformant viewer. While this approach does impose
148			some burden on conformant MIME viewers, interoperability with older
149			mail readers was deemed to be more important in this case.
150			]PRE]
151
152			[PRE[
153			It may be the case that some user agents, if they can recognize more
154			than one of the formats, will prefer to offer the user the choice of
155			which format to view. This makes sense, for example, if a message
156			includes both a nicely- formatted image version and an easily-edited
157			text version. What is most critical, however, is that the user not
158			automatically be shown multiple versions of the same data. Either
159			the user should be shown the last recognized version or should be
160			given the choice.
161			]PRE]
162
163			[PRE[
164			THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a
165			"multipart/alternative" entity represents the same data, but the
166			mappings between the two are not necessarily without information
167			loss. For example, information is lost when translating ODA to
168			PostScript or plain text. It is recommended that each part should
169			have a different Content-ID value in the case where the information
170			content of the two parts is not identical. And when the information
171			content is identical -- for example, where several parts of type
172			"message/external-body" specify alternate ways to access the
173			identical data -- the same Content-ID field value should be used, to
174			optimize any caching mechanisms that might be present on the
175			recipient's end. However, the Content-ID values used by the parts
176			should NOT be the same Content-ID value that describes the
177			"multipart/alternative" as a whole, if there is any such Content-ID
178			field. That is, one Content-ID value will refer to the
179			"multipart/alternative" entity, while one or more other Content-ID
180			values will refer to the parts inside it.
181			]PRE]
182
183
184			* "difference" パラメーター
185
186			RFC 1766 が定義していました。 multipart/alternative
187			で選択肢になっている各部分の差異について指定します。
188
189			RFC 1766 では値として、 one or more 個の "Content-Type" / "Content-Language"
190			/ iana-token が指定できるとされています。値は RFC
191			として出版されている頭領域名でなければなりません。
192			従って、値の大文字・小文字は区別しないのでしょう(明記されては
193			いません)。
194
195			「more」個の値を指定する例が示されていないので、どうするのか
196			わかりませんが、読点 (comma) 区切りと解するのが適当でしょうか。
197
198			RFC 1766 を廃止する RFC 3282 では、 differences
199			パラメーターは実際には使われなかったとして、
200			differences パラメーターも廃止しています。
201
202			値は IANA に登録することになってますが、それっぽい登録簿は
203			無いみたいです。
204
205
206			* 関連
207
208			[9] [CODE(MIME)[[[Content-ID]]:]]
209			欄は[[実体]]の[[一意]]な識別子を与えるもので、
210			通常は[[実体]]ごとに異なるものとしなければなりませんが、
211			[CODE(MIME)[[[multipart/alternative]]]] 内の各[[本体部分]]の
212			[CODE(MIME)[Content-ID]] は同じものでも構わないとされています。
213
214			[[#comment]]
215
216
217			* メモ
218
219			[1]
220			引数 [CODE(MIME)[[[differences]]]]
221	wakaba	1.2	と似たようなのが [CODE(HTTP)[[[URI:]]]] 欄にもあったっけ。
222
223			[12] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
224			([TIME[2009-09-12 07:37:40 +09:00]] 版)
225			<http://tools.ietf.org/html/rfc5621#section-4>