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." -- 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. -- 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".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.訳注: 「この文書」とは古い版の名残か。 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. -- Recognize the "alternative" subtype, and avoid
showing the user redundant parts of
multipart/alternative mail. -- 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.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". (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 RFCのライセンス