#?SuikaWiki/0.9 [1] [CODE[MIME-Version:]] 欄は、主に[[電子メイル]]で使って、メッセージ[[本体]]が [[MIME]] に従って解釈されること, 解釈に使用する MIME の版を指定するものです。 [[#comment]] *仕様書から **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 (抜粋) >(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 の部分の LICENSE See [[RFCのライセンス]] *メモ - [12] [[HTTP]] における [CODE[MIME-Version:欄]]については、 [[HTTP実体とMIME実体]>>4]を参照。 - [13] [WEAK[2003-03-03 17:32]] ''[[名無しさん]]'': 最近 (多分以前からだと思うが。) [[NedFreed]] が [[ietf-822]] で示した見解によれば、 MIME の版が 1.0 より大きな数になることは永遠に無いです。 - [14] [[複数部分]]の[[本体部分]]の MIME 実体になぜか [CODE(MIME)[MIME-Version]] 欄つけてる実装を見かけました。まあ無害ですがね。