#?SuikaWiki/0.9


* パラメーター

,boundary	,境界文字列	,[[MIME]] (See [[multipart/*媒体型]])
,differences	,違い	,RFC 1766


* RFC 2046 5.1.4.  Alternative Subtype

[PRE[
   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.
]PRE]

[PRE[
   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.
]PRE]

"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:

[PRE[
     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
]PRE]

[PRE[
     --boundary42
     Content-Type: text/plain; charset=us-ascii
]PRE]

[PRE[
       ... plain text version of message goes here ...
]PRE]

[PRE[
     --boundary42
     Content-Type: text/enriched
]PRE]

[PRE[
       ... RFC 1896 text/enriched version of same message
           goes here ...
]PRE]

[PRE[
     --boundary42
     Content-Type: application/x-whatever
]PRE]

[PRE[
       ... fanciest version of same message goes here ...
]PRE]

[PRE[
     --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 に登録することになってますが、それっぽい登録簿は
無いみたいです。


* See also

- [[媒体型]]
-- [[multipart/*媒体型]]
- [[MIME]]
-- <urn:ietf:rfc:2046>
- <urn:ietf:rfc:1766>
- <urn:ietf:rfc:3282>
- [[RFC822と仲間達の頭領域名]]
-- [[Content-Type:領域]]
-- [[Content-Language:領域]]


* License

[[RFCのライセンス]]

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