网络工作组N.Freed征求意见：2049 Innosoft过时：1521,1522,1590N.伯恩斯坦类别：标准跟踪第一虚拟1996年11月多用途Internet邮件扩展
                           （MIME）第五部分：
                   一致性标准和示例此备忘录的状态本文档为互联网社区，并请求讨论和建议改进。请参阅“互联网”的最新版本标准化状态的官方协议标准”（STD 1）以及此协议的状态。此备忘录的分发不受限制。摘要标准11，副本请求822，定义消息表示协议，指定有关US-ASCII消息头的大量详细信息，并留下消息内容或消息正文，作为平面US-ASCII文本。这套文件，统称为多用途互联网邮件扩展，或MIME，重新定义消息格式以允许（1） 字符集以外的文本消息正文美国-亚洲科学院，（2） 一组可扩展的非文本格式消息正文，（3） 多部分消息正文，以及（4） 字符集中的文本标题信息美国-阿拉伯联合酋长国。这些文件基于副本请求934，标准11，和射频1049，但对其进行了扩展和修订。因为副本请求822说消息体太少了，这些文档主要是与（而非修订）正交副本请求822.此集合中的初始文档，RFC 2045号文件，指定各种用于描述MIME消息结构的标头。第二个文档定义了MIME媒体类型的一般结构系统并定义一组初始媒体类型。第三个文档，副本请求2047，描述了对的扩展副本请求822允许非美国-Freed&Borenstein标准课程[第1页]

RFC 2049MIME一致性1996年11月Internet邮件标题字段中的ASCII文本数据。第四份文件，RFC 2048号文件，规定了MIME的各种IANA注册程序-相关设施。第五个也是最后一个文档描述了MIME一致性标准，并提供一些示例MIME消息格式、确认和参考书目。这些文件是RFC 1521、1522和1590的修订版它们本身是RFC 1341和1342的修订版。附录B这个的文档描述了与以前版本的差异和更改。目录1.简介。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。2
   2MIME一致性。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。2
   三.电子邮件数据发送指南。。。。。。。。。。。。。。。。。。。。。6
   4.标准编码模型。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。9
   5总结。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。12
   6.安全注意事项。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。12
   7.作者地址。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。12
   8.确认。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。13
   A类.A复杂的多部分示例。。。。。。。。。。。。。。。。。。。。。。。。。。。15
   B类。更改自RFC 1521号文件、1522和1590。。。。。。。。。。。。。。。。。16
   C类参考文献。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。20

1.简介此集合中的第一个和第二个文档定义MIME头字段和初始MIME媒体类型集。第三份文件描述了对的扩展RFC822协议允许字符集的格式除US-ASCII外。本文档描述了MIME的哪些部分必须由一致的MIME实现支持。它还可以还描述了当代消息传递系统的各种缺陷MIME基于的规范化编码模型。2.MIME一致性这些文件中描述的机制是开放的。它是当然不希望所有实现都支持所有可用的媒体类型，也不是所有媒体都共享相同的扩展名。然而，为了促进互操作性有助于定义“MIME-conformance”的概念，以定义一定程度的实现，允许有用的互通内容与US-ASCII文本不同的邮件。在这个第节，我们指定了这种一致性的要求。Freed&Borenstein标准课程[第2页]

RFC 2049MIME一致性1996年11月符合MIME的邮件用户代理必须：（1） 始终在中生成“MIME-Version:1.0”标题字段它创建的任何消息。（2） 识别Content-Transfer-Encoding头字段并对所有接收到的数据进行解码-可打印或base64实现。身份转换7bit、8bit和binary也必须是辨识。任何未经编码发送的非7位数据必须用内容传输编码正确标记8位或二进制，视情况而定。如果基础传输不支持8位或二进制（作为SMTP[RFC-821号文件]不需要），发送方必须同时使用适当的内容对数据进行编码和标记-传输编码，例如quoted-printable或base64。（3） 必须处理任何未识别的内容传输编码就好像它的Content-Type是“application/octet-流”，无论实际识别内容类型。（4） 识别并解释Content-Type标题字段，并避免使用Content-Type向用户显示原始数据文本以外的字段。实现必须能够使用使用charset参数指定的字符集，如果它不是US-ASCII。（5） 忽略名称相同的任何内容类型参数无法识别。（6） 显式处理以下媒体类型值，以至少以下范围：文本：--识别并显示“文本”邮件字符集“US-ASCII”--识别其他字符集能够告知用户什么消息使用的字符集。Freed&Borenstein标准轨道[第3页]

RFC 2049MIME一致性1996年11月--将“ISO-8859-*”字符集识别为能够显示以下字符的范围ISO-8859-*和US-ASCII通用，即由八位字节值1-127表示的字符。--对于已知字符中无法识别的子类型设置、显示或提供向用户显示“原始”版本的内容转换后的数据从规范形式到局部形式。--将未知字符集中的材质视为它是“application/octet-stream”。图像、音频和视频：--至少提供设施来处理任何无法识别的子类型“应用程序/octet-stream”。应用程序：--提供删除引用内容的能力-在此中定义的可打印或base64编码记录它们是否被使用，并将结果用户文件中的信息。多部分：--识别混合子类型。显示所有相关消息级别和正文部分的信息标题级别，然后显示或提供显示每个身体部位都是单独的。--识别“替代”子类型，并避免显示的用户冗余部分多部分/备选邮件。--识别“多部分/摘要”子类型，具体使用“message/rfc822”而不是“text/plain”作为车身部位的默认媒体类型在“多部分/摘要”实体中。--将任何未识别的子类型视为“混合”。Freed&Borenstein标准课程[第4页]

RFC 2049MIME一致性1996年11月消息：--识别并至少显示RFC822协议消息封装（消息/rfc822），以便保留任何递归结构，即显示或提供在中显示封装数据根据其媒体类型。--将任何未识别的子类型视为“应用程序/octet-stream”。（7） 在遇到任何未识别的内容类型字段时，实现必须将其视为具有媒体无参数的“application/octet-stream”类型子参数。如何处理这些数据取决于实现，但可能的处理选项无法识别的数据包括提供给用户写入数据转换为文件（从邮件传输格式解码）或为用户命名一个程序解码数据应作为输入传递。（8） 如果一致性用户代理提供非MIME消息的非标准支持除US-ASCII以外的字符集仅接收到消息。合格的用户代理不得发送包含以下内容的非MIME邮件US-ASCII文本。特别是，在邮件中使用非US-ASCII文本没有MIME-Version字段的消息不鼓励发送时妨碍互操作性不同本地化区域之间的消息习俗。合格用户代理必须包括适当的发送纯文本以外的任何内容时使用MIME标记US-ASCII字符集中的文本。此外，如果满足以下条件，则应升级非MIME用户代理尽可能包括适当的MIME头他们发送的消息中的信息，即使什么都没有支持MIME中的else。此升级将具有对非MIME收件人几乎没有影响帮助MIME正确显示此类消息。它也为最终采用其他MIME功能。（9） 合格的用户代理必须确保中的非空白可打印US-ASCII字符以“=？”开头、以“=”结尾的“*text”或“*ctext”Freed&Borenstein标准课程[第5页]

射频2049MIME一致性1996年11月“？=”是有效的编码字。（“开始”是指：现场主体开始或紧随其后线性-白色空间；“结束”是指：在场-体或紧邻线-白-空格。）此外，“短语”中的任何“单词”以“=？”开头，以“？=”结尾必须是有效的编码字。（10） 合格的用户代理必须能够区分来自“text”、“ctext”或“word”s的编码单词，根据中的规则第4节，随时可以出现在邮件标题中的适当位置。它必须支持任何它支持的字符集。程序必须是如果字符集是“US-ASCII”。对于ISO-8859-*字符集邮件阅读程序必须至少能够显示也在US-ASCII集合中的字符。满足上述条件的用户代理称为MIME-一致。这个短语的意思是假定“安全”，可以向这样的邮件系统，因为这样的系统至少能够将数据视为未区分的二进制，并且不会简单地溢出它出现在毫无戒心的用户的屏幕上。还有一种感觉，在符合MIME的格式，即此类数据不会破坏或被符合以下条件的任何已知系统破坏无线电频率控制
   821和副本请求822。符合MIME的用户代理具有额外保证不会向用户显示从未打算被视为文本。三.电子邮件数据发送指南互联网电子邮件并不是一个完美的同质系统。邮件可能成为在到达最终目的地的过程中的几个阶段被破坏。具体来说，通过互联网发送的电子邮件可能会在许多网络技术。许多网络和邮件技术不支持SMTP传输中的全部功能环境。穿过这些系统的邮件可能会被修改以便运输。互联网上存在许多广泛部署的非共振MTA。这些MTA使用SMTP协议，将动态邮件更改为利用主机的内部数据结构在上实现，或者只是简单地中断。Freed&Borenstein标准课程[第6页]

RFC 2049MIME一致性1996年11月以下指南可能对任何设计数据的人有用格式（媒体类型）应在最广泛的网络技术和已知损坏的MTA毫发无损。请注意在base64编码中编码的任何内容都将满足这些规则，但是一些众所周知的机制，特别是UNIX uuencode工具，不会。还要注意，Quoted-Printable中编码的任何内容编码可以完好无损地保存大多数网关，但也可能无法保存一些使用EBCDIC字符集的系统的网关。（1） 在某些情况下，用于数据的编码可能作为普通网关或用户代理的一部分进行更改操作。特别是，从base64到报价-可供选择，反之亦然。这个可能会导致CRLF序列与行混淆文本正文中的分隔符。因此CRLF不能作为换行符以外的其他内容依赖。（2） 许多系统可以选择表示和存储文本数据使用本地换行约定。本地换行约定可能与RFC822协议CRLF约定--已知使用普通CR、普通LF、CRLF或计数记录。结果是分离的CR和LF一般来说，对角色的容忍度不高；他们可能会在某些系统上丢失或转换为分隔符，以及因此，不能依赖。（3） NUL（US-ASCII值0）的传输为Internet邮件中存在问题。（这主要是NUL被用作终止字符的结果C语言中的许多标准运行时库例程编程语言。）使用NUL作为终止字符如此根深蒂固，以至于消息不应该依赖于它们被保存。（4） TAB（HT）字符可能被误解或自动转换为可变数量的空格。这在某些环境中是不可避免的，尤其是那些不基于US-ASCII字符集。这样的转换被强烈拒绝，但可能发生，邮件格式不得依赖TAB（HT）字符。（5） 长度超过76个字符的行可以换行或在某些环境中被截断。换行或换行邮件传输强加的截断失望，但在某些情况下不可避免。需要长线的应用程序必须以某种方式Freed&Borenstein标准课程[第7页]

RFC 2049MIME一致性1996年11月区分软换行和硬换行。（A）简单的方法是使用quoted-printable编码。）（6） 尾随“空白”字符（空格、制表符（HT））某些运输代理可能会丢弃线路，而其他运输代理可能会用这些填充线字符，以便邮件文件中的所有行长度相等。尾部空白的持续性，因此，不能依赖。（7） 许多邮件域使用US-ASCII上的变体字符集，或使用EBCDIC等字符集其中包含大多数但不是全部的US-ASCII字符。字符的正确翻译不是在“不变”集合中不能相互依赖字符转换网关。例如，这个发送uuencoded时出现问题BITNET（EBCDIC系统）上的信息。类似问题可能在不跨越网关的情况下发生，因为许多互联网主机使用美国以外的字符集-ASCII内部。可打印字符串的定义在X.400中，在某些特殊案例。特别是，只有众所周知，73个网关在所有网关上都是一致的与大小写相对应的字符字母A-Z和A-Z，10位数字0-9，以及以下十一个特殊字符：“'”（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编码遵循此规则。（8） 一些邮件传输代理会破坏数据包括某些文字字符串。特别是Freed&Borenstein标准课程[第8页]

RFC 2049MIME一致性1996年11月已知单行上的句点（“.”）已损坏通过一些（错误的）SMTP实现和一行以五个字符“From”（第五个字符是空格）通常也会损坏。仔细的合成剂可以防止这些通过编码数据（例如，在引用的-使用“=46rom”代替“From”进行可打印编码在一行的开头，用“=2E”代替“.”在线上）。请注意，以上列表不是推荐列表MTA的实践。射频c 821MTA禁止更改空白或包装长线的特性。这些BAD和已知在已建立的网络上会发生无效做法，以及实现在处理它们的不良影响时应该是健壮的可能导致。4.标准编码模型在这些文件的早期版本中，存在一些混淆，关于电子邮件数据何时转换为的模型规范形式和编码，特别是这个过程将如何影响CRLF的治疗，因为新行因系统而异。因此编码的规范模型如下所示。编写MIME实体的过程可以建模为正在完成在许多步骤中。请注意，这些步骤大致类似于PEM中使用的步骤[RFC-1421号文件]并针对每个“最内层”主体：（1） 创建本地表单。要传输的主体是在系统的本机格式。使用本机字符集，在适当的情况下，本地行尾约定是也使用了。正文可以是UNIX样式的文本文件，或Sun光栅图像、VMS索引文件或音频系统相关格式的数据仅存储在内存或与本地表示某种形式的信息。基本上，数据是在与指定的类型相对应的“本机”形式媒体类型。Freed&Borenstein标准课程[第9页]

RFC 2049MIME一致性1996年11月（2） 转换为规范形式。整个机构，包括“银行外”信息例如记录长度和可能的文件属性信息转换为通用规范形式。主体的特定媒体类型以及其相关属性决定了使用的规范形式。转换为适当的规范形式可能涉及字符集转换，转换音频数据、压缩或各种特定于各种媒体类型的其他操作。但是，如果涉及字符集转换，请注意必须理解媒体的语义类型，这可能对任何字符集转换，例如关于文本子类型中有语法意义的字符而不是“普通”。例如，对于文本/纯数据，文本必须转换为支持的字符集，并且行必须用CRLF分隔符分隔符合副本请求822注意由副本请求822如果下一步使用quoted-printable或base64编码。（3） 应用传输编码。适合本机构的内容传输编码已应用。请注意，没有固定的关系在媒体类型和传输编码之间。在特别是，可能适合选择base64或quoted-printable基于字符频率特定于给定实例的计数车身。（4） 插入实体。编码的正文插入到MIME实体中适当的标题。然后将实体插入高级实体的主体（消息或多部分）。通过以下方式完成从实体形式到本地形式的转换颠倒这些步骤。请注意，反转这些步骤可能会产生由于无法保证原始和最终的局部形式是相同的。Freed&Borenstein标准课程[第10页]

RFC 2049MIME一致性1996年11月需要注意的是，这些步骤只是一个模型；他们是具体来说，不是一个如何构建实际系统的蓝图。特别是，该模型没有考虑到两种常见的设计：（1） 在许多情况下，转换为规范形式之前编码将归入编码器本身，它直接理解本地格式。例如，文本正文的本地换行约定可能是与一起传递到编码器本身了解该格式是什么。（2） 编码器的输出可能必须通过一个或在传输为一条消息。因此，编码器的输出可能不会符合副本请求822.特别是，它可能再次适用于使用局部换行表示转换器的输出约定而不是使用标准副本请求822CRLF公司分隔符。其他实现变化也是可以想象的。至关重要的讨论的方面是，尽管进行了任何优化，所需步骤的折叠或附加处理的插入，生成的消息必须与此处描述的模型。例如，包含以下内容的消息标题字段：内容类型：text/foo；charset=巴内容传输编码：base64必须首先以text/foo形式表示，然后（如有必要）在“bar”字符集中表示，最后通过将base64算法转换为邮件安全形式。注意：一些混淆是由以下系统引起的：消息的格式使用本地换行约定不同于RFC822协议CRLF约定。值得注意的是这些格式不是规范的RFC822协议/MIME公司。这些格式是而不是的“编码”RFC822协议，其中规范中的CRLF序列消息的表示被编码为本地换行符惯例。注意，将CRLF序列编码为的格式例如，LF不能表示包含以下内容的MIME消息包含不属于CRLF行分隔的LF八位字节的二进制数据序列。Freed&Borenstein标准课程[第11页]

RFC 2049MIME一致性1996年11月


5.总结本文件定义了MIME一致性的含义。它还可以详细说明了互联网电子邮件系统中已知存在的各种问题以及如何使用MIME来克服它们。最后，它描述了MIME的规范编码模型。6.安全注意事项安全问题将在本集的第二个文档中讨论，无线电频率控制
   2046.7.作者地址如需了解更多信息，请与本文档的作者联系通过互联网邮件：内德·费利德Innosoft国际公司。东加维大道南1050号加利福尼亚州西科维纳，邮编：91790美国电话：+1 818 919 3600传真：+1 818 919 3614电子邮件：ned@innosoft.com纳撒尼尔·S·伯恩斯坦第一家虚拟控股公司华盛顿大道25号新泽西州莫里斯敦07960美国电话：+1 201 540 8967传真：+1 201 993 3032电子邮件：nsb@nsb.fv.comMIME是互联网工程特别工作组工作的成果工作组副本请求822延期。该集团的主席，Greg Vaudreuil，联系方式：格雷戈里·沃德鲁伊Octel网络服务达拉斯大道17080号德克萨斯州达拉斯75248-1905美国电子邮件：格雷格·瓦德鲁伊@Octel.ComFreed&Borenstein标准课程[第12页]

RFC 2049MIME一致性1996年11月


8.致谢本文件是在几次IETF会议上，IETF-SMTP和IETF-822邮件列表等。尽管有任何枚举似乎注定要遭受令人震惊的疏漏，以下是在这项工作的众多贡献者中：哈拉尔德·特维特·阿尔维斯特兰德·马克·安德烈森兰德尔·阿特金森鲍勃·布莱登菲利普·布兰登·布赖恩·卡普奇凯文·卡罗索·乌洪·崔彼得·克利瑟罗（Peter Clitherow）戴夫·科利尔·布朗（Dave Collier-Brown）约翰·库恩罗德的克里斯蒂安·康斯坦丁马克·克里斯平·戴夫·克罗克斯蒂芬·克罗克-特里·克劳利沃尔特·丹尼尔斯·吉姆·戴维斯弗兰克·道森·阿克塞尔·戴宁格（Frank Dawson Axel Deininger）Hitoshi Doi Kevin Donnelly先生史蒂夫·多纳·基思·爱德华兹克里斯·艾奇·达纳·S·埃默里约翰尼·埃里克逊·克雷格·埃弗哈特Patrik Faltstrom Erik E.博览会罗杰·法杰曼·阿兰·丰丹马丁·福森·詹姆斯·加尔文斯蒂芬·吉尔迪亚·菲利普·格莱斯顿托马斯·戈登·凯尔德·西蒙森特里·格雷·菲尔·格罗斯詹姆斯·汉密尔顿·大卫·赫伦马克·霍顿·布鲁斯·霍华德比尔·扬森·奥尔勒·贾尼福斯里斯托·坎昆内·菲尔·卡恩阿兰·卡兹·蒂姆·凯利斯尼尔·凯丁·史蒂夫·基尔Kyuho Kim Anders Klemets公司约翰·克伦森·瓦尔迪斯·克列特涅克（John Klensin Valdis Kletniek）吉姆·诺尔斯Stev Knowles鲍勃·库默费尔德·佩卡·基托拉克索斯特兰·拉格斯特罗姆·文森特·刘Timo Lehtinen唐纳德·林赛华纳失去卡琳·洛维劳伦斯·伦德布拉德·查尔斯·林恩约翰·麦克米兰·拉里·马斯特里克·麦高文（Rick McGowan）、迈克尔·麦金纳尼（Michael J.McInerny）利奥·麦克劳克林·戈利·蒙塔泽·科萨里汤姆·摩尔约翰·加德纳·迈尔斯埃里克·纳古姆·马克·尼德曼克里斯·纽曼约翰·诺伦伯格Freed&Borenstein标准课程[第13页]

RFC 2049MIME一致性1996年11月Mats Ohrman Julian洋葱迈克尔·巴顿·大卫·J·佩珀埃里克·范德波尔·布莱克·C·拉姆斯代尔Christer Romson Luc Rooijakkers先生马歇尔·罗斯·乔纳森·罗森博格吉多·范·罗苏姆·扬·瑞宁哈里·萨利宁·迈克尔·桑德森佐藤·马克库·萨维拉（Yutaka Sato Markku Savela）理查德·阿伦·谢费尔·马沙希罗·塞基古奇（Richard Alan Schafer Masahiro Sekiguchi）马克·谢尔曼·鲍勃·斯马特彼得·斯派克·亨利·斯宾塞艾纳·斯特弗鲁德·迈克尔·斯坦因克劳斯·斯坦伯格（Klaus Steinberger）彼得·斯文伯格（Peter Svanberg）詹姆斯·汤普森-史蒂夫·尤勒斯图亚特·万斯·彼得·范德比尔特格雷格·瓦德鲁伊尔·埃德·维尔梅蒂拉里·维登·瑞恩·沃尔德龙里斯·威瑟利·杰·韦伯戴夫·威克·沃利·威德尔Sven-Ove Westberg Brian Wideen公司约翰·沃布斯·格伦·赖特Rayan Zachariassen大卫·齐默尔曼作者对清单中的任何遗漏表示歉意，这些遗漏包括当然是无意的。Freed&Borenstein标准课程[第14页]

RFC 2049MIME一致性1996年11月附录A——复杂的多部分示例下面是复杂的多部分消息的概要。这个消息包含五个要连续显示的部分：两个介绍性纯文本对象、嵌入的多部分消息、文本/扩展对象，以及非ASCII字符集。嵌入的多部分消息本身包含两个要并行显示的对象，一个图片和一个音频片段。MIME版本：1.0发件人：Nathaniel Borenstein<nsb@nsb.fv.com>收件人：Ned Freed<ned@innosoft.com>日期：1994年10月7日星期五16:15:05-0700（太平洋夏令时）主题：多部分示例内容类型：多部分/混合；边界=唯一边界-1这是多部分消息的前导区域。理解多部分格式的邮件阅读器应该忽略这个序言。如果你正在阅读这篇文章，你可能想考虑换一个能理解的邮件阅读器如何正确显示多部分消息。--唯一边界-1…此处显示一些文本。。。[注意边界和起点之间的空白此部分中的文本表示没有标题字段这是US-ASCII字符集中的文本。它可以通过显式键入完成，如下一部分。]--唯一边界-1内容类型：文本/纯文本；charset=US-ASCII这可能是前一部分的一部分，但说明了身体的显式类型与隐式类型部分。--唯一边界-1内容类型：多部分/并行；边界=唯一边界-2--唯一边界-2内容类型：音频/基本Freed&Borenstein标准课程[第15页]

RFC 2049MIME一致性1996年11月内容传输编码：base64…base64编码8000 Hz单信道μ定律格式的音频数据在这里。。。--唯一边界-2内容类型：image/jpeg内容传输编码：base64…此处显示base64编码的图像数据。。。--唯一边界-2----唯一边界-1内容类型：文本/丰富这是浓缩的</斜体><较小>如中所定义RFC 1896</更小>不是吗酷吗</更大></更大>--统一基础-1内容类型：message/rfc822发件人：（US-ASCII邮箱）收件人：（US-ASCII中的地址）主题：（US-ASCII主题）内容类型：文本/纯文本；charset=ISO-8859-1内容传输编码：可引用打印…此处显示ISO-8859-1中的其他文本。。。--唯一边界-1--附录B——变更RFC 1521号文件、1522和1590这些文件是RFC 1521号文件、1522和1590。对于熟悉早期文档、更改的人员的便利性本附录对这些文件进行了总结。进一步了解历史，请注意RFC 1521中的附录H指定该文档的方式不同于其前身，射频1341.（1） 此文档已完全重新格式化和拆分到多个文档中。这样做是为了改进本文档纯文本版本的质量，需要作为参考副本。Freed&Borenstein标准轨道[第16页]

RFC 2049MIME一致性1996年11月（2） 描述MIME对象总体结构的BNF标题已添加。这是一个文档更改only--在任何方式。（3） MIME中七种媒体类型的特定BNF有已删除。此BNF不正确、不完整，并且与类型无关的BNF不一致。并且因为type-independent BNF已经完全指定各种MIME头的语法，类型-最终分析，特定BNF完全不必要，造成的问题比解决的问题多。（4） 更具体的“US-ASCII”字符集名称具有在许多这些文件的一部分。（5） 主要亚型的非正式概念是远离的。（6） 术语“对象”的使用不一致。这个该术语的定义已经澄清，以及相关术语“主体”、“主体部分”和“实体”，并在适当的地方纠正了用法。（7） 多部分媒体类型的BNF重新安排，以明确CRLF正在进行边界标记实际上是标记的一部分而不是前面的身体部位。（8） 描述多部分媒体类型的散文和BNF已经进行了更改，以明确身体部位在多部分对象中不能包含任何行从边界参数字符串开始。（9） 在重新组装“消息/部分”MIME的规则中实体，将“主题”添加到标题列表中从内部消息中获取，示例如下修改以澄清这一点。（10） “消息/部分”碎片仅限于仅在线条边界处拆分MIME对象。（11） 在讨论应用程序/后记脚本类型时，增加了一段警告嵌入可能导致的互操作性问题PostScript MIME实体内的二进制数据。Freed&Borenstein标准课程[第17页]

RFC 2049MIME一致性1996年11月（12） 为的基本语法规则添加了澄清说明Content-Type标题字段，以明确以下两种形式：内容类型：文本/纯文本；charset=us ascii（注释）内容类型：文本/纯文本；charset=“us-ascii”完全等效。（13） 以下句子已从MIME-Version标头的讨论：“然而，鼓励一致性软件检查版本数字，如果无法识别遇到MIME版本。"（14） 修复了“application/external-body”的拼写错误而不是“message/external-body”。（15） 字符集的定义已重新组织使需求更加明确。（16） “image/gif”媒体类型的定义如下移动到单独的文档。进行了此更改因为可能与IETF规则冲突管理专利技术的标准化。（17） “7bit”和“8bit”的定义如下拧紧，以便只能使用裸露的CR、LF作为行尾序列。该文档也不再要求保留NUL字符，这会带来MIME与现实世界的实现保持一致。（18） MIME中规范文本的定义如下拧紧以使换行符必须由CRLF序列。不允许使用CR和LF字符超出此使用范围。引用的定义-可打印编码已相应地改变。（19） 现在引用可替换编码的定义包括一些关于如何引用的建议-可打印编码器可能最好处理不正确的编码材料。（20） 增加了散文以澄清“7bit”的用法，多部分或上的“8bit”和“binary”传输编码封装“8位”或“二进制”数据的消息实体。Freed&Borenstein标准课程[第18页]

射频2049MIME一致性1996年11月（21）在MIME一致性章节中，“多部分/摘要”支持已添加到的需求列表中最小MIME一致性。此外“message/rfc822”支持得到加强，以澄清识别递归结构的重要性。（22）对“消息”子类型的各种限制是现在完全按子类型指定。（23）“消息/rfc822”的定义更改为表示“发件人”、“主题”或“日期”标题必须存在。（24）未识别子类型的必要处理为“application/octet-stream”更加明确在类型定义部分和合规指南。（25）使用text/richtext的示例更改为文本/丰富。（26）BNF子类型的定义已更改为很明显，IANA注册的亚型或内容类型中必须使用非标准的“X-”子类型标题字段。（27）简单注册使用的MIME媒体类型，以及那些由IETF标准化的现在是在MIME BNF中有所不同。（28）所有MIME注册程序都有被广泛修订。IANA注册程序字符集已移动到单独的未包含在此文档集中的文档。（29）美国科学院国际研究所逃生和转移机制的使用以及这些文档定义的ISO-8859-X字符集已澄清：此类机制不应与这些字符集及其未定义使用效果。（30）的AFS访问类型定义消息/external-body已删除。（31）组合的处理多部分/替代和消息/外部主体现在是具体解决。Freed&Borenstein标准课程[第19页]

RFC 2049MIME一致性1996年11月（32）特定于消息/外部正文的安全问题是现在详细讨论一下。附录C——参考[ATK公司]Nathaniel S.Borenstein，多媒体应用《使用Andrew Toolkit开发》，Prentice-Hall，1990年。[ISO-2022标准]国际标准——信息处理--字符代码结构和扩展技术，ISO/IEC 2022:1994，第4版。[ISO-8859标准]国际标准--信息处理--8位单字节编码图形字符集-第1部分：拉丁字母1，ISO 8859-1:1987，第1版。-第2部分：拉丁字母2，ISO 8859-2:1987，第1版。-第3部分：拉丁字母3，ISO 8859-3:1988，第1版。-第4部分：拉丁字母4，ISO 8859-4:1988，第1版。-第5部分：拉丁/西里尔字母，ISO 8859-5:1988，1st预计起飞时间。-第6部分：拉丁/阿拉伯字母表，ISO 8859-6:1987，第1版。-第7部分：拉丁/希腊字母，ISO 8859-7:1987，第1版。-第8部分：拉丁/希伯来语字母，ISO 8859-8:1988，第1版。-第9部分：拉丁字母5，ISO/IEC 8859-9:1989，1st预计起飞时间。国际标准——信息技术——8位单字节编码图形字符集-第10部分：拉丁字母表第6号，ISO/IEC 8859-10:1992，第1版。[ISO-646标准]国际标准信息技术ISO信息交换用7位编码字符集，ISO 646:1991，第三版。。[JPEG格式]JPEG草案标准ISO 10918-1 CD。[MPEG标准]视频编码标准草案ISO 11172 CD，ISOIEC/JTC1/SC2/WG11（电影专家组），1991Freed&Borenstein标准课程[第20页]

RFC 2049MIME一致性1996年11月[动力系统控制模块]CCITT，分册III.4-建议G.711，“脉冲代码语音频率调制（PCM）”，日内瓦，1972年。[海报]Adobe Systems，Inc.，PostScript语言参考《手册》，Addison-Wesley，1985年。[海报2]Adobe Systems，Inc.，PostScript语言参考《手册》，Addison-Wesley，第二版，1990年。[RFC-783号文件]Sollins，K.R.，“TFTP协议（第2版）”，RFC-783号文件,麻省理工学院，1981年6月。[RFC-821号文件]Postel，J.B.，“简单邮件传输协议”，STD 10，RFC 821号文件，南加州大学/信息科学研究所，1982年8月。[RFC-822号文件]Crocker，D.，“ARPA互联网格式标准文本消息”，STD 11，副本请求822，UDEL，1982年8月。[RFC-934号文件]Rose，M.和E.Stefferud，“提议的信息标准封装”，射频934特拉华州和NMA，1985年1月。[RFC-959号文件]Postel，J.和J.Reynolds，《文件传输协议》，STD9,副本请求959，南加州大学/信息科学研究所，10月1985[RFC-1049号文件]Sirbu，M.，“互联网内容类型标题字段消息”，副本请求1049，CMU，1988年3月。[RFC-1154号文件]Robinson，D.和R.Ullmann，“编码标题字段互联网消息“，副本请求1154，Prime Computer，Inc.，4月1990[RFC-1341号文件]Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）：指定和描述互联网消息体的格式”，无线电频率控制
        1341，Bellcore，Innosoft，1992年6月。Freed&Borenstein标准课程[第21页]

RFC 2049MIME一致性1996年11月[RFC-1342号文件]Moore，K.，“互联网中非科学文本的表现消息标题“，RFC 1342号文件6月，田纳西大学1992[RFC-1344号文件]Borenstein，N.，“MIME对互联网邮件的影响”网关”，RFC 1344号文件《Bellcore》，1992年6月。[RFC-1345号文件]Simonsen，K.，“字符记忆与字符集”，无线电频率控制
        1345《Rationel Almen Planlaegning》，1992年6月。[RFC-1421号文件]Linn，J.，“互联网电子产品的隐私增强邮件：第一部分——消息加密和身份验证程序”，RFC 1421号文件、IAB IRTF PSRG、IETF PEM WG、，1993年2月。[RFC-1422号文件]Kent，S.，“互联网电子产品的隐私增强邮件：第二部分——基于证书的密钥管理”，无线电频率控制
        1422IAB IRTF PSRG，IETF PEM WG，1993年2月。[RFC-1423号文件]Balenson，D.，“互联网隐私增强电子邮件：第三部分——算法、模式和标识符”，IAB IRTF PSRG，IETF PEM WG，1993年2月。[RFC-1424号文件]Kaliski，B.，“互联网电子产品的隐私增强邮件：第四部分——关键认证及相关服务”，IAB IRTF PSRG，IETF PEM WG，1993年2月。[RFC-1521号文件]Borenstein，N.和Freed，N.，“MIME（多用途Internet邮件扩展）：指定和描述互联网消息体的格式”，无线电频率控制
        1521，Bellcore，Innosoft，1993年9月。[RFC-1522号文件]Moore，K.，“互联网中非ASCII文本的表示消息标题“，RFC 1522号文件田纳西大学，1993年9月。Freed&Borenstein标准课程[第22页]

射频2049MIME一致性1996年11月[RFC-1524号文件]Borenstein，N.，“用户代理配置机制多媒体邮件格式信息“，RFC 1524号文件，Bellcore公司，1993年9月。[RFC-1543号文件]Postel，J.，《RFC作者须知》，副本请求1543,南加州大学/信息科学研究所，1993年10月。[RFC-1556号文件]Nussbacher，H.，“双向文本的处理MIME“，射频1556，以色列大学间计算机中心，1993年12月。[RFC-1590号文件]Postel，J.，“媒体类型注册程序”，无线电频率控制
        1590，USC/信息科学研究所，1994年3月。[RFC-1602号文件]互联网架构委员会，互联网工程指导小组，Huitema，C.，Gross，P.，“互联网标准过程——第2版”，1994年3月。[RFC-1652号文件]Klensin，J.，（工作组主席），Freed，N.，（编辑），Rose，M。，Stefferud，E.和Crocker，D.，“SMTP服务扩展用于8bit-IME传输“，RFC 1652号文件，联合国大学，Innosoft，Dover Beach Consulting，Inc。，Network Management Associates，Inc.分公司，1994年3月。[RFC-1700号文件]Reynolds，J.和J.Postel，“指定数字”，STD 2，副本请求1700，南加州大学/信息科学研究所，10月1994[RFC-1741型]Faltstrom，P.、Crocker，D.和Fair，E.，“MIME内容BinHex编码文件的类型”，1994年12月。[RFC-1896号文件]Resnick，P.和A.Walker，“文本/丰富的MIME内容类型“，射频频率18961996年2月。Freed&Borenstein标准课程[第23页]

RFC 2049MIME一致性1996年11月[RFC-2045号文件]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第1部分：Internet消息格式身体”，射频2045、Innosoft、First Virtual Holdings、，1996年11月。[RFC-2046号文件]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型“，RFC 2046号文件,Innosoft，First Virtual Holdings，1996年11月。[RFC-2047号文件]Moore，K.，“多用途互联网邮件扩展（MIME）第三部分：非ASCII文本在互联网上的表现消息标题“，副本请求2047，美国大学田纳西州，1996年11月。[RFC-2048号文件]Freed，N.、Klensin，J.和J.Postel，“多用途Internet邮件扩展（MIME）第四部分：MIME注册程序”，RFC 2048号文件、Innosoft、MCI、，ISI，1996年11月。[RFC-2049号文件]Freed，N.和N.Borenstein，“多用途互联网邮件”扩展（MIME）第五部分：一致性标准和示例“，RFC 2049（本文件），Innosoft，First虚拟控股公司，1996年11月。[美国-亚洲科学院]编码字符集——7位美国标准编码信息交换，ANSI X3.4-1986。[X400个]Pietro Schicker，“消息处理系统，X.400”，消息处理系统和分布式应用，E。斯特弗鲁德，O-j.雅各布森和P.希克编辑，北方-荷兰，1989年，第3-41页。Freed&Borenstein标准课程[第24页]