[2] MIME の multipart/alternative
媒体型は、
同じ情報の複数の代替
となる表現を1つにまとめるために使うことができる書式です。
[3] 例えば、電子メイルの宛先が正しくないことを伝える DSN のメッセージで、人間向けの説明文の日本語版と英語版を同時に含めることができます。 あるいはアニメーション画像を提供する時に、 MNG 版と GIF 版を提供し、受け取った側で使える方を使ってもらうということができます。
[4]
本質的には同じものを表す複数の表現を提供する技術としては HTTP
の内容折衝が有名ですが、 HTTP は提供側 (鯖)
と利用側 (利用者エージェント) が直接通信するので、
利用者エージェントが用意した情報を使って鯖側で折衝
(表現の選択) を行います。それに対して送信者と受信者が時間的・空間的に離れている電子メイルでは、
送信者が用意した選択肢を
multipart/alternative
形式に詰め込み、
受信者がその中から好きなものを選ぶという方法を採っています。
[11] 各本体部分が同じ情報の異なる版であることを表します >>5。
[20] 本体部分の順序は、元の内容を忠実に表していないものから順に、 最後を最も好ましいものとしなければなりません。 >>5
[6] multipart/alternative
の構文は、
他の multipart/*
媒体型と共通です >>5。
本体の部分に複数の本体部分を boundary
引数で区切って並べます。
[8] 含まれる各本体部分の順序は、
後の方程オリジナル
に近いものにします。例えば元々の PDF
版、それから作成した HTML 版、平文版と
3つあれば、平文、 HTML、 PDF の順で並べます。
このような順序にするのは、 MIME に対応していない利用者エージェントで見た時に
(つまり平文として見た時に) できるだけごみ
が利用者に見えないようにと配慮されたことによります。
[39]
AMP Email
は、
最後の本体部分だけをレンダリングする
MUA
が存在することを理由に、
text/x-amp-html
より後に
text/html
を置くことを推奨 (recommend) しています。
>>38
[40] そのように表示する MUA は仕様違反です (仕様は適合性の規定が曖昧ですが、 少なくても意図した挙動でないことは明らかです)。 AMP の推奨する動作は明確な仕様違反です。
[41] AMP の推奨が意図的違反なのか、 MIME 仕様への無理解に由来するものなのかは不明です。
[42] 表示の仕様違反の MUA が多数なら、現行 MIME 仕様が実効性を失っていることになりますから、 改正されるべきですし、意図的違反もやむなしでしょう。 そうでもないのなら、 仕様違反を推奨するのはいただけません。
引数名 | 引数値 | 既定値 | 説明 | 状態 | 出典 |
boundary | (必須) | 境界文字列 | IETF 原案標準 | MIME | |
differences | 違う点 | 廃止 (IETF 提案標準) | RFC 1766 |
differences
引数[37]
differences
引数は
RFC 1766 が定義していました >>36。 multipart/alternative
で選択肢になっている各部分の差異について指定します。
RFC 1766 では値として、 one or more 個の "Content-Type" / "Content-Language" / iana-token が指定できるとされています。値は RFC として出版されている頭領域名でなければなりません。 従って、値の大文字・小文字は区別しないのでしょう(明記されては いません)。
「more」個の値を指定する例が示されていないので、どうするのか わかりませんが、読点 (comma) 区切りと解するのが適当でしょうか。
RFC 1766 を廃止する RFC 3282 では、 differences パラメーターは実際には使われなかったとして、 differences パラメーターも廃止しています。
値は IANA に登録することになってますが、それっぽい登録簿は 無いみたいです。
[19] 実装は、各本体部分の内容が交換可能なものと認識するべきです。 環境に応じて、場合によっては利用者の指示により、 「最適」なものを選ぶべきです。 >>5
[21] 一般に受信者の環境が対応する最後の本体部分が最善の選択です >>5。
[22] 選択肢のいずれかが multipart/*
の場合で、
認識でいない本体部分が含まれている場合は、
それを表示することにしても構いませんし、より前の本体部分を表示しても構いませんし、
両方でも構いません。 >>5
[25] いずれにせよ、利用者に同じデータの複数の版を同時に提示しないことが重要です >>5。
[44] 具体的にどのように「最善」を選択するべきかは決められていません。
[45]
仕様上は Content-Language:
の違いにも使えますし、
その他のヘッダーで表される違いにも使えますが、
実際にそのような利用例があるのかは不明です。
[46] 実際にはほとんどの場合には定型化したいくつかの選択肢から1つを選ぶ形で使われていて (>>47)、 実装もその定型に従った選択しかしません。
[47] いくつかの使われ方があります。
[28] HTMLメールでは、 text/plain
と
text/html
の本体部分が含まれるのが基本です。
[29] HTMLメールの HTML 版に画像が埋め込まれている場合、
text/plain
と multipart/related
で、 multipart/related
内に text/html
と画像が含まれることがあります。
[30] HTMLメールに添付ファイルが含まれる場合、 multipart/mixed
に multipart/alternative
と添付ファイルが本体部分として含まれるのが一般的です。
[33] multipart/alternative
は、
送信者がどの部分も同等同義の内容を含めていることを前提としていますが、
受信者がそれを確認するのは困難です。 (少なくても HTMLメールでは)
この点送信者を信用できず、送信者は HTML 部分は丁寧に作成しても、
平文は気にも留めず機械生成した値や情報を削った内容しか含まれていなかったり、
改訂時に忘れられて古い版のままだったり、蔑ろにされているのが現実です
(HTMLメール参照)。本来の想定である
「受信者の装置や利用者エージェントの能力に合わせた形式の選択」
という実装戦略はここでは成立しません。
[43] AMP Email
は
text/plain
,
text/html
,
text/x-amp-html
を本体部分として含める形式です。
differences
引数) (IETF 提案標準) urn:ietf:rfc:1766The "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.
multipart/alternative
型は構文的には
multipart/mixed
と同じですが、
意味的には異なります。特に、
各本体部分は同じ情報の代替
版とします。
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.
システムは各部分の内容は交換可能であることを認識するべきです。
システムは局所環境や場合によっては利用者との対話にも基づき、
最善
な型を選ぶべきです。 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:
multipart/alternative
は例えば装飾付きの文章書式でメッセージを送る時にどこでも簡単に表示できるようにするために使うことができます。
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--
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.
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.
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.
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.
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.
[9] Content-ID:
欄は実体の一意な識別子を与えるもので、
通常は実体ごとに異なるものとしなければなりませんが、
multipart/alternative
内の各本体部分の
Content-ID
は同じものでも構わないとされています。
Content-ID:
を参照。[27] message/external-body
と併用することで、
代替版をすべて含めて送らずとも、必要なものを受信者に取得させることができます >>26。
[1]
引数 differences
と似たようなのが URI:
欄にもあったっけ。
[12] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) http://tools.ietf.org/html/rfc5621#section-4
[13] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) http://tools.ietf.org/html/rfc5621#section-6
[15] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( ( 版)) http://tools.ietf.org/html/rfc5621#section-4.1
[16] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( ( 版)) http://tools.ietf.org/html/rfc5621#section-8.2
[17] RFC 3459 - Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter ( ( 版)) http://tools.ietf.org/html/rfc3459#section-12.1
[18] draft-jennings-sipping-multipart-02 - Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative ( ( 版)) https://tools.ietf.org/html/draft-jennings-sipping-multipart-02
[32] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) https://tools.ietf.org/html/rfc5621
[34] RFC 2483 - URI Resolution Services Necessary for URN Resolution () https://tools.ietf.org/html/rfc2483#section-4.4
[48] Welcome to Netscape Navigator 3.0, , https://web.archive.org/web/20020630200918/http://wp.netscape.com/eng/mozilla/3.0/relnotes/windows-3.0.html#MIME