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

MIME関連の一連の規定は，RFC 1521，1522及び1590の改訂である。初期の規定を熟知している人に便利なように，初期の規定からの変更点をこの附属書に要約する。それ以前の履歴に関して，RFC 1521がその前の版のRFC 1341とどのように異なるかをRFC 1521のAppendix Hが示している。

1. a) この規定は完全に再構成され，複数の規定に分割された。これは，参照原稿であるために必要とされる，この規定のプレーンテキスト版の品質を高めるために行われた。 (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. b) 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. c) 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. d) これらの規定の多くの部分における非公式の用語である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. e) 主下位型という非公式の概念を削除した。 (5) The informal concept of a primary subtype has been removed.

6. f) 用語“オブジェクト”は, 一貫性なしに用いられていた。この用語の定義は，関連の用語“本体”，“本体部分”及び“実体”とともに明確化され，用法は適切に訂正された。 (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. g) 境界マーカに先行する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. h) マルチパートオブジェクト内の本体部分は，境界パラメタ文字列で始まる行を含んではならないことを明確にするため，マルチパートメディア型を記述する普通文及び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. i) “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. j) “message/partial”素片化子は，行境界でのMIMEオブジェクトの分割だけに制限される。 (10) "Message/partial" fragmenters are restricted to splitting MIME objects only at line boundaries.

11. k) 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. l) 次の二つの形式を明確にするために，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. m) 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. n) “message/external-body”ではなく“application/external-body”とした誤植を修正した。 (14) A typo was fixed that said "application/external-body" instead of "message/external-body".

15. o) 要件を明確にするため，文字集合の定義を再構成した。 (15) The definition of a character set has been reorganized to make the requirements clearer.

16. p) “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. q) “7ビット”及び“8ビット”の定義を厳しくしたので，はだかのCR及びLFは行終端列として使用されるだけとした。この規定も，NUL文字を保存することをもはや要求しない。それは, MIMEを実世界の実装と整合させる。 (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. r) 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. s) quoted-printable符号化の定義は，quoted-printble符号化器が不適切に符号化されたデータをどう扱うのが最もよいかについて，今では多くの推奨を含む。
(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.
20. t) “8bit”又は“2値”データにカプセル化するメッセージ実体又はマルチパートで, “7bit”，“8bit”及び“2値”の転送符号化の使用を明確にする普通文を加えた。 (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.

21. u) MIME適合性の節において，最小限のMIME適合性に関する要件の一覧に“multipart/digest”のサポートを追加した。“message/rfc822”のサポートのための用件も，再帰構造を認識することの重要性を明確にするために, 強化された。 (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.

22. v) “message”の下位型の様々な制限は，今では下位型ごと完全に規定されている。 (22) The various restrictions on subtypes of "message" are now specified entirely on a subtype by subtype basis.

23. w) “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.

24. x) 認識できない下位型の“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.

25. y) text/richtextを用いた例は，text/enrichedに変更された。 (25) Examples using text/richtext were changed to text/enriched.

26. z) 下位型の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.

27. aa) 使用するために単に登録される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.

28. ab) 様々な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.

29. ac) これらの規定が定義している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.

30. ad) message/external-bodyのためのAFSアクセス型の定義を削除した。 (30) The definition of the AFS access-type for message/external-body has been removed.

31. ae) multipart/alternativeとmessage/external-bodyとの組合せの処理には，今は特に言及していない。 (31) The handling of the combination of multipart/alternative and message/external-body is now specifically addressed.

32. af) message/external-bodyに固有のセキュリティの課題は，今では細かく示されている。 (32) Security issues specific to message/external-body are now discussed in some detail.