非官方中文译本声明：本页为 IETF RFC 2049《MIME 第四部分（注册流程）》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc2049。

RFC 2049：MIME 第五部分（一致性标准与示例）

Internet Engineering Task Force (IETF) · N. Freed（Innosoft）、N. Borenstein（First Virtual）· 1996 年 11 月 · 类别：Standards Track（标准跟踪）· 取代 RFC 1521、1522、1590

封面与文档信息

网络工作组（Network Working Group）　N. Freed

请求评论（Request for Comments）：2049　　所属机构：Innosoft

取代（Obsoletes）：1521、1522、1590　　类别：Standards Track（标准跟踪）　　合作作者：N. Borenstein（First Virtual）

日期：1996 年 11 月

标题：多用途 Internet 邮件扩展（MIME）第五部分：一致性标准与示例（Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples）

本备忘录的状态

本文档为 Internet 团体规定了一种 Internet 标准跟踪协议，并请求讨论与改进建议。有关该协议的标准化状态与进展，请参阅"Internet 官方协议标准"（STD 1）的当前版本。本备忘录的分发不受限制。

摘要

STD 11、RFC 822 定义了一种消息表示协议，详细规定了关于 US-ASCII 消息头的大量细节，并将消息内容或消息主体留作扁平的 US-ASCII 文本。这组统称为多用途 Internet 邮件扩展（Multipurpose Internet Mail Extensions，即 MIME）的文档，重新定义了消息的格式，以允许：

除 US-ASCII 之外的字符集中的文本消息主体；
一组可扩展的、用于非文本消息主体的不同格式；
多部分（multi-part）消息主体；
除 US-ASCII 之外的字符集中的文本头信息。

这些文档基于 RFC 934、STD 11 与 RFC 1049 中记录的更早工作，但对其进行了扩展与修订。由于 RFC 822 对消息主体所述甚少，这些文档在很大程度上与 RFC 822 正交（而非其修订）。

本系列文档的第一份 RFC 2045 规定了用于描述 MIME 消息结构的各种头字段。第二份文档定义了 MIME 媒体类型系统的总体结构，并定义了初始的媒体类型集合。第三份文档 RFC 2047 描述了 RFC 822 的扩展，以允许 Internet 邮件头字段中的非 US-ASCII 文本数据。第四份文档 RFC 2048 规定了 MIME 相关设施的各类 IANA 注册流程。这第五份也是最后一份文档描述了 MIME 一致性准则，并提供了一些 MIME 消息格式的说明性示例、致谢以及参考文献。

这些文档是 RFC 1521、1522 与 1590 的修订版，而后者本身又是 RFC 1341 与 1342 的修订版。本文档的附录 B 描述了相对先前版本的差异与变更。

1. 引言

本系列文档中的第一份和第二份文档定义了 MIME 头字段以及最初的 MIME 媒体类型集合。第三份文档描述了 RFC822 格式的扩展，以支持 US-ASCII 之外的字符集。本文档描述了一个符合规范的 MIME 实现必须支持 MIME 的哪些部分。它还描述了当代消息系统的各种缺陷，以及 MIME 所基于的规范编码模型。

2. MIME 一致性

这些文档所描述的机制是开放式的。绝对不期望所有实现都支持所有可用的媒体类型，也不期望它们都共享相同的扩展。然而，为了促进互操作性，定义"MIME 一致性（MIME-conformance）"这一概念是有用的，它定义了一个特定层次的实现，使得内容不同于 US-ASCII 文本的消息能够有用地进行互通。在本节中，我们规定此类一致性的要求。

一个符合 MIME 的用户代理（mail user agent）必须（MUST）：

在它创建的任何消息中都生成 "MIME-Version: 1.0" 头字段。
识别 Content-Transfer-Encoding 头字段，并解码所有以 quoted-printable 或 base64 实现编码的接收数据。7bit、8bit 与 binary 这些恒等变换也必须被识别。
任何未经编码发送的非 7bit 数据，必须恰当地以 8bit 或 binary 的内容传输编码进行标注（视情况而定）。如果底层传输不支持 8bit 或 binary（正如 SMTP [RFC-821] 那样），则发送方需要使用恰当的 Content-Transfer-Encoding（如 quoted-printable 或 base64）对数据进行编码并标注。
必须将任何无法识别的 Content-Transfer-Encoding 视作其 Content-Type 为 "application/octet-stream"，无论实际的 Content-Type 是否被识别。
识别并解释 Content-Type 头字段，并避免向用户显示 Content-Type 字段为非 text 类型的原始数据。实现必须至少能够发送 text/plain 消息，若字符集不是 US-ASCII，则通过 charset 参数指定。
忽略任何其名称不被识别的内容类型参数。
显式地处理以下媒体类型取值，至少达到以下程度：
- 文本（Text）：
  - -- 识别并显示字符集为 "US-ASCII" 的 "text" 邮件。
  - -- 至少识别其他字符集，能够告知用户该消息使用的字符集是什么。
  - -- 识别 "ISO-8859-*" 字符集，至少能够显示那些 ISO-8859-* 与 US-ASCII 共有的字符，即所有由八位组值 1-127 表示的字符。
  - -- 对于已知字符集中无法识别的子类型，在将内容从规范形式转换为本地形式后，向用户显示或提供显示该数据的"原始"版本。
  - -- 将未知字符集中的内容视作 "application/octet-stream" 处理。
- 图像、音频与视频（Image, audio, and video）：
  - -- 至少提供将任何无法识别的子类型视作 "application/octet-stream" 处理的设施。
- 应用（Application）：
  - -- 若使用了本文档定义的 quoted-printable 或 base64 编码，应提供能力将其去除，并将结果信息放入用户文件。
- 多部分（Multipart）：
  - -- 识别 mixed 子类型。显示消息层级与主体部分（body part）头层级的所有相关信息，然后逐个显示或提供显示每个主体部分。
  - -- 识别 "alternative" 子类型，并避免向用户显示 multipart/alternative 邮件中的冗余部分。
  - -- 识别 "multipart/digest" 子类型，具体是使用 "message/rfc822" 而非 "text/plain" 作为 "multipart/digest" 实体内部主体部分的默认媒体类型。
  - -- 将无法识别的子类型视作 "mixed" 处理。
- 报文（Message）：
  - -- 至少识别并显示 RFC822 报文封装（message/rfc822），以保留任何递归结构的方式，即依据其媒体类型显示或提供显示被封装的数据。
  - -- 将无法识别的子类型视作 "application/octet-stream" 处理。
遇到任何无法识别的 Content-Type 字段时，实现必须将其视作媒体类型为 "application/octet-stream" 且无参数子参数来处理。如何处理此类数据由实现决定，但处理此类无法识别数据的常见选项包括：向用户提供将其写入文件（从邮件传输格式解码）的能力，或向用户提供命名一个程序、将解码后的数据作为输入传给它的能力。
一致的用户代理如果被要求对非 MIME 消息（使用了 US-ASCII 之外的字符集）提供非标准支持，则只能在收到的消息上这样做。一致的用户代理不得发送除 US-ASCII 文本之外的任何非 MIME 消息。
特别地，强烈不鼓励在缺少 MIME-Version 字段的邮件消息中使用非 US-ASCII 文本，因为这会在使用不同本地化约定的地区之间发送消息时妨碍互操作性。一致的用户代理在发送 US-ASCII 字符集之外的纯文本以外的任何内容时，必须包含恰当的 MIME 标注。

此外，如果可能，应升级非 MIME 用户代理，使其发送的消息包含恰当的 MIME 头信息，即便不支持 MIME 的其他部分。这一升级对非 MIME 接收方影响甚微（如果有的话），并将有助于 MIME 正确显示此类消息。它也为最终采纳其他 MIME 能力提供了平滑的过渡路径。
一致的用户代理必须确保，在 "*text" 或 "*ctext" 中，任何以 "=?" 开始并以 "?=" 结束的非空白可打印 US-ASCII 字符字符串都是合法的编码字（encoded-word）。（"开始"意指：在字段体的开头或紧跟线性空白之后；"结束"意指：在字段体的末尾或紧邻线性空白之前。）此外，在 "phrase" 内任何以 "=?" 开始并以 "?=" 结束的 "word" 必须是合法的编码字。
一致的用户代理必须能够根据第 4 节的规则，在消息头中适当位置出现的任何时候，区分编码字与 "text"、"ctext" 或 "word"。对于任何它支持的字符集，它必须同时支持 "B" 与 "Q" 编码。如果字符集是 "US-ASCII"，程序必须能够显示未编码的文本。对于 ISO-8859-* 字符集，邮件阅读程序必须至少能够显示那些同样属于 US-ASCII 字符集的字符。

满足上述条件的用户代理称为 MIME 一致的（MIME-conformant）。这一表述的含义是：向此类邮件系统的用户发送几乎任何种类的、经恰当标记的数据都被认为是"安全"的，因为此类系统至少能够将这些数据当作无差别的二进制来处理，而不会将其简单地泼洒到毫无防备的用户屏幕上。

在另一种意义上，以 MIME 一致的格式发送数据也永远是"安全"的，即此类数据不会被任何已知符合 RFC 821 与 RFC 822 的系统破坏，也不会破坏它们。MIME 一致的用户代理还有额外的保证：用户不会被显示那些从未打算作为文本查看的数据。

3. 发送电子邮件数据的准则

互联网电子邮件并非一个完美、同构的系统。邮件在到达最终目的地的途中多个阶段可能会被损坏。具体而言，在整个互联网中发送的电子邮件可能穿越许多网络技术。许多网络与邮件技术并不支持 SMTP 传输环境中可能具备的完整功能。穿越这些系统的邮件很可能会被修改，以便能够被传输。

互联网中存在许多广泛部署的不一致 MTA（邮件传输代理）。这些 MTA 使用 SMTP 协议，在传输过程中改动消息，以利用它们所实现主机的内部结构，或者干脆就是有缺陷的。

以下准则对任何设计一种据称能够在最广泛的网络技术与已知有缺陷的 MTA 中完好无损的数据格式（媒体类型）的人可能有用。请注意，以 base64 编码的任何内容都将满足这些规则，但某些广为人知的机制（尤其是 UNIX uuencode 工具）则不会。另请注意，以 Quoted-Printable 编码的任何内容将完好地穿越大多数网关，但穿越某些通往使用 EBCDIC 字符集的系统的网关时可能不会。

在某些情况下，数据所使用的编码可能作为正常网关或用户代理操作的一部分而改变。特别是，从 base64 到 quoted-printable 以及反之的转换可能是必要的。这可能导致 CRLF 序列与文本主体中的换行相混淆。因此，不能依赖 CRLF 作为除换行之外的其他东西而持续存在。
许多系统可能选择使用本地换行约定来表示和存储文本数据。本地换行约定可能与 RFC822 的 CRLF 约定不一致——已知有系统使用单独的 CR、单独的 LF、CRLF 或计数记录。结果是，孤立的 CR 与 LF 字符在一般意义上不能被很好地容忍；在某些系统上它们可能丢失或被转换为分隔符，因此不能依赖它们。
在 Internet 邮件中传输 NUL（US-ASCII 值 0）是有问题的。（这在很大程度上是因为 NUL 被许多 C 语言标准运行时库例程用作终止字符。）使用 NUL 作为终止字符的做法现在已如此根深蒂固，以至于消息不应依赖它们被保留。
TAB（HT）字符可能被误解，或可能被自动转换为不定数量的空格。在某些环境中这是不可避免的，尤其是在那些不基于 US-ASCII 字符集的环境中。强烈不鼓励（STRONGLY DISCOURAGED）此类转换，但它可能发生，邮件格式不能依赖 TAB（HT）字符的持续存在。
长于 76 字符的行在某些环境中可能被换行或截断。由邮件传输强加的行换行或行截断是强烈不鼓励的，但在某些情况下不可避免。需要长行的应用必须以某种方式区分软换行与硬换行。（一种简单的方法是使用 quoted-printable 编码。）
行尾的"空白"字符（SPACE、TAB（HT））可能被某些传输代理丢弃，而其他传输代理可能用这些字符填充行，使邮件文件中的所有行长度相等。因此，不能依赖行尾空白的持续存在。
许多邮件域使用 US-ASCII 字符集的变体，或使用诸如 EBCDIC 之类的字符集，这些字符集包含大部分但非全部 US-ASCII 字符。对于不在"不变（invariant）"集中的字符，其正确转换不能依赖跨字符转换网关。例如，当跨越 BITNET（一个 EBCDIC 系统）发送 uuencoded 信息时，这种情况就是个问题。即使不跨越网关也可能发生类似问题，因为许多 Internet 主机在内部使用 US-ASCII 之外的字符集。X.400 中可打印字符串（Printable Strings）的定义在某些情况下增加了进一步限制。特别是，已知在所有网关间保持一致的唯一字符是这 73 个字符：对应大写和小写字母 A-Z 与 a-z、10 个数字 0-9，以及以下 11 个特殊字符：
- "'"（US-ASCII 十进制值 39）
- "("（US-ASCII 十进制值 40）
- ")"（US-ASCII 十进制值 41）
- "+"（US-ASCII 十进制值 43）
- ","（US-ASCII 十进制值 44）
- "-"（US-ASCII 十进制值 45）
- "."（US-ASCII 十进制值 46）
- "/"（US-ASCII 十进制值 47）
- ":"（US-ASCII 十进制值 58）
- "="（US-ASCII 十进制值 61）
- "?"（US-ASCII 十进制值 63）
一个最大可移植的邮件表示将把自己限制在相对较短的文本行中，其中唯一有意义的字符取自这 73 个字符的集合。base64 编码遵循这一规则。
某些邮件传输代理会破坏包含特定字面字符串的数据。特别是：
单独成行的句点（"."）已知会被某些（不正确的）SMTP 实现破坏；以五个字符 "From "（第五个字符是空格）开头的行也常被破坏。一个细心的撰写代理可以通过对数据进行编码来防止这些损坏（例如，在行首使用 "=46rom " 代替 "From "，用 "=2E" 代替单独成行的 "."）。

请注意，上述列表并非给 MTA 的推荐实践清单。RFC 821 的 MTA 被禁止改变空白字符的性质或对折行长行。这些不良且无效的实践在已建立的网络上是已知会发生的，实现应当在处理它们可能造成的不良后果时保持健壮。

4. 规范编码模型

在本文档的早期版本中，关于何时将电子邮件数据转换为规范形式并编码的模型存在一些混淆，特别是考虑到换行符的表示因系统而异，这一过程将如何影响对 CRLF 的处理。为此，下面给出编码的规范模型。

组合一个 MIME 实体的过程可以建模为分若干步骤完成。请注意，这些步骤大致类似于 PEM [RFC-1421] 中所用的步骤，并且是针对每个"最内层"主体执行的：

创建本地形式（Creation of local form）。
待传输的主体以系统的原生格式创建。使用原生字符集，并在适当时使用本地行尾约定。该主体可以是一个 UNIX 风格文本文件、一幅 Sun 光栅图像、一个 VMS 索引文件、以系统相关格式仅存于内存中的音频数据，或任何其他对应于某种信息表示的本地模型的东西。从根本上说，数据以对应于媒体类型所指定类型的"原生"形式创建。
转换为规范形式（Conversion to canonical form）。
整个主体，包括"带外（out-of-band）"信息（如记录长度，可能还有文件属性信息），被转换为通用的规范形式。主体具体的媒体类型及其关联属性决定了所使用规范形式的性质。转换为恰当的规范形式可能涉及字符集转换、音频数据变换、压缩，或各种特定于不同媒体类型的其他操作。然而，如果涉及字符集转换，必须注意理解媒体类型的语义，这可能对任何字符集转换有强烈影响，例如对于除 "plain" 之外的文本子类型中具语法意义的字符。

例如，对于 text/plain 数据，文本必须转换为受支持的字符集，并且行必须以符合 RFC 822 的 CRLF 分隔符定界。注意，如果下一步采用 quoted-printable 或 base64 编码，则由 RFC 822 隐含的行长度限制将被取消。
应用传输编码（Apply transfer encoding）。
应用一个适用于该主体的 Content-Transfer-Encoding。注意，媒体类型与传输编码之间不存在固定关系。特别地，基于特定于某主体实例的字符频率计数来选择 base64 或 quoted-printable 可能是恰当的。
插入实体（Insertion into entity）。
编码后的主体被插入到一个带有恰当头字段的 MIME 实体中。然后该实体根据需要被插入到更高层实体（报文或多部分）的主体中。

从实体形式到本地形式的转换通过逆转这些步骤来完成。注意，这些步骤的逆转可能产生不同的结果，因为无法保证原始与最终本地形式相同。

必须注意，这些步骤仅仅是一个模型；它们绝不是构建实际系统的蓝图。特别是，该模型未能考虑两种常见设计：

在许多情况下，编码前转换为规范形式将被编码器本身吸收，编码器直接理解本地格式。例如，文本主体的本地换行约定可能连同该格式是什么的知识一起带入编码器本身。
编码器的输出在作为消息传输之前，可能必须经过一个或多个附加步骤。因此，编码器的输出可能不符合 RFC 822 规定的格式。特别地，再次强调，转换器的输出使用本地换行约定而非标准的 RFC 822 CRLF 分隔符来表达可能是恰当的。

其他实现变体也是可以想见的。本讨论的关键方面在于，尽管存在任何优化、所需步骤的合并或附加处理的插入，所产生的消息必须与本文所描述的模型所产生的消息一致。例如，带有以下头字段的消息：

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

必须先表示为 text/foo 形式，然后（如有必要）表示为 "bar" 字符集，最后通过 base64 算法转换为邮件安全形式。

注意（NOTE）：一些系统以使用与 RFC822 CRLF 约定不同的本地换行约定的格式表示消息，这造成了某些混淆。重要的是要注意，这些格式并非规范的 RFC822/MIME。这些格式实际上是 RFC822 的编码，其中消息规范表示中的 CRLF 序列被编码为本地换行约定。注意，将 CRLF 序列编码为（例如）LF 的格式，无法表示包含不属于 CRLF 行分隔序列的 LF 八位组的、含二进制数据的 MIME 消息。

5. 小结

本文档定义了 MIME 一致性的含义。它还详述了 Internet 电子邮件系统中已知的各类问题，以及如何使用 MIME 克服它们。最后，它描述了 MIME 的规范编码模型。

6. 安全考量

安全问题在本系列文档的第二份文档 RFC 2046 中讨论。

7. 作者地址

如需更多信息，最好通过 Internet 邮件联系本文档的作者：

Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA

电话：+1 818 919 3600
传真：+1 818 919 3614
电子邮箱：ned@innosoft.com

Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA

电话：+1 201 540 8967
传真：+1 201 993 3032
电子邮箱：nsb@nsb.fv.com

MIME 是 Internet 工程任务组（IETF）RFC 822 扩展工作组工作的成果。该组主席 Greg Vaudreuil 可通过以下方式联系：

Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA

电子邮箱：Greg.Vaudreuil@Octel.Com

8. 致谢

本文档是大量人员在数届 IETF 会议、IETF-SMTP 与 IETF-822 邮件列表以及其他场合集体努力的结果。尽管任何列举似乎都注定会有严重的遗漏，以下仍是众多贡献者中的一部分：

Harald Tveit Alvestrand、Marc Andreessen、Randall Atkinson、Bob Braden、Philippe Brandon、Brian Capouch、Kevin Carosso、Uhhyung Choi、Peter Clitherow、Dave Collier-Brown、Cristian Constantinof、John Coonrod、Mark Crispin、Dave Crocker、Stephen Crocker、Terry Crowley、Walt Daniels、Jim Davis、Frank Dawson、Axel Deininger、Hitoshi Doi、Kevin Donnelly、Steve Dorner、Keith Edwards、Chris Eich、Dana S. Emery、Johnny Eriksson、Craig Everhart、Patrik Faltstrom、Erik E. Fair、Roger Fajman、Alain Fontaine、Martin Forssen、James M. Galvin、Stephen Gildea、Philip Gladstone、Thomas Gordon、Keld Simonsen、Terry Gray、Phill Gross、James Hamilton、David Herron、Mark Horton、Bruce Howard、Bill Janssen、Olle Jarnefors、Risto Kankkunen、Phil Karn、Alan Katz、Tim Kehres、Neil Katin、Steve Kille、Kyuho Kim、Anders Klemets、John Klensin、Valdis Kletniek、Jim Knowles、Stev Knowles、Bob Kummerfeld、Pekka Kytolaakso、Stellan Lagerstrom、Vincent Lau、Timo Lehtinen、Donald Lindsay、Warner Losh、Carlyn Lowery、Laurence Lundblade、Charles Lynn、John R. MacMillan、Larry Masinter、Rick McGowan、Michael J. McInerny、Leo Mclaughlin、Goli Montaser-Kohsari、Tom Moore、John Gardiner Myers、Erik Naggum、Mark Needleman、Chris Newman、John Noerenberg、Mats Ohrman、Julian Onions、Michael Patton、David J. Pepper、Erik van der Poel、Blake C. Ramsdell、Christer Romson、Luc Rooijakkers、Marshall T. Rose、Jonathan Rosenberg、Guido van Rossum、Jan Rynning、Harri Salminen、Michael Sanderson、Yutaka Sato、Markku Savela、Richard Alan Schafer、Masahiro Sekiguchi、Mark Sherman、Bob Smart、Peter Speck、Henry Spencer、Einar Stefferud、Michael Stein、Klaus Steinberger、Peter Svanberg、James Thompson、Steve Uhler、Stuart Vance、Peter Vanderbilt、Greg Vaudreuil、Ed Vielmetti、Larry W. Virden、Ryan Waldron、Rhys Weatherly、Jay Weber、Dave Wecker、Wally Wedel、Sven-Ove Westberg、Brian Wideen、John Wobus、Glenn Wright、Rayan Zachariassen、David Zimmerman。

作者为名单中的任何遗漏表示歉意，那肯定是无意的。

附录 A. 一个复杂的多部分示例

下面是一个复杂多部分消息的概要。该消息包含五个要串行显示的部分：两段介绍性纯文本对象、一个内嵌的多部分消息、一个 text/enriched 对象，以及一个以非 ASCII 字符集封装的收尾文本消息。内嵌的多部分消息本身包含两个要并行显示的对象：一幅图片与一段音频片段。

     MIME-Version: 1.0
     From: Nathaniel Borenstein <nsb@nsb.fv.com>
     To: Ned Freed <ned@innosoft.com>
     Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
     Subject: A multipart example
     Content-Type: multipart/mixed;
                   boundary=unique-boundary-1

     This is the preamble area of a multipart message.
     Mail readers that understand multipart format
     should ignore this preamble.

     If you are reading this text, you might want to
     consider changing to a mail reader that understands
     how to properly display multipart messages.

     --unique-boundary-1

       ... Some text appears here ...

     [Note that the blank between the boundary and the start
      of the text in this part means no header fields were
      given and this is text in the US-ASCII character set.
      It could have been done with explicit typing as in the
      next part.]

     --unique-boundary-1
     Content-type: text/plain; charset=US-ASCII

     This could have been part of the previous part, but
     illustrates explicit versus implicit typing of body
     parts.

     --unique-boundary-1
     Content-Type: multipart/parallel; boundary=unique-boundary-2

     --unique-boundary-2
     Content-Type: audio/basic

     Content-Transfer-Encoding: base64

       ... base64-encoded 8000 Hz single-channel
           mu-law-format audio data goes here ...

     --unique-boundary-2
     Content-Type: image/jpeg
     Content-Transfer-Encoding: base64

       ... base64-encoded image data goes here ...

     --unique-boundary-2--

     --unique-boundary-1
     Content-type: text/enriched

     This is <bold><italic>enriched.</italic></bold>
     <smaller>as defined in RFC 1896</smaller>

     Isn't it
     <bigger><bigger>cool?</bigger></bigger>

     --unique-boundary-1
     Content-Type: message/rfc822

     From: (mailbox in US-ASCII)
     To: (address in US-ASCII)
     Subject: (subject in US-ASCII)
     Content-Type: Text/plain; charset=ISO-8859-1
     Content-Transfer-Encoding: Quoted-printable

       ... Additional text in ISO-8859-1 goes here ...

     --unique-boundary-1--

附录 B. 相对 RFC 1521、1522 与 1590 的变更

这些文档是 RFC 1521、1522 与 1590 的修订版。为便于熟悉早期文档的读者，本附录总结了相对那些文档的变更。更多历史背景，注意 RFC 1521 的附录 H 说明了该文档与其前身 RFC 1341 的差异。

本文档已被完全重新排版并拆分为多个文档。这样做是为了改善本文档纯文本版本的质量，而该纯文本版本被要求作为参考副本。
已增加描述 MIME 对象头整体结构的 BNF。这仅是文档性变更——底层语法未以任何方式改变。
已移除 MIME 中七种媒体类型的具体 BNF。该 BNF 不正确、不完整，且与类型无关的 BNF 不一致。既然类型无关的 BNF 已经完整规定了各种 MIME 头的语法，类型相关的 BNF 说到底完全没必要，且引起的问题多于它解决的。
更具体的 "US-ASCII" 字符集名称已取代这些文档许多部分中非正式的 ASCII 术语。
已移除非正式的"主子类型（primary subtype）"概念。
"对象（object）"一词的使用曾前后不一致。该术语的定义已澄清，同时澄清了相关术语 "body"、"body part" 与 "entity"，并在适当处修正了用法。
多部分媒体类型的 BNF 已重新安排，以明确边界标记（boundary marker）之前的 CRLF 实际上是标记本身的一部分，而非前一个主体部分的一部分。
描述多部分媒体类型的正文与 BNF 已修改，以明确多部分对象内部的主体部分不得包含任何以边界参数字符串开头的行。
在重新组装 "message/partial" MIME 实体的规则中，"Subject" 被加入到要从内部消息提取的头列表，并且示例被修改以澄清这一点。
"Message/partial" 的分片器被限制只能在行边界处拆分 MIME 对象。
在关于 application/postscript 类型的讨论中，增加了一段警告，提示在 PostScript MIME 实体内嵌入二进制数据可能引起的互操作性问题。

为 Content-Type 头字段的基本语法规则增加了一条澄清性说明，以明确以下两种形式：

            Content-type: text/plain; charset=us-ascii (comment)

            Content-type: text/plain; charset="us-ascii"

是完全等价的。

已从 MIME-Version 头的讨论中移除这句话："然而，鼓励一致软件检查版本号，并在遇到无法识别的 MIME 版本时至少警告用户。"
修正了一个将 "application/external-body" 误写为 "message/external-body" 的拼写错误。
字符集的定义已重新组织，以使要求更清晰。
"image/gif" 媒体类型的定义已移至独立文档。做出此变更是因为可能与 IETF 管辖专利技术标准化工作的规则相冲突。
"7bit" 与 "8bit" 的定义已收紧，使得裸 CR、LF 只能用作行尾序列。文档也不再要求保留 NUL 字符，这使 MIME 与实际实现相一致。
MIME 中规范文本的定义已收紧，使得换行必须用 CRLF 序列表示。CR 与 LF 字符不允许在此用途之外出现。quoted-printable 编码的定义已相应更改。
quoted-printable 编码的定义现在包含了若干建议，说明 quoted-printable 编码器如何最好地处理编码不当的材料。
增加了正文，以澄清在封装了 "8bit" 或 "binary" 数据的 multipart 或 message 实体上使用 "7bit"、"8bit" 与 "binary" 传输编码的问题。
在 MIME 一致性一节中，将 "multipart/digest" 支持加入最小 MIME 一致性要求列表。同时，加强了对 "message/rfc822" 支持的要求，以澄清识别递归结构的重要性。
对 "message" 各子类型的各种限制现在完全按子类型逐个规定。
"message/rfc822" 的定义已更改，指明 "From"、"Subject" 或 "Date" 头中至少有一个必须存在。
将未识别子类型作为 "application/octet-stream" 处理的必要处理，在类型定义小节与一致性指南中都已更加明确。
使用 text/richtext 的示例已改为 text/enriched。
子类型的 BNF 定义已更改，以明确 Content-Type 头字段中必须使用一个 IANA 注册的子类型或一个非标准的 "X-" 子类型。
仅为使用而注册、与由 IETF 标准化的 MIME 媒体类型，现在在 MIME BNF 中加以区分。
各类 MIME 注册流程已广泛修订。字符集的 IANA 注册流程已移至本系列文档之外的一份独立文档。
这些文档定义的 US-ASCII 与 ISO-8859-X 字符集中转义与移位（escape and shift）机制的使用已澄清：此类机制绝不应与这些字符集一起使用，若使用则其效果未定义。
已移除 message/external-body 的 AFS access-type 定义。
multipart/alternative 与 message/external-body 组合的处理现在被专门说明。
特定于 message/external-body 的安全问题现在有一定程度的详细讨论。

附录 C. 参考文献

下列参考文献在本文档中被引用：

[ATK] Borenstein, Nathaniel S., 《Multimedia Applications Development with the Andrew Toolkit》, Prentice-Hall, 1990.

[ISO-2022] 国际标准——信息处理——字符代码结构与时扩展技术，ISO/IEC 2022:1994，第 4 版。

[ISO-8859] 国际标准——信息处理——8 位单字节编码图形字符集：第 1 部分：拉丁字母表 No.1（ISO 8859-1:1987，第 1 版）；第 2 部分：拉丁字母表 No.2（ISO 8859-2:1987，第 1 版）；第 3 部分：拉丁字母表 No.3（ISO 8859-3:1988，第 1 版）；第 4 部分：拉丁字母表 No.4（ISO 8859-4:1988，第 1 版）；第 5 部分：拉丁/西里尔字母表（ISO 8859-5:1988，第 1 版）；第 6 部分：拉丁/阿拉伯字母表（ISO 8859-6:1987，第 1 版）；第 7 部分：拉丁/希腊字母表（ISO 8859-7:1987，第 1 版）；第 8 部分：拉丁/希伯来字母表（ISO 8859-8:1988，第 1 版）；第 9 部分：拉丁字母表 No.5（ISO/IEC 8859-9:1989，第 1 版）；第 10 部分：拉丁字母表 No.6（ISO/IEC 8859-10:1992，第 1 版）。

[ISO-646] 国际标准——信息技术——ISO 7 位编码字符集用于信息交换，ISO 646:1991，第 3 版。

[JPEG] JPEG 标准草案 ISO 10918-1 CD。

[MPEG] 视频编码标准草案 ISO 11172 CD，ISO IEC/JTC1/SC2/WG11（运动图像专家组），1991 年 5 月。

[PCM] CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies", Geneva, 1972.

[POSTSCRIPT] Adobe Systems, Inc., 《PostScript Language Reference Manual》, Addison-Wesley, 1985.

[POSTSCRIPT2] Adobe Systems, Inc., 《PostScript Language Reference Manual》, Addison-Wesley, 第 2 版, 1990.

[RFC-783] Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, 1981 年 6 月。

[RFC-821] Postel, J.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/信息科学研究所, 1982 年 8 月。

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, 1982 年 8 月。

[RFC-934] Rose, M. 与 E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware 与 NMA, 1985 年 1 月。

[RFC-959] Postel, J. 与 J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/信息科学研究所, 1985 年 10 月。

[RFC-1049] Sirbu, M., "Content-Type Header Field for Internet Messages", RFC 1049, CMU, 1988 年 3 月。

[RFC-1154] Robinson, D. 与 R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1154, Prime Computer, Inc., 1990 年 4 月。

[RFC-1341] Borenstein, N. 与 N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, 1992 年 6 月。

[RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of Tennessee, 1992 年 6 月。

[RFC-1344] Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, 1992 年 6 月。

[RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345, Rationel Almen Planlaegning, 1992 年 6 月。

[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, 1993 年 2 月。

[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1422, IAB IRTF PSRG, IETF PEM WG, 1993 年 2 月。

[RFC-1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", IAB IRTF PSRG, IETF PEM WG, 1993 年 2 月。

[RFC-1424] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV -- Key Certification and Related Services", IAB IRTF PSRG, IETF PEM WG, 1993 年 2 月。

[RFC-1521] Borenstein, N. 与 Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 1993 年 9 月。

[RFC-1522] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, 1993 年 9 月。

[RFC-1524] Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC 1524, Bellcore, 1993 年 9 月。

[RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, USC/信息科学研究所, 1993 年 10 月。

[RFC-1556] Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC 1556, Israeli Inter-University Computer Center, 1993 年 12 月。

[RFC-1590] Postel, J., "Media Type Registration Procedure", RFC 1590, USC/信息科学研究所, 1994 年 3 月。

[RFC-1602] Internet Architecture Board, Internet Engineering Steering Group, Huitema, C., Gross, P., "The Internet Standards Process -- Revision 2", 1994 年 3 月。

[RFC-1652] Klensin, J.（WG Chair）、Freed, N.（Editor）、Rose, M.、Stefferud, E. 与 Crocker, D., "SMTP Service Extension for 8bit-MIME transport", RFC 1652, United Nations University, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, 1994 年 3 月。

[RFC-1700] Reynolds, J. 与 J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/信息科学研究所, 1994 年 10 月。

[RFC-1741] Faltstrom, P., Crocker, D., 与 Fair, E., "MIME Content Type for BinHex Encoded Files", 1994 年 12 月。

[RFC-1896] Resnick, P. 与 A. Walker, "The text/enriched MIME Content-type", RFC 1896, 1996 年 2 月。

[RFC-2045] Freed, N. 与 N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual Holdings, 1996 年 11 月。

[RFC-2046] Freed, N. 与 N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual Holdings, 1996 年 11 月。

[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, University of Tennessee, 1996 年 11 月。

[RFC-2048] Freed, N.、Klensin, J. 与 J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, Innosoft, MCI, ISI, 1996 年 11 月。

[RFC-2049] Freed, N. 与 N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049（本文档）, Innosoft, First Virtual Holdings, 1996 年 11 月。

[US-ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[X400] Schicker, Pietro, "Message Handling Systems, X.400", 《Message Handling Systems and Distributed Applications》, E. Stefferud, O-j. Jacobsen 与 P. Schicker 编, North-Holland, 1989, 第 3-41 页。