[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つですね。 * 構文 @@ ・・・ ** [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?'' : 最初は単なる [CODE(822)[MIME-Version: 2.4]] ハァ? という話題でしたが、途中でネタ化して・・・。 [[IPv9]] が実用化されて(略) * 文脈 ** 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]] でも[[参考]]として説明が掲載されています。 ** 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 >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: - 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」を含むかもしれない行を表示する前に メッセージ頭全体を解析することが期待されていないことです。 ** 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 > [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] **RFC の部分の LICENSE See [[RFCのライセンス]] *メモ