MIME適合性

MIME適合性

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."
            -- 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 also

License

See RFCのライセンス