附属書B. RFC 1521, 1522及び1590からの変更点

MIME関連の一連の標準情報(TR)は，RFC 1521，1522及び1590の改定である。 これんらの初期の規定を熟知している人に便利なように，初期の規定からの変更点をこの付属書に要約する。 それ以前の履歴については，RFC 1521のAppendix Hに，RFC 1521がその前の版のRFC 1341とどう異なっているかが明記されている。

1. 規定は完全に再構成され，複数の規定に分割された。 これは，参照原稿として必要とされる，プレーンテキスト版の規定の品質を高めるために行われた。
(1) This document has been completely reformatted and split into multiple documents. This was done to improve the quality of the plain text version of this document, which is required to be the reference copy.
2. MIMEオブジェクトヘッダの全体の構造を記述するBNFが追加された。 これは，文書が変更されただけで，根本的な文法は変わっていない。
(2) BNF describing the overall structure of MIME object headers has been added. This is a documentation change only -- the underlying syntax has not changed in any way.
3. MIMEの七つのメディア型のための特定のBNFは削除された。 このBNFは，不正確で，不完全で，型独立のBNFとは矛盾した。 型独立のBNFはすでに多くのMIMEヘッダの構文を完全に規定しているから，型特定のBNFは，結局，完全に不要であり，かえって問題を起こした。
(3) The specific BNF for the seven media types in MIME has been removed. This BNF was incorrect, incomplete, amd inconsistent with the type-indendependent BNF. And since the type-independent BNF already fully specifies the syntax of the various MIME headers, the type- specific BNF was, in the final analysis, completely unnecessary and caused more problems than it solved.
4. これらの規定の多くの部分で，非公式の用語である"ASCII"の使用は，より特定の意味をもつ"US-ASCII"文字集合の名前に置き換えた。
(4) The more specific "US-ASCII" character set name has replaced the use of the informal term ASCII in many parts of these documents.
5. 主下位型という非公式の概念は削除した。
(5) The informal concept of a primary subtype has been removed.
6. 用語"オブジェクト"は一貫せずに用いられていた。 この用語は，関連の用語"本体"，"本体部分"及び"実体"とともに明確化され，用法は適切に正された。
(6) The term "object" was being used inconsistently. The definition of this term has been clarified, along with the related terms "body", "body part", and "entity", and usage has been corrected where appropriate.
7. 境界マーカに先行するCRLFは，先行する本体部分ではなくマーカの一部であることを明確にするため，マルチパートメディア型のためのBNFは再整理された。
(7) The BNF for the multipart media type has been rearranged to make it clear that the CRLF preceeding the boundary marker is actually part of the marker itself rather than the preceeding body part.
8. マルチパートオブジェクト内の本体部分は，境界パラメタ文字列で始まる行を含んではならないことを明確にするため，マルチパートメディア型を記述する散文及びBNFは変更された。
(8) The prose and BNF describing the multipart media type have been changed to make it clear that the body parts within a multipart object MUST NOT contain any lines beginning with the boundary parameter string.
9. "message/partial"MIME実体を再組立てする規則で，内部メッセージからとるために，ヘッダの一覧に"Subject"が追加された。この点を明確にするため例が修正された。
(9) In the rules on reassembling "message/partial" MIME entities, "Subject" is added to the list of headers to take from the inner message, and the example is modified to clarify this point.
10. "message/partial"断片化は，行境界でのMIMEオブジェクトの分割だけに制限される。
(10) "Message/partial" fragmenters are restricted to splitting MIME objects only at line boundaries.
11. application/postscript型の議論において，PoseScript MIME実体の内側での2値データの組込みにより引き起こされる可能性のある相互運用可能性上の問題についての警告をする追加のパラグラフを追加した。
(11) In the discussion of the application/postscript type, an additional paragraph has been added warning about possible interoperability problems caused by embedding of binary data inside a PostScript MIME entity.
12. 次の二つの形式を明確にするために，Content-Typeヘッダフィールドのための基本構文規則を明確化する備考を加えた。
       Content-type: text/plain; charset=us-ascii (comment)
       Content-type: text/plain; charset="us-ascii"
    上記二つは完全に等しい
(12) Added a clarifying note to the basic syntax rules for the Content-Type header field to make it clear that the following two forms: Content-type: text/plain; charset=us-ascii (comment) Content-type: text/plain; charset="us-ascii" are completely equivalent.
13. MIME-Versionヘッダの議論から次の文を削除した。 「しかし，適合ソフトウェアは，版番号を検査し，少なくとも利用者に認識できないMIME-Versionに遭遇したことを警告することが推奨される。」
(13) The following sentence has been removed from the discussion of the MIME-Version header: "However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME-version is encountered."
14. "message/external-body"ではなく"application/external-body"といってしまっている誤植を修正した。
(14) A typo was fixed that said "application/external-body" instead of "message/external-body".
15. 要求を明確にするため，文字集合の定義を認識した。
(15) The definition of a character set has been reorganized to make the requirements clearer.
16. "image/gif"メデイァ型の定義は、別文書に移した。 この変更は、特許保護された技術の標準化を管理するIETF規則と矛盾が生じるおそれがあるため、行われた。 (16) The definition of the "image/gif" media type has been moved to a separate document. This change was made because of potential conflicts with IETF rules governing the standardization of patented technology.
17. "7ビット"及び"8ビット"の定義をきつくしたので、はだかのCR及びLFは行終端列としてだけとした。この文書は、実世界の実装とあわせるMIMEををもたらすため、NUL文字を保持することももはや要求しない。
(17) The definitions of "7bit" and "8bit" have been tightened so that use of bare CR, LF can only be used as end-of-line sequences. The document also no longer requires that NUL characters be preserved, which brings MIME into alignment with real-world implementations.
18. MIMEの正準テキストの定義をきつくし、改行はCRLF列であらわさなければならないことになった。 CR文字及びLF文字はこの用法以外にあってはならない。 それにともないquoted-printable符号化の定義が変更になった。
(18) The definition of canonical text in MIME has been tightened so that line breaks must be represented by a CRLF sequence. CR and LF characters are not allowed outside of this usage. The definition of quoted- printable encoding has been altered accordingly.
19. quoted-printable符号化の定義は、quoted-printble符号化器が不適切に符号化されたデータをどう扱うのが最もよいかについて、いくつかの推奨を含むようになった。
20. (19) The definition of the quoted-printable encoding now includes a number of suggestions for how quoted- printable encoders might best handle improperly encoded material.
21. マルチパート又は"8bit"又は"binary"データにカプセル化するメッセージ実体で、"7bit"、"8bit"及び"binary"転送符号化の使用を明確にする記述を加えた。
(20) Prose was added to clarify the use of the "7bit", "8bit", and "binary" transfer-encodings on multipart or message entities encapsulating "8bit" or "binary" data.
22. MIME適合性の章で、最小限のMIME適合性要件の一覧に、"multipart/digest"のサポートを追加した。
(21) In the section on MIME Conformance, "multipart/digest" support was added to the list of requirements for minimal MIME conformance. Also, the requirement for "message/rfc822" support were strengthened to clarify the importance of recognizing recursive structure.
23. "message"の下位型の多数の制限を、下位型ごとに基づいて規定した。
(22) The various restrictions on subtypes of "message" are now specified entirely on a subtype by subtype basis.
24. "message/rfc822"の定義は、"From"、"Subject"又は"Date"の少なくともいずれかなければならないように変更した。
(23) The definition of "message/rfc822" was changed to indicate that at least one of the "From", "Subject", or "Date" headers must be present.
25. 認識できない下位型を"application/octet-stream"として処理する要件は、型定義及び適合性指針の両方により明示的に作成された。
(24) The required handling of unrecognized subtypes as "application/octet-stream" has been made more explicit in both the type definitions sections and the conformance guidelines.
26. text/richtextを用いた例は、text/enrichedに変更された。
(25) Examples using text/richtext were changed to text/enriched.
27. 下位型のBNF定義は、IANA登録の下位型又は非標準の"X-"下位型がContent-Typeヘッダフィールドで使わなければならないことを明らかにすりょうに変更した。
(26) The BNF definition of subtype has been changed to make it clear that either an IANA registered subtype or a nonstandard "X-" subtype must be used in a Content-Type header field.
28. 使用するために単に登録されるMIMEメディア型とIETFにより標準化されるMIMEメディア型とをMIME BNFで区別した。
(27) MIME media types that are simply registered for use and those that are standardized by the IETF are now distinguished in the MIME BNF.
29. 多くのMIME登録手続きの全てを拡張的に修正した。 文字集合のためのIANA登録手続きは、この文書の集合に含まない、別の文書へと移動した。
(28) All of the various MIME registration procedures have been extensively revised. IANA registration procedures for character sets have been moved to a separate document that is no included in this set of documents.
30. これらの文書が定義しているUS-ASCII文字集合及びISO-8859-X文字集合におけるエスケープ及びシフト機構の使用を明確にした。 このような機構は、これらの文字集合及び使われる文字集合が未定義ななときに起る影響とともに使用してはならない。
(29) The use of escape and shift mechanisms in the US-ASCII and ISO-8859-X character sets these documents define have been clarified: Such mechanisms should never be used in conjunction with these character sets and their effect if they are used is undefined.
31. message/external-bodyのためのAFSアクセス型の定義は削除した。
(30) The definition of the AFS access-type for message/external-body has been removed.
32. multipart/alternative及びmessage/external-bodyを複合の処理は、特別に論じられている
(31) The handling of the combination of multipart/alternative and message/external-body is now specifically addressed.
33. message/external-bodyに特有のセキュリティ上の論点は、細かく論じられている。
(32) Security issues specific to message/external-body are now discussed in some detail.