[1] MIME-Version: 頭欄は、 RFC 822 (現 RFC 5322)
メッセージが MIME を使用している版を表します。
[22] 元々名前の通り MIME の版を表す頭欄として導入され、現行の
RFC 2045 でもそのように説明されていますが、唯一の版番号
1.0 が (小改訂の後も) 使われていて、
将来新しい版番号が導入されることもないだろうとの見解が示されています >>13。
1.0 以上の値MIME-Version: 1.1 のメッセージって意外とあるみたい。どういう仕様でしょうねぇ。1.1.1 とか 1.1.2 とかも見つかりました! 但しそのメッセージには謎の charset iso-8860-1 がついてたりしますが。。。Mime-Version: 1.1b && X-Mailer: Windows Eudora Version 1.5.2MIME-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 : 最初は単なる MIME-Version: 2.4
ハァ? という話題でしたが、途中でネタ化して・・・。
IPv9 が実用化されて(略)
[39] VPIM では、 MIME-Version: 1.0 (Voice 1.0) >>36 や
MIME-Version: 1.0 (Voice 2.0) >>38
のような注釈を記述するべきとされています。
[23] MIME-Version: 頭欄は、電子メイルや電子ニュースで用いられている
RFC 822 (現 RFC 5322) メッセージで使用することができます。
[24] 多部分メッセージに含まれる MIME 実体や、 BEEP
など RFC 822 メッセージ以外に含まれる MIME 実体では、
MIME-Version: 頭欄は用いられません。
[14] 複数部分の本体部分の MIME 実体になぜか MIME-Version 欄つけてる実装を見かけました。まあ無害ですがね。
[26] HTTP は MIME 風のメッセージの構造を採用しており、
主に初期の実装では MIME-Version: 頭欄が用いられることがありました。
HTTP の初期の仕様書でも触れられている他、後の RFC でも参考として説明が掲載されています。
[31] HTTPメッセージは MIME-Version:
ヘッダーを1つ含めることができます。これは当該メッセージの構築に使った
MIME の版を表し、 MIME に完全に適合することを表します。 >>12
Transfer-Encoding:
や Content-Encoding: の利用が認められているのかどうか不明瞭です。[42]
FIPA MTP HTTP要求およびその multipart/mixed
の実体は指定することを要求しています。
(が提示されている例文にはHTTP要求の方にしか書かれていません。)
[25] GNU Gettext などで用いられている POファイルは、頭部として
RFC 822 風の欄の構造を持った部分を記述しますが、
そこで MIME-Version: 欄も指定されます。
実際問題この欄の指定には意味も本来の MIME との互換性もないように思えますが・・・。
encoded-word との関係[20] この欄が影響するのは、電子メイル本体部を MIME
的に解釈するか否かです。電子メイル頭部での
encoded-word 使用の如何とは無関係です。
(RFC 2045・2046 の規定内容に従う時は MIME-Version が関係しますが、 RFC 2047 の規定内容に従うか否かは関係しません。ちなみに encoded-word の使用如何を明示する方法はありません。)
この件については昔から誤解が絶えません。 大昔の規定 (1341 の昔) ではこの問題に明確に言及されていなかったのですが、 後の改訂で RFC 本文にはっきり明記されています。 (>>21 参照。)
[27] MIME 本体仕様は RFC 1341、RFC 1521、RFC 2045〜RFC 2049
と2回改訂がありましたが、 MIME-Version:
欄の値は変わっていません。新たな頭欄が追加されたり RFC 2231
による構文拡張が行われたりしていますが、それでも値は追加されませんでした。
[28] 今後も MIME 仕様に非互換な変更を加えることは実質的に不可能でしょうから、 新しい版番号を導入して区別する必要性も生じないでしょう。 新しい版番号を導入すると既存の実装との互換性もなくなってしまいます。 従って >>13 のように新たな版番号となることはないだろうとの関係者の見解もあります。
[29] もっとも、現存の利用者エージェントで MIME-Version:
欄の値を調べ、それによって解釈を変更するようなものがどれだけあるかは疑問です。
黎明期には MIMEメッセージと非 MIMEメッセージを区別するために用いていた
MUA もあったようですが、今となってはその必要もないでしょう。
そんなわけで、 MIME-Version: 欄は実質的に意義を失っているものと推測されます。
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] MIME-Version 頭欄。これはメッセージが MIME
に適合することを宣言するために版番号を使用し、メイル処理エージェントが適合メッセージと古い非適合のメッセージでこの欄を欠いていると考えられるものを識別出来ます。
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.
Messages composed in accordance with this document MUST include such a header field, with the following verbatim text:
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:
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.
1. Always generate a "MIME-Version: 1.0" header field.
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] MIME-Version 頭欄。これはメッセージが MIME
に適合することを宣言するために版番号を使用し、メイル処理エージェントが適合メッセージと古い非適合のメッセージでこの欄を欠いていると考えられるものを識別出来ます。
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:
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:
1. Always generate a "MIME-Version: 1.0" header field.
(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] MIME-Version 頭欄。これはメッセージが MIME
に適合することを宣言するために版番号を使用し、メイル処理エージェントが適合メッセージと古い非適合のメッセージでこの欄を欠いていると考えられるものを識別出来ます。
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:
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:
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 document.
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 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".
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:
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 以前の非標準地方慣習の集合を使っているメッセージ かもしれないのです。
(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」を含むかもしれない行を表示する前に メッセージ頭全体を解析することが期待されていないことです。
{2068,2616} HTTP is not a MIME-compliant protocol
(see appendix 19.4). {2068,2616} However, HTTP/1.1 messagesmay{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, {1945} as defined by RFC 1521 [5], should indicateindicates that the message is{1945} MIME-conformantin full compliance with the MIME protocol (as defined in RFC 2045[7]).{1945} Unfortunately, some older HTTP/1.0 servers send it indiscriminately, and thus this field should be ignored.{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 メッセージを輸出する時に (可能である所で) 完全に適合させる責任があります。
{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 仕様ではなくこの文書で定義されます。
[33] RFC 2068 と RFC 2616 は構文も規定していましたが、 RFC 1945 と RFC 7231 は構文の規定を含んでいません。
MIME-Version: 1
[40] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) ( ( 版)) http://tools.ietf.org/html/rfc4130#appendix-A.3
Version-Hdr = "Mime-Version:" "1.0" CRLF