Edit

Page

Page title:

Page body:

[1] [DFN[[CODE(MIME)@en[MIME-Version:]]]] [[頭欄]]は、 [[RFC 822]] (現 [[RFC 5322]])
[[メッセージ]]が [[MIME]] を使用している[[版]]を表します。

[22] 元々名前の通り [[MIME]] の[[版]]を表す[[頭欄]]として導入され、現行の
[[RFC 2045]] でもそのように説明されていますが、唯一の[[版番号]]
[DFN[[CODE(MIME)@en[[[1.0]]]]]] が (小改訂の後も) 使われていて、
将来新しい[[版番号]]が導入されることもないだろうとの見解が示されています [SRC[>>13]]。

;; [[versioning]] の失敗例の1つですね。

* 仕様書

[REFS[
- [12] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#appendix-A.1>
]REFS]

* 構文

@@ ・・・

** [CODE(MIME)@en[1.0]] 以上の値

- [13] [WEAK[2003-03-03 17:32]] ''[[名無しさん]]'': 最近 [WEAK[(多分以前からだと思うが。)]] [[NedFreed]] が [[ietf-822]] で示した見解によれば、 MIME の版が 1.0 より大きな数になることは永遠に無いです。
- [15] [CODE(MIME)[MIME-Version: 1.1]] のメッセージって意外とあるみたい。どういう仕様でしょうねぇ。
- [16] >>15 先生! [CODE(MIME)[1.1.1]] とか [CODE(MIME)[1.1.2]] とかも見つかりました! [WEAK[但しそのメッセージには謎の charset [CODE(charset)[iso-8860-1]] がついてたりしますが。。。]]
- [17] [CODE(MIME)[Mime-Version: 1.1b]] && [CODE(822)[X-Mailer: Windows Eudora Version 1.5.2]]
- [18] [CODE(MIME)[MIME-Version: 2.0]] もかなりひっかかります。 spam ばっかりですけども。。。

[19] ''MIME version 2.4?'' <http://groups.google.com/groups?hl=ja&lr=&ie=UTF-8&oe=utf-8&c2coff=1&selm=Pine.NXT.3.92.960304211407.16930A-100000%40Tomobiki-Cho.CAC.Washington.EDU> : 最初は単なる [CODE(822)[MIME-Version: 2.4]]
ハァ? という話題でしたが、途中でネタ化して・・・。
[[IPv9]] が実用化されて(略)

** VPIM

[39] [[VPIM]] では、 [CODE(MIME)@en[[[MIME-Version:]] 1.0 (Voice 1.0)]] [SRC[>>36]] や
[CODE(MIME)@en[[[MIME-Version:]] 1.0 (Voice 2.0)]] [SRC[>>38]]
のような[[注釈]]を記述する[['''べき''']]とされています。

[REFS[
- [36] [CITE@en[RFC 1911 - Voice Profile for Internet Mail]]
( ([TIME[2014-11-03 00:29:14 +09:00]] 版))
<http://tools.ietf.org/html/rfc1911#page-7>
- [38] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]]
( ([TIME[2014-09-07 15:46:36 +09:00]] 版))
<http://tools.ietf.org/html/rfc3801#section-4.2.10>
-- [37] 旧 [CITE@en[RFC 2421 - Voice Profile for Internet Mail - version 2]]
( ([TIME[2014-08-04 01:19:09 +09:00]] 版))
<http://tools.ietf.org/html/rfc2421#section-4.2.10>
]REFS]

* 文脈

** RFC 822 メッセージ

[23] [CODE(MIME)@en[MIME-Version:]] [[頭欄]]は、[[電子メイル]]や[[電子ニュース]]で用いられている
[[RFC 822]] (現 [[RFC 5322]]) [[メッセージ]]で使用することができます。

** MIME 実体

[24] [[多部分メッセージ]]に含まれる [[MIME]] [[実体]]や、 [[BEEP]]
など [[RFC 822]] [[メッセージ]]以外に含まれる [[MIME]] [[実体]]では、
[CODE(MIME)@en[MIME-Version:]] [[頭欄]]は用いられません。

[14] [[複数部分]]の[[本体部分]]の MIME 実体になぜか [CODE(MIME)[MIME-Version]] 欄つけてる実装を見かけました。まあ無害ですがね。

** HTTP メッセージ

[26] [[HTTP]] は [[MIME]] 風の[[メッセージ]]の構造を採用しており、
主に初期の実装では [CODE(HTTP)@en[[[MIME-Version:]]]] [[頭欄]]が用いられることがありました。
[[HTTP]] の初期の仕様書でも触れられている他、後の [[RFC]] でも[[参考]]として説明が掲載されています。

[31] [[HTTPメッセージ]]は [CODE(MIME)@en[[[MIME-Version:]]]]
[[ヘッダー]]を1つ含めることができます。これは当該[[メッセージ]]の構築に使った
[[MIME]] の版を表し、 [[MIME]] に完全に適合することを表します。 [SRC[>>12]]

;; [34] [[RFC 7231]] の本体ではなく[[附属書]]で規定されていますが、
特に推奨とも非推奨ともされていません。構文などは [[MIME]] ([[RFC 2045]])
に委ねているようで、独自の規定はありません。

;; [35] [[HTTPメッセージ]]が [[MIME]] に適合するとはどのような意味なのかははっきりしません。
[[MIME]] にない機能、例えば [CODE(HTTP)@en[[[Transfer-Encoding:]]]]
や [CODE(HTTP)@en[[[Content-Encoding:]]]] の利用が認められているのかどうか不明瞭です。

[42] 
[[FIPA MTP]] [[HTTP要求]]およびその [CODE[multipart/mixed]]
の[[実体]]は指定することを要求しています。
(が提示されている例文には[[HTTP要求]]の方にしか書かれていません。)

** PO ファイル

[25] [[GNU]] [[Gettext]] などで用いられている [[POファイル]]は、[[頭部]]として
[[RFC 822]] 風の[[欄]]の構造を持った部分を記述しますが、
そこで [CODE(MIME)@en[MIME-Version:]] 欄も指定されます。
実際問題この欄の指定には意味も本来の [[MIME]] との互換性もないように思えますが・・・。

* 意味

** [CODE(ABNF)@en[encoded-word]] との関係

[20] この欄が影響するのは、電子メイル[[本体]]部を MIME 
的に解釈するか否かです。電子メイル頭部での
[[encoded-word]] 使用の如何とは無関係です。
(RFC 2045・2046 の規定内容に従う時は [CODE(822)[MIME-Version]] が関係しますが、 RFC 2047 の規定内容に従うか否かは関係しません。[WEAK[ちなみに encoded-word の使用如何を明示する方法はありません。]])

この件については昔から誤解が絶えません。
大昔の規定 (1341 の昔) ではこの問題に明確に言及されていなかったのですが、
後の改訂で RFC 本文にはっきり明記されています。
(>>21 参照。)

** 仕様改訂との関係

[27] [[MIME]] 本体仕様は [[RFC 1341]]、[[RFC 1521]]、[[RFC 2045]]〜[[RFC 2049]]
と2回改訂がありましたが、 [CODE(MIME)@en[[[MIME-Version:]]]]
欄の値は変わっていません。新たな[[頭欄]]が追加されたり [[RFC 2231]]
による構文拡張が行われたりしていますが、それでも値は追加されませんでした。

[28] 今後も [[MIME]] 仕様に非互換な変更を加えることは実質的に不可能でしょうから、
新しい版番号を導入して区別する必要性も生じないでしょう。
新しい版番号を導入すると既存の実装との互換性もなくなってしまいます。
従って >>13 のように新たな版番号となることはないだろうとの関係者の見解もあります。

[29] もっとも、現存の[[利用者エージェント]]で [CODE(MIME)@en[[[MIME-Version:]]]]
欄の値を調べ、それによって解釈を変更するようなものがどれだけあるかは疑問です。
黎明期には [[MIMEメッセージ]]と非 [[MIMEメッセージ]]を区別するために用いていた
[[MUA]] もあったようですが、今となってはその必要もないでしょう。
そんなわけで、 [CODE(MIME)@en[[[MIME-Version:]]]] 欄は実質的に意義を失っているものと推測されます。

* 歴史

**RFC 1341 (MIME 第1版)
***1. Introduction (抜粋)
>1.  A MIME-Version header field, which uses a version number
to  declare  a  message  to  be  conformant  with  this
specification and  allows  mail  processing  agents  to
distinguish  between  such messages and those generated
by older or non-conformant software, which is  presumed to lack such a field.

[2] [CODE[MIME-Version]] 頭欄。これはメッセージが MIME 
に適合することを宣言するために版番号を使用し、メイル処理エージェントが適合メッセージと古い非適合のメッセージでこの欄を欠いていると考えられるものを識別出来ます。
***3    The MIME-Version Header Field
>Since RFC 822 was published in 1982, there has  really  been
only  one  format  standard for Internet messages, and there
has  been  little  perceived  need  to  declare  the  format
standard  in  use.  This document is an independent document
that complements RFC 822. Although the  extensions  in  this
document have been defined in such a way as to be compatible
with RFC 822, there are  still  circumstances  in  which  it
might  be  desirable  for  a  mail-processing  agent to know
whether a message was composed  with  the  new  standard  in mind.

[3] [[RFC822]] が 1982 年に出版されてから、 Internet
メッセージには本当に唯一の標準だけがあり、使用している書式規格を宣言する必要を感じることはほとんどありませんでした。
この文書は RFC 822 を補完する独立した仕様です。この文書の拡張は RFC 822
と互換性があるように定義しますが、それでもメイル処理エージェントが、メッセージが新しい規格で構成されたのかどうかを知ることが出来るのが望ましいという事情があります。

>Therefore, this document defines a new header field,  
"MIME-Version",  which is to be used to declare the version of the
Internet message body format standard in use.

[4]
>Messages composed in  accordance  with  this  document  MUST
include  such  a  header  field, with the following verbatim text:

[6]
-[5]            MIME-Version: 1.0

>The presence of this header field is an assertion  that  the
message has been composed in compliance with this document.

>Since it is possible that a future document might extend the
message format standard again, a formal BNF is given for the
content of the MIME-Version field:

-[7]            MIME-Version := text

>Thus, future  format  specifiers,  which  might  replace  or
extend  "1.0", are (minimally) constrained by the definition
of "text", which appears in RFC 822.

>Note that the MIME-Version header field is required  at  the
top  level  of  a  message. It is not required for each body
part of a multipart entity.  It is required for the embedded
headers  of  a  body  of  type  "message" if and only if the
embedded message is itself claimed to be MIME-compliant.

***Appendix A -- Minimal MIME-Conformance (抜粋)
>1.  Always generate a "MIME-Version:  1.0"  header                field.

**RFC 1521 (MIME 第2版第1部)
***1. Introduction (抜粋)
>1. A MIME-Version header field, which uses a version number to
declare a message to be conformant with this specification and
allows mail processing agents to distinguish between such
messages and those generated by older or non-conformant software,
which is presumed to lack such a field.

[9] [CODE[MIME-Version]] 頭欄。これはメッセージが MIME 
に適合することを宣言するために版番号を使用し、メイル処理エージェントが適合メッセージと古い非適合のメッセージでこの欄を欠いていると考えられるものを識別出来ます。
***3.    The MIME-Version Header Field
>Since RFC 822 was published in 1982, there has really been only one
format standard for Internet messages, and there has been little
perceived need to declare the format standard in use.  This document
is an independent document that complements RFC 822. Although the
extensions in this document have been defined in such a way as to be
compatible with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know whether a
message was composed with the new standard in mind.

[11] [[RFC822]] が 1982 年に出版されてから、 Internet
メッセージには本当に唯一の標準だけがあり、使用している書式規格を宣言する必要を感じることはほとんどありませんでした。
この文書は RFC 822 を補完する独立した仕様です。この文書の拡張は RFC 822
と互換性があるように定義しますが、それでもメイル処理エージェントが、メッセージが新しい規格で構成されたのかどうかを知ることが出来るのが望ましいという事情があります。

>Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet message
body format standard in use.

>Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:

>   MIME-Version: 1.0

>The presence of this header field is an assertion that the message
has been composed in compliance with this document.

>Since it is possible that a future document might extend the message
format standard again, a formal BNF is given for the content of the
MIME-Version field:

-   version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

>Thus, future format specifiers, which might replace or extend "1.0",
are constrained to be two integer fields, separated by a period.  If
a message is received with a MIME-version value other than "1.0", it
cannot be assumed to conform with this specification.

>Note that the MIME-Version header field is required at the top level
of a message. It is not required for each body part of a multipart
entity.  It is required for the embedded headers of a body of type
"message" if and only if the embedded message is itself claimed to be MIME-conformant.

>It is not possible to fully specify how a mail reader that conforms
with MIME as defined in this document should treat a message that
might arrive in the future with some value of MIME-Version other than
"1.0".  However, conformant software is encouraged to check the
version number and at least warn the user if an unrecognized MIME-version 
is encountered.

>It is also worth noting that version control for specific content-
types is not accomplished using the MIME-Version mechanism.  In
particular, some formats (such as application/postscript) have
version numbering conventions that are internal to the document
format.  Where such conventions exist, MIME does nothing to supersede
them.  Where no such conventions exist, a MIME type might use a
"version" parameter in the content-type field if necessary.

>NOTE TO IMPLEMENTORS: All header fields defined in this document,
including MIME-Version, Content-type, etc., are subject to the
general syntactic rules for header fields specified in RFC 822.  In
particular, all can include comments, which means that the following
two MIME-Version fields are equivalent:

-                    MIME-Version: 1.0
-                    MIME-Version: 1.0 (Generated by GBD-killer 3.7)
***Appendix A -- Minimal MIME-Conformance (抜粋)
>1.  Always generate a "MIME-Version: 1.0" header field.

**RFC 2045 (MIME 第3版第1部)
***1. Introduction (抜粋)
>(1)   A MIME-Version header field, which uses a version
number to declare a message to be conformant with MIME
and allows mail processing agents to distinguish
between such messages and those generated by older or
non-conformant software, which are presumed to lack such a field.

[8] [CODE[MIME-Version]] 頭欄。これはメッセージが MIME 
に適合することを宣言するために版番号を使用し、メイル処理エージェントが適合メッセージと古い非適合のメッセージでこの欄を欠いていると考えられるものを識別出来ます。

***4.  MIME-Version Header Field
>Since RFC 822 was published in 1982, there has really been only one
format standard for Internet messages, and there has been little
perceived need to declare the format standard in use.  This document
is an independent specification that complements RFC 822.  Although
the extensions in this document have been defined in such a way as to
be compatible with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know whether a
message was composed with the new standard in mind.

[10] [[RFC822]] が 1982 年に出版されてから、 Internet
メッセージには本当に唯一の標準だけがあり、使用している書式規格を宣言する必要を感じることはほとんどありませんでした。
この文書は RFC 822 を補完する独立した仕様です。この文書の拡張は RFC 822
と互換性があるように定義しますが、それでもメイル処理エージェントが、メッセージが新しい規格で構成されたのかどうかを知ることが出来るのが望ましいという事情があります。

>Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet message
body format standard in use.

>Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:

-     MIME-Version: 1.0

>The presence of this header field is an assertion that the message
has been composed in compliance with this document.

>Since it is possible that a future document might extend the message
format standard again, a formal BNF is given for the content of the
MIME-Version field:

-     version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

>Note that the MIME-Version header field is required at the top level
of a message.  It is not required for each body part of a multipart
entity.  It is required for the embedded headers of a body of type
"message/rfc822" or "message/partial" if and only if the embedded
message is itself claimed to be MIME-conformant.

>It is also worth noting that version control for specific media types
is not accomplished using the MIME-Version mechanism.  In particular,
some formats (such as application/postscript) have version numbering
conventions that are internal to the media format.  Where such
conventions exist, MIME does nothing to supersede them.  Where no
such conventions exist, a MIME media type might use a "version"
parameter in the content-type field if necessary.

>NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
comment strings that are present must be ignored.  In particular, the
following four MIME-Version fields are equivalent:

-     MIME-Version: 1.0
-     MIME-Version: 1.0 (produced by MetaSend Vx.x)
-     MIME-Version: (produced by MetaSend Vx.x) 1.0
-     MIME-Version: 1.(produced by MetaSend Vx.x)0

>In the absence of a MIME-Version field, a receiving mail user agent
(whether conforming to MIME requirements or not) may optionally
choose to interpret the body of the message according to local
conventions.  Many such conventions are currently in use and it
should be noted that in practice non-MIME messages can contain just
about anything.

MIME-Version 領域がかけている場合、受信したメイル利用者代理者
(MIME 必要条件に適合してもしなくても) は任意でメッセージの本体を
地方の慣習で解釈することを選んでも良い。そのような慣習が多く
現在行われていて、実際には非 MIME メッセージは本当に何でも
含み得ることに注意されたい。

>It is impossible to be certain that a non-MIME mail message is
actually plain text in the US-ASCII character set since it might well
be a message that, using some set of nonstandard local conventions
that predate MIME, includes text in another character set or non-
textual data presented in a manner that cannot be automatically
recognized (e.g., a uuencoded compressed UNIX tar file).

非 MIME メイル・メッセージが実際 plain text で US-ASCII 文字集合であるかを
確認するのは不可能です。他の文字集合の文書や自動的に認識できない手法 
(例えば uuencode して圧縮した UNIX の tar 玉) で表現された文字でない
データ表現などの MIME 以前の非標準地方慣習の集合を使っているメッセージ
かもしれないのです。

**RFC 2047 (MIME 第3版)
***6.1. Recognition of 'encoded-word's in message headers (抜粋)
[21]
>(4) A MIME-Version header field is NOT required to be present for
'encoded-word's to be interpreted according to this
specification.  One reason for this is that the mail reader is
not expected to parse the entire message header before displaying
lines that may contain 'encoded-word's.

(4) MIME-Version 頭領域はこの仕様書により解釈される 「encoded-word」
の出現に必要では''ありません''。この理由の一つは
メイル読者が「encoded-word」を含むかもしれない行を表示する前に
メッセージ頭全体を解析することが期待されていないことです。

** HTTP

[FIG(quote)[
[FIGCAPTION[
[32] RFC 1945 (HTTP/1.0) D.2.7; RFC 2068 (HTTP/1.1) 19.4.7; RFC 2616 (HTTP/1.1) 19.4.1 MIME-Version
]FIGCAPTION]

> [INS[[INS[{2068,2616}]] HTTP is not a MIME-compliant protocol [DEL[(see appendix 19.4)]].]] [INS[[INS[{2068,2616}]] However,]] HTTP[INS[/1.1]]
messages [DEL[may]] [INS[[INS[{2616}]] MAY]] include a single MIME-Version general-header field
to indicate what version of the MIME protocol was used to construct
the message. Use of the MIME-Version header field[DEL[, [INS[{1945}]] as defined by RFC 1521 [5], should indicate]] [INS[indicates]]
that the message is [DEL[[INS[{1945}]] MIME-conformant]] [INS[in full compliance with the MIME protocol [INS[(as defined in RFC 2045[7])]]]]. [DEL[[INS[{1945}]] Unfortunately, some older HTTP/1.0 servers send it indiscriminately, and thus this field should be ignored.]] [INS[[INS[{2068,2616}]] Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME environments.]]

[4] HTTP は MIME に従ったプロトコルではありません。しかし、 
HTTP/1.1 メッセージは一つの MIME-Version 
一般頭欄を、メッセージの構築に使った MIME 
[[プロトコル]]の版を示すために含めても構いません。
MIME-Version 頭欄の使用は、メッセージが (RFC 2045 で定義された) 
MIME プロトコルに完全に適合することを示します。
串や関門は厳密な MIME 環境に HTTP メッセージを輸出する時に 
(可能である所で) 完全に適合させる責任があります。

[INS[
>[INS[{2068,2616}]]
- MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

> MIME version "1.0" is the default for use in HTTP/1.1. However,
HTTP/1.1 message parsing and semantics are defined by this document
and not the MIME specification.

MIME の版 "1.0" が HTTP/1.1 で使う時の既定値です。しかし、
HTTP/1.1 メッセージの解析と意味は MIME 
仕様ではなくこの文書で定義されます。
]INS]
]FIG]

[33] [[RFC 2068]] と [[RFC 2616]] は構文も規定していましたが、
[[RFC 1945]] と [[RFC 7231]] は構文の規定を含んでいません。

* 例

[30] 
>
[PRE(HTTP bad example code)[
MIME-Version: 1
]PRE]

;; [CITE@en[HTTP/1.1 MIME-Version header]] ([TIME[2009-07-19 11:36:18 +09:00]] 版) <http://www.http-stats.com/MIME-Version>

[40] [CITE@en[RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)]]
( ([TIME[2014-09-21 21:13:43 +09:00]] 版))
<http://tools.ietf.org/html/rfc4130#appendix-A.3>

[FIG(quote)[
[FIGCAPTION[
[41] [CITE@en[RFC 2653 - CIP Transport Protocols]]
([TIME[2015-05-03 15:13:10 +09:00]] 版)
<https://tools.ietf.org/html/rfc2653>
]FIGCAPTION]

> 
>    Version-Hdr    = "Mime-Version:" "1.0" CRLF

]FIG]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)