There was some confusion, in earlier versions of these documents,
   regarding the model for when email data was to be converted to
   canonical form and encoded, and in particular how this process would
   affect the treatment of CRLFs, given that the representation of
   newlines varies greatly from system to system.  For this reason, a
   canonical model for encoding is presented below.

   The process of composing a MIME entity can be modeled as being done
   in a number of steps.  Note that these steps are roughly similar to
   those steps used in PEM [RFC-1421] and are performed for each
   "innermost level" body:

MIME 実体の構成の過程は、次の手順にモデル化できます。 なお、この手順は PEM での手順とおおよそ同じであり、 また各「最奥級」本文に施します。

    (1)   Creation of local form.

局地形の作成

          The body to be transmitted is created in the system's
          native format.  The native character set is used and,
          where appropriate, local end of line conventions are
          used as well.  The body may be a UNIX-style text file,
          or a Sun raster image, or a VMS indexed file, or audio
          data in a system-dependent format stored only in
          memory, or anything else that corresponds to the local
          model for the representation of some form of
          information.  Fundamentally, the data is created in the
          "native" form that corresponds to the type specified by
          the media type.

転送される本文は系統の母型 native format で作成します。 母 native 文字集合を使い、適切なところで局地 local 行末記法をも使います。 本文は UNIX 型文ファイルでも Sun ラスタ画像でも VMS 索引ファイルでも、 系統依存形式の主記憶にのみ保管される形式の音声データでも、 その他の情報形式の表現の局地モデルに対応するどんなものでも構いません。 根本的に、データは媒体型で規定される型に対応する「母 native」形式 で作られます。

    (2)   Conversion to canonical form.

正規形に変換

          The entire body, including "out-of-band" information
          such as record lengths and possibly file attribute
          information, is converted to a universal canonical
          form.  The specific media type of the body as well as
          its associated attributes dictate the nature of the
          canonical form that is used.  Conversion to the proper
          canonical form may involve character set conversion,
          transformation of audio data, compression, or various
          other operations specific to the various media types.
          If character set conversion is involved, however, care
          must be taken to understand the semantics of the media
          type, which may have strong implications for any
          character set conversion, e.g. with regard to
          syntactically meaningful characters in a text subtype
          other than "plain".

記録 record 長やファイル属性情報とかの「外部 out-of-band」情報を含む実体本文 を普遍正規形に変換します。本文の特定の媒体型とその関連付けられた 属性に使われる正規形の性質を書きます。適切な正規形への変換は 文字集合の変換, 音声データの変形, 圧縮, その他の各種媒体型特有の 処理を含みます。しかし、文字集合変換が含まれる場合には、 例えば "plain" 以外の亜型では構文的に意味のある文字に関して、 文字集合の変換に強い関わりを持つかもしれないので、媒体型の意味を理解する よう注意しなければなりません。

          For example, in the case of text/plain data, the text
          must be converted to a supported character set and
          lines must be delimited with CRLF delimiters in
          accordance with RFC 822.  Note that the restriction on
          line lengths implied by RFC 822 is eliminated if the
          next step employs either quoted-printable or base64
          encoding.

例えば、 text/plain データの場合、文は対応している文字集合に変換して 行を RFC 822 に従って CRLF で区切らなければなりません。 なお、 RFC 822 による行長制限は次の段階で quoted-printable か base64 の符号化を使うなら無視します。

    (3)   Apply transfer encoding.

転送符号化を施す。

          A Content-Transfer-Encoding appropriate for this body
          is applied.  Note that there is no fixed relationship
          between the media type and the transfer encoding.  In
          particular, it may be appropriate to base the choice of
          base64 or quoted-printable on character frequency
          counts which are specific to a given instance of a
          body.

この本文に適切な CTE を適応します。なお、媒体型と転送符号化の間には 固定された関係はありません。が特に、 base64 と quoted-printable を本文の文字頻度に基づいて選択するのが適切かもしれません。

    (4)   Insertion into entity.

実体に挿入。

          The encoded body is inserted into a MIME entity with
          appropriate headers. The entity is then inserted into
          the body of a higher-level entity (message or
          multipart) as needed.

符号化本文を MIME 実体に適切な頭と共に挿入します。実体はこの時 必要であれば高水準実体 (メッセージか多部分) の本文中に挿入します。

   Conversion from entity form to local form is accomplished by
   reversing these steps. Note that reversal of these steps may produce
   differing results since there is no guarantee that the original and
   final local forms are the same.

実体から局地形の変換は逆の手順を踏むことで行えます。 なお、この逆の手順を踏んだ時には、元の局地形と後のが同じになる保証は無いので、 違った結果を生むかもしれません。

   It is vital to note that these steps are only a model; they are
   specifically NOT a blueprint for how an actual system would be built.
   In particular, the model fails to account for two common designs:

この手順はモデルに過ぎないというのが重要です。実際の系統をどう組み立てるかの 具体的な青写真ではありません。特に、モデルは2つの共通な設計を 組み入れていません。

    (1)   In many cases the conversion to a canonical form prior
          to encoding will be subsumed into the encoder itself,
          which understands local formats directly.  For example,
          the local newline convention for text bodies might be
          carried through to the encoder itself along with
          knowledge of what that format is.

多くの場合符号化の前の正規形への変換は、局地形式を直接理解する 符号化者を包摂している。例えば、文本文の局地改行変換は その形式が何かの知識と共に符号化者自身が最後まで行うかもしれない。

    (2)   The output of the encoders may have to pass through one
          or more additional steps prior to being transmitted as
          a message.  As such, the output of the encoder may not
          be conformant with the formats specified by RFC 822.
          In particular, once again it may be appropriate for the
          converter's output to be expressed using local newline
          conventions rather than using the standard RFC 822 CRLF
          delimiters.

符号化者の出力はメッセージとして転送される前に一つ以上の追加の手順を踏む 必要があるかもしれない。符号化者の出力が RFC 822 で規定する形式に 適合しないかもしれない。特に、もう一度標準 RFC 822 CRLF 区切りを使うのでなく局地改行慣習を使って表現するようにするのが 変換者の出力には適切かもしれない。

   Other implementation variations are conceivable as well.  The vital
   aspect of this discussion is that, in spite of any optimizations,
   collapsings of required steps, or insertion of additional processing,
   the resulting messages must be consistent with those produced by the
   model described here.  For example, a message with the following
   header fields:

他の実装変形も同様に考えられます。この話の大切な点は、 最適化したとしても、必要な手順を省いても、または追加の処理の挿入でも、 結果のメッセージは個々で説明するモデルで生成したものと一致しなければならない ということです。例えば、次の頭領域のメッセージ

     Content-type: text/foo; charset=bar
     Content-Transfer-Encoding: base64

   must be first represented in the text/foo form, then (if necessary)
   represented in the "bar" character set, and finally transformed via
   the base64 algorithm into a mail-safe form.

はまず text/foo 形式で表現され、 "bar" 文字集合で (必要なら) 表現し、 最後に base64 算法でメイル安全形に変形しなければなりません。

   NOTE: Some confusion has been caused by systems that represent
   messages in a format which uses local newline conventions which
   differ from the RFC822 CRLF convention.  It is important to note that
   these formats are not canonical RFC822/MIME.  These formats are
   instead *encodings* of RFC822, where CRLF sequences in the canonical
   representation of the message are encoded as the local newline
   convention.  Note that formats which encode CRLF sequences as, for
   example, LF are not capable of representing MIME messages containing
   binary data which contains LF octets not part of CRLF line separation
   sequences.