*RFC 2049 2. MIME Conformance The mechanisms described in these documents are open-ended. It is definitely not expected that all implementations will support all available media types, nor that they will all share the same extensions. In order to promote interoperability, however, it is useful to define the concept of "MIME-conformance" to define a certain level of implementation that allows the useful interworking of messages with content that differs from US-ASCII text. In this section, we specify the requirements for such conformance. これらの文書で説明した機構は青天井です。全ての実装が全ての利用可能な 媒体型に対応することも、同じ拡張を全て共有することも確かに期待していません。 しかし相互通信性の拡展のため、 US-ASCII 文以外の内容を持つメッセージの 便利なネットワーク間作業が出来る実装の水準を決める、 「MIME 適合」の概念を定義することは有用です。この節では、 この適合性の要件について規定します。 A mail user agent that is MIME-conformant MUST: MIME 適合メイル利用者代理者は次の様にし'''なければなりません'''。 (1) Always generate a "MIME-Version: 1.0" header field in any message it creates. (1) その作成するメッセージに必ず "MIME-Version: 1.0" 頭領域を生成する。 (2) Recognize the Content-Transfer-Encoding header field and decode all received data encoded by either quoted- printable or base64 implementations. The identity transformations 7bit, 8bit, and binary must also be recognized. CTE 頭領域を認識して quoted-printable か base64 のどちらかの実装 で符号化された全ての受信データを復号する。 Any non-7bit data that is sent without encoding must be properly labelled with a content-transfer-encoding of 8bit or binary, as appropriate. If the underlying transport does not support 8bit or binary (as SMTP [RFC-821] does not), the sender is required to both encode and label data using an appropriate Content- Transfer-Encoding such as quoted-printable or base64. 符号化せずに送る非 7ビット・データは8ビットまたはバイナリの 内容転送符号化で必ず適切に札付けする。下の転送が8ビットやバイナリ に対応していない (SMTP はしていないように。) 場合は送信者は データを quoted-printable か base64 の様な適切な CTE で符号化して札付けする (3) Must treat any unrecognized Content-Transfer-Encoding as if it had a Content-Type of "application/octet- stream", regardless of whether or not the actual Content-Type is recognized. (3) 認識出来ない CTE を、実際の CT が認識できるか否かに関わらず CT "a/os" を持つものとして扱わなければならない。 (4) Recognize and interpret the Content-Type header field, and avoid showing users raw data with a Content-Type field other than text. Implementations must be able to send at least text/plain messages, with the character set specified with the charset parameter if it is not US-ASCII. (4) CT 頭領域を認識・解釈し、 CT 領域がある生データを利用者に 文以外で見せることを避ける。実装者は最低でも text/plain メッセージを、 文字集合が US-ASCII でない場合は charset パラメーターに指定した上で、 送ることが出来なければなりません。 (5) Ignore any content type parameters whose names they do not recognize. (5) 名前を認識出来ない内容型パラメーターは無視する。 (6) Explicitly handle the following media type values, to at least the following extents: (6) 次の媒体型値を、最低でも次の程度明白に扱う。 Text: -- Recognize and display "text" mail with the character set "US-ASCII." -文字集合 "US-ASCII" の "text" メイルを認識・表示する。 -- Recognize other character sets at least to the extent of being able to inform the user about what character set the message uses. -他の文字集合を、少なくても利用者にどの文字集合がメッセージに使われている かを告げることが出来る程度に認識する。 -- Recognize the "ISO-8859-*" character sets to the extent of being able to display those characters that are common to ISO-8859-* and US-ASCII, namely all characters represented by octet values 1-127. -"ISO-8859-*" 文字集合を ISO-8859-* と US-ASCII で共通な部分、 すなわちオクテット値 1-127 で表現される全ての文字を表示できる程度に 認識する。 -- For unrecognized subtypes in a known character set, show or offer to show the user the "raw" version of the data after conversion of the content from canonical form to local form. -既知の文字集合の認識出来ない亜型には、「生」版のデータを、 内容を正規形から局地形に変換した後に利用者に表示するかまたは 表示するかを尋ねる。 -- Treat material in an unknown character set as if it were "application/octet-stream". -未知の文字集合のものを "a/os" であるとして扱う。 Image, audio, and video: -- At a minumum provide facilities to treat any unrecognized subtypes as if they were "application/octet-stream". -最低でも未知の亜型を "" であるとして扱う機能を提供する。 Application: -- Offer the ability to remove either of the quoted- printable or base64 encodings defined in this document if they were used and put the resulting information in a user file. -結果情報を利用者ファイルに入れるときにこの文書で定義する quoted-printable か base64 の符号化が使われていれば それを解く能力を提供する。 訳注: 「この文書」とは古い版の名残か。 RFC 2045 に定義がある。 Multipart: -- Recognize the mixed subtype. Display all relevant information on the message level and the body part header level and then display or offer to display each of the body parts individually. -mixed 亜型を認識する。メッセージ級および本文部分頭級の関連情報を 全て表示し、各本文部分を個々に表示するかまたは表示するかを尋ねる。 -- Recognize the "alternative" subtype, and avoid showing the user redundant parts of multipart/alternative mail. -"a" 亜型を認識し、 m/a メイルの余分な部分を利用者に見せるのを避ける。 -- Recognize the "multipart/digest" subtype, specifically using "message/rfc822" rather than "text/plain" as the default media type for body parts inside "multipart/digest" entities. -"M/D" 亜型を認識する。具体的には "m/d" 実体の内側の本文部分の既定の媒体型は "t/p" ではなく "m/r" を使う。 - Treat any unrecognized subtypes as if they were "mixed". -認識出来ない亜型を "m" であるとして扱う。 Message: -- Recognize and display at least the RFC822 message encapsulation (message/rfc822) in such a way as to preserve any recursive structure, that is, displaying or offering to display the encapsulated data in accordance with its media type. -- Treat any unrecognized subtypes as if they were "application/octet-stream". -最低でも RFC822 メッセージ・カプセル化 () を再帰構造を保ったままの方法で 認識して表示する、 つまりカプセル化されたデータをその媒体型によって表示するかまたは 表示するかを尋ねる。 -認識出来ない亜型を "" であるとして扱う。 (7) Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input. 認識出来ない CT 領域に遭遇した場合、実装はこれをパラメーター 小引数を持たない媒体型 "" であるとして扱わなければならない。 この様なデータをどう扱うかは実装の裁量とするが、このような 認識出来ないデータの取り扱いの適当な選択肢は、これをファイルに書く (メイル転送形式から復号して) ことを利用者に申し出るか、 復号したデータを入力として渡すプログラムの名前を利用者に尋ねることを含む。 (8) Conformant user agents are required, if they provide non-standard support for non-MIME messages employing character sets other than US-ASCII, to do so on received messages only. Conforming user agents must not send non-MIME messages containing anything other than US-ASCII text. 適合利用者代理者は US-ASCII 以外の文字集合を使った非 MIME メッセージ の非標準な対応を含める場合、受信したメッセージのみそうする。 適合利用者代理者は US-ASCII 文以外のものを含む非 MIME メッセージ を送ってはならない。 In particular, the use of non-US-ASCII text in mail messages without a MIME-Version field is strongly discouraged as it impedes interoperability when sending messages between regions with different localization conventions. Conforming user agents MUST include proper MIME labelling when sending anything other than plain text in the US-ASCII character set. 特に、非 US-ASCII 文をメイル・メッセージ中で MIME-Version 領域無しに 使うことは、違った地域化慣習を持つ地域間でのメッセージ送信時の 相互通信性の悪化を招くので強く非推奨とします。適合利用者代理者は 適切な MIME 札付けを US-ASCII 文字集合以外による平文以外のものを送る時は 含め'''なければなりません'''。 In addition, non-MIME user agents should be upgraded if at all possible to include appropriate MIME header information in the messages they send even if nothing else in MIME is supported. This upgrade will have little, if any, effect on non-MIME recipients and will aid MIME in correctly displaying such messages. It also provides a smooth transition path to eventual adoption of other MIME capabilities. 加えて、非 MIME 利用者代理者は、その送るメッセージに適切な MIME 頭情報を含めることが 卑しくも可能なように、それ以外に MIME に対応していない場合でも 昇格させるべきです。この昇格はあっても少ししか非 MIME 受信者に 影響しませんし、かようなメッセージを MIME が正しく表示するのを 助けることになります。また、更なる MIME 機能の採用へのスムーズな移行経路 ともなります。 (9) Conforming user agents must ensure that any string of non-white-space printable US-ASCII characters within a "*text" or "*ctext" that begins with "=?" and ends with "?=" be a valid encoded-word. ("begins" means: At the start of the field-body or immediately following linear-white-space; "ends" means: At the end of the field-body or immediately preceding linear-white- space.) In addition, any "word" within a "phrase" that begins with "=?" and ends with "?=" must be a valid encoded-word. 適合利用者代理者は、 "*text" や "*ctext" 中の非空白間隔の印字可能 US-ASCII 文字の文字列で "=?" で始まって "?=" で終わるものを妥当な encoded-word としなければなりません。 (「始ま」るとは領域本文の始まりか行空白間隔の すぐ後を意味します。「終わる」とは領域本文の終わりか行空白間隔の直ぐ前を 意味します。) 加えて、 "phrase" 中の "word" で "=?" で始まり "?=" で終わるものを妥当な encoded-word としなければなりません。 (10) Conforming user agents must be able to distinguish encoded-words from "text", "ctext", or "word"s, according to the rules in section 4, anytime they appear in appropriate places in message headers. It must support both the "B" and "Q" encodings for any character set which it supports. The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the US-ASCII set. 適合利用者代理者は encoded-word を、第4章の規則により、 メッセージ頭中の適切な場所に出現した場合は常に、 "",,,"" と区別できなければなりません。 "B" と "Q" の両符号化をその対応する どの文字集合についても対応しなければなりません。プログラムは その文字集合が "" である場合に符号化前の文を表示できなければなりません。 ISO-8859-* 文字集合については、メイル読みプログラムは少なくても US-ASCII 集合中にもある部分は表示出来なければなりません。 訳注: 2047 から写したのかな? 第4章に[[符号化語]]の話はないよーん。 A user agent that meets the above conditions is said to be MIME- conformant. The meaning of this phrase is that it is assumed to be "safe" to send virtually any kind of properly-marked data to users of such mail systems, because such systems will at least be able to treat the data as undifferentiated binary, and will not simply splash it onto the screen of unsuspecting users. 上記の条件を満たす利用者代理者は MIME 適合を主張することが出来ます。 この言葉の意味は、適切に印付けされたほとんどどんなデータもそのメイル系統に 送っても「安全」であると仮定されるということです。というのはそのような系統は 少なくてもデータを無差別バイナリとして扱うことが出来、 疑いを持たない利用者の画面を単に壊してしまうことがないでしょうから。 There is another sense in which it is always "safe" to send data in a format that is MIME-conformant, which is that such data will not break or be broken by any known systems that are conformant with RFC 821 and RFC 822. User agents that are MIME-conformant have the additional guarantee that the user will not be shown data that were never intended to be viewed as text. 常に「安全に」データを MIME 適合の形式で送ることには、別の意味もあります。 この様なデータは RFC 821 と RFC 822 に適合する既知の系統を壊したり 壊されたりすることがありません。 MIME 適合利用者代理者は 利用者が文として見られることを全く意図していないデータを提示されない ことを加えて保証するものです。 *See also -[[MIME]] --RFC 2049 *License See [[RFCのライセンス]]