RFC2048中文

最近学习MIME文档类型，遇到了RFC系列文件，部分网上已有了中文版，未找到RFC2048的中文翻译，便自己进行了翻译学习，不足之处还请见谅！

MIME类型第四部分文档

IESG：The Internet Engineering Steering Group，因特网工程指导组
IETF：The Internet Engineering Task Force，国际互联网工程任务组
IANA：The Internet Assigned Numbers Authority，互联网数字分配机构

MIME登记注册程序
第四部分文档（RFC2048）为下面的MIME设备明确了各种IANA注册程序：
（1）媒体类型
（2）外部实体访问类型
（3）内容传输编码
在MIME中使用的字符集在别的地方进行了说明，这个文档中就不再赘述。
这些文档是RFC1521和1522的修改版，也是RFC1341和1342的修订。在RFC2049文件附录中描述了与先前版本的不同与改变。

目录
1.介绍
2.媒体类型注册
2.1注册树和子类型名
2.1.1IETF树
2.1.2供应商的树
2.1.3个人的树或抽象的树
2.1.4特殊的X树
2.1.5额外的注册树
2.2注册要求
2.2.1功能要求
2.2.2命名要求
2.2.3参数要求
2.2.4标准和格式要求
2.2.5交换建议
2.2.6安全要求
2.2.7无要求的使用和实现
2.2.8出版要求
2.2.9其他信息
2.3注册程序
2.3.1向社区呈现媒体类型以供核查
2.3.2IESG同意
2.3.3IANA注册
2.4媒体类型注册说明
2.5注册的媒体类型表中的位置
2.6IANA的媒体类型注册程序
2.7更改控制
2.8注册模版
3.外部实体访问类型
3.1注册要求
3.1.1命名要求
3.1.2机制的规范要求
3.1.3出版要求
3.1.4安全要求
3.2注册程序
3.2.1将访问类型展示给社区
3.2.2访问类型的核查
3.2.3IANA注册
3.3注册的访问类型表的位置
3.4IANA的注册访问类型的程序
4.转换编码
4.1转换编码的要求
4.1.1命名要求
4.1.2算法的规范要求
4.1.3输入域的要求
4.1.4输出范围的要求
4.1.5数据完整性和通用性要求
4.1.6新功能性要求
4.2转换编码命名程序
4.3IANA转换编码的注册程序
4.4注册的转换编码表的位置
5作者地址
A.Grandfathered 媒体类型


1.介绍
当前的因特网协议已经设计为在一些某些领域容易扩展的。特别的是，MIME（RFC2045）是一个开放式的架构，不通过修改任何的基础协议就可以兼容附加的对象类型，字符集和访问方法。然而，一个注册流程还是需要来保证一系列的值在一套有秩序的，明确的和公开的方式进行。
这篇文档定义使用IANA为这系列值作为总的注册的注册程序。
历史注解：媒体类型的注册流程最初被定义在异步Internet邮件环境的上下文之中。在这个邮件环境中对于当远方的邮件系统的能力不清楚时是需要限制媒体类型的数量来增加互操作的可能性。当媒体类型在媒体类型的扩散不妨碍互操作性的新环境中使用时，原始程序是机器严格的并必须是普遍的。

2.媒体类型注册
一个新的媒体类型或类型的注册以一个注册提议书的撰写开始。注册可能发生在有着下面讨论的不同规则几种不同的注册树状图中。通常的，新的注册提议的分发和审查方式与所涉及的树状图相适应。如果提议被接受，这个媒体类型接下来就会被注册。下面的几个部分描述了不同的注册树状图的要求和流程。
2.1注册树状图和子类型名
为了增加注册流程的有效性和灵活性，不同结构的子类型名可能会注册适应不同的要求，例如：一个子类型将会被英特网社区要求支持广泛和实现或者一个用于移动与专有软件相关联的文件的子类型。接下来的几小节定义了注册“树”，以使用的名字区分（如：“tree.subtree...tree”的名字形式）。注意对于这篇文档一些媒体类型定义优先的，不会遵守下面描述的命名转换，这些会在附录A中讨论。
2.1.1IETF“树”
IETF“树”的目的是互联网社区普遍感兴趣的类型。IETF树的注册要求被IESG提议和媒体类型注册作为RFC一些形式。
在IETF树中媒体类型正常以names明确地指出其不含结束符（“.”，全部停止）。
在IETF树中媒体类型注册的拥有者是被认为IETF自身。修改或更改规范要求初始注册所需的相同级别的处理（例如标准磁盘）。
2.1.2供应商树
供应商树是用于与商业相关的可用媒体类型。在这种情况下，供应商与生产者被解释为等同的和非常广泛的。
一个注册可以被任何有需要在交换与特殊产品相关的文件的人放在在供应商树中。然而，注册正常地属于生产了软件或文件格式的供应商或组织。根据他们的要求，将对规范进行更改，如后面章节讨论的一样。
在供应商树中的注册将会被前面的“vnd.”区分。在注册的考虑上，可能在其之后有一个媒体类型或知名的制作人（如："vnd.mudpie"），或有IANA批准指定的生产商的名称然后接着一个媒体类型或产品名称（如："vnd.bigcompany.funnypictures"）。
虽然不需要公开和审查要在供应商树中注册的媒体类型，但强烈鼓励使用IETF类型列表进行评审，以改进这些规范的质量。在树的注册供应商可以直接提交到IANA。
2.1.3个人的或无价值的树
实验性创造出的媒体类型的注册或一个非商业发行的产品的一部分，可以在个人或无价值的树中注册。注册是以"prs."开头区分的。
个人注册和相关规范的拥有者是注册的人或者是下面描述的有责任的人。
虽然公开和审查在个人树中注册的媒体类型不是必须的，但是强烈建议使用IETF列表进行审查来提高规范的质量，在个人数中注册的媒体类型可以直接提交到IANA。
2.1.4特殊的“x”树
为了方便和对称的注册计划，媒体类型名称的“x.”作为第一个方面，可用于相同目的，从"x-"开始使用的名称。这些类型是未注册的，实验性的，只有在双方交换协议时才使用。
然而，有了上面描述的供应商和个人树的简单的注册流程，这个树应该被鼓励使用未注册的实验性的类型，"x."和"x-"的形式都不被鼓励使用。
2.1.5额外的注册树
不时会被社区需要，在IESG和下属机构的建议下，IANA可能会创建新的顶级注册树。明确的是这些可能被创建的树由知名常设机构进行外部注册和管理的，如专门针对其所涵盖的科学的媒体类型的科学团体。一般而言，这些附加树中的一个规范的评审质量相当于IETF将在其自己的树上注册的质量。这些新树的建立将通过RFC发布，由IESG批准。
2.2注册要求
媒体类型注册提议所有都期待遵守下面几节各种各样的要求。注意的是要求有时随着注册树变化。
2.2.1功能性要求
媒体类型必须作为一种实际的媒体格式：将那些被更好地认为是传输编码的东西作为编码集，或者一种类型的独立实体。例如，尽管解base64编码的应用存在
，base64也不能注册为一种媒体类型。
这个要求不管任意注册树都适用。
2.2.2命名要求
所有注册的媒体类型都必须指定MIME类型和子类型名。这些名的组合来唯一的确定媒体类型以及子类型名的文件格式确定注册树。
顶级类型的选择必须考虑到涉及媒体类型的性质。例如，通常用于表示静止图像的媒体应该是图像内容类型的一个子类型，而能够表示音频信息的媒介属于音频内容类型。有关基本类型及其基本特性的附加信息，请参阅RFC2046。
顶级类型的新子类型必须遵守顶级类型的限制，如果有的话。例如：所有多部分内容类型的子类型必须使用同样的封装语法。
在一些情况中一个新的媒体类型可能不“适合”在任何当前定义的顶级内容类型中。这样的情况期望上是很少的。但是这情况只要出现一个新的顶级内容类型就可以被定义来适应它。这样一个定义必须通过RFC标准；没有其他的机制能够被使用来定义其他的顶级内容类型。
这些要求也同样适用于其他的注册树。
2.2.3参数要求
媒体类型可能选出一个或多个MIME内容类型参数，或者一些参数可能通过内容类型的子类型定义的应用于其子类型的一系列参数自动地对媒体类型可得到。在别的例子下，当一个媒体类型在IETF树中注册时，参数的名字，值以及意义都必须完全地明确而；在媒体类型注册在个人或无价值的树中时，应该尽可能地完整明确。
在IETF注册树中新的参数禁止被定义为一个介绍新的功能的方式，尽管新的参数可能会是增加来传递额外的信息而没有改变现有的功能。这个的一个例子会是修订参数来暗示一个外部规范的修订等级如JPEG。同样媒体类型的行为注册到供应商或个人树不被要求。
2.2.4规范化和格式要求
所有注册的媒体类型必须使用一个单例规范数据格式，不管注册树。
对于在IETF注册树的所有类型，都必须有一种精确且公开可用的每个媒体类型的格式规范，并且如果媒体类型注册建议本身不包括在内，那么至少必须引用它。
格式和处理资料的规格可能会或不会公开的媒体类型在供应商树注册和登记，建议明确允许只包括一个规范的软件和版本产生或处理这样的媒体类型。鼓励在注册建议书中提及或列入格式规范，但不是必须的。
在个人树注册的格式说明依然是需要的，但可能作为RFCs发布或存放在IANA。存放的规范将与注册一个著名的TCP端口所需的规范一致，特别的是，不需要公开。
一些媒体类型包含有专利权的科技使用。这种是特别允许的。然而，当标准的管制协议规范是标准跟踪协议的一部分时，必须遵守RFC1602中有专利权的技术使用的限制。
2.2.5交换建议
媒体类型应该尽可能多的在系统和应用中实现。然而，一些媒体类型在跨不同平台的时候有互操作的问题。不同的版本，字节编码，以及网关处理的细节都会出现。
通用的媒体类型互操作性不是必须的，但应当尽可能识别已知的互操作问题。媒体类型的发布不要求经过互操作核查，互操作可能性部分将继续进行评估。
这些提议不管注册树类型都适用。
2.2.6安全要求
在IETF注册的所有类型都必须要有一份安全问题分析。（这是根据基本情况对所有的IETF协议的要求）同样注册在个人或供应商树的媒体类型的安全问题分析
是被鼓励但不是必须的。然而，不管安全问题的分析做没做，在哪一个注册树中所有的安全问题描述必须尽可能准确。特别的，不存在此类相关的安全问题的声明不能混淆为与此类关联的安全问题未被评估。
绝对没有要求媒体类型的注册树是安全或完全没有风险的。尽管这样，不管哪个注册树一种媒体类型的注册的已知安全问题风险必须识别出来。
所有注册的安全考虑部分的主体是继续评估和修改，特别是使用“媒体类型评论”机制进行扩展了的后一部分。
一种媒体类型注册的安全分析需要考虑的问题：
（1）复杂的媒体类型可能包括对收件人采取行动的指令文件或其他资源的规定。在很多情况下，规定是为发起人在一个指定的不受限制的任意可能有破坏性的动作行动。在RFC2046中注册application/postscript媒体类型就是这样的例子，可以在RFC2046中找到如何处理。
（2）复杂媒体类型可能包括指定直接或间接在某些方面对收件人隐私有害的动作的规定。在此，注册application/postscript媒体类型说明了如何处理这类指令。
（3）媒体类型可能针对的对程序某种需要做安全保证，但不是提供必要的安全机制本身。例如，可以定义媒体类型来储存保密的医疗信息，这又需要外部保密服务。
2.2.7无要求的使用与实现
在异步邮件环境下，要求远程邮件代理功能的信息是很频繁的，对于发件人最大的互操作性是通过限制常用的媒体类型格式数量。这是由于过去作为一个限制潜在的媒体类型数量的一个理由，并且导致了注册过程中存在重大障碍和延误。
然而，对常用媒体类型的需求不要求限制新的媒体类型注册。如果媒体类型本设计是有限的使用，应当在注册中说明。
2.2.8发布要求
在IETF树中注册的媒体类型是必须作为RFC发布。RFC发布供应商和个人媒体类型是鼓励的，但不是必需的。在所有情况下，IANA都会保留所有媒体类型提案的副本并将其“发布”为其媒体类型注册树本身的一部分。
除了在IETF树中，数据类型的注册不意味着IANA或IETF的认可，批准或推荐即使认证说明书是足够的。不论成为互联网标准，协议，数据对象还是什么都必须通过IETF标准流程。这对于媒体类型便捷的注册来说太难也太冗长了。
对于需要与供应商进行实质性审查和批准的媒体类型，IETF树是存在的，而个人树是不存在的。预计将不时发布适用于特定应用的说明性文档，建议在这些上下文中证明已特别有用的媒体类型的实现和支持。
正如上面所说，注册一个顶级的类型需要一个标准的流程以及RFC发布。
2.2.9额外的信息
如果媒体类型可用，各种各样可选的信息在媒体类型说明中：
（1）魔数（length，octet values）：魔数是总是存在的字节序列，因此可以用来识别实体是否是给定的媒体。
（2）文件扩展名：通常用来表示包含给定类型的媒体文件。
（3）Macintosh文件类型代码（4字节）用于标识包含一个给定类型的媒体文件。
这些信息对于使用者是十分有用的，应当提供可用。
2.3注册程序
IANA已经实施了以下程序供审查和批准新的媒体类型。这不是一个标准程序，而是旨在允许社区评估和检查，没有过多时间延迟的管理程序。为了在IETF树中注册，应该遵守正常的IETF过程，处理互联网草案和公告在ietf-type列表的第一步。对于在供应商和个人树注册，下面的初始审查过程可以省略，类型也可以直接提交模版和注释直接注册到IANA（[e-mail]）。但是，在社区中寻求供应商或个人媒体类型说明审查无论何时都是被鼓励的。
2.3.1将媒体类型呈现给社区进行审查
将提议的媒体类型注册发送到“[e-mail]”邮件列表以两周的审查期。这个邮件列表是为了审查提议的媒体而设立的访问类型。提议的媒体类型没有正式注册不得使用；可以使用在RFC2045中指定的“X-”前缀直到注册完成。
公开发布的目的是在类型/子类型的选择上征求建议和反馈意见，还有引用版本和外部信息的明确性以及审查任何互操作性或安全考虑。提交者在任何时候都可以提交修改后的注册，或撤回注册。
2.3.2IESG批准
IETF树中注册的媒体类型都必须提交给IESG批准。
2.3.3IANA注册
只要媒体类型符合媒体类型的要求并获得必要的批准，注册者就可以向注册媒体并提供给社区的IANA提交注册请求。
2.4媒体类型注册的评估
注册媒体类型的评估可以由社区会员提交到IANA。这些意见将会尽可能传递到“所有者”。意见提供者可能会要求意见被附加到媒体类型注册本身，如果IANA批准，意见就会和类型注册在一起。
2.5注册媒体类型列表的位置
媒体类型注册将被张贴在匿名FTP目录"ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/",所有的注册媒体类型都会定期列出，分发“分配号码”RFC[当前STD 2,RFC 1700].媒体类型说明及其辅助材料也可以发布作为RFC信息到"[e-mail]"（请遵循RFC作者的说明[RFC-1543]）。
2.6IANA注册媒体类型的程序
IANA只会在IETF注册树中注册媒体类型作为回应IESG说明注册批准的来函。供应商和个人类型将没有任何审查地自动通过注册，只要满足以下最低条件：
（1）媒体类型必须作为实际的媒体格式。特别的，字符集和传输编码不会注册为媒体类型。
（2）所有媒体类型必须有正确的形式和子类型名。所有的类型名必须遵循RFC标准。所有的子类型名称必须是唯一的，必须符合MIME语法，并且必须包含适当的树形前缀。
（3）在个人树中注册的类型必须提供一个格式规范或指导。
（4）任何安全考虑不能虚假。（这是不可能也不必要对于IANA来说去进行全面媒体类型注册的安全审查。不过，IANA有权查明显然无用的材料并排除）
2.7转换控制
IANA发布媒体类型之后，作者可以要求提供对其定义的改变。上面不同注册树的描述指定每种类型注册的“所有者”。要求更改遵循与注册要求同样的程序：
（1）在ietf-types列表上发布修改后的模板。
（2）至少保留两周的意见
（3）如果需要，正式审核后使用IANA发布
只有在有严重遗漏的情况下才可以要求更改发布的规范中的错误。当需要审核时，根据新定义下的无效定义如果呈现有效的实体，更改请求可能会被拒绝。
内容类型的所有者可以通过通知IANA和ietf列表传递内容类型的职责给别人或机构代理，这个可以在没有讨论或审核的情况下完成。
IESG可能会重新分配媒体类型的职责。最普遍的情况下是对类型进行更改注册者已经离世，失去联系否则社区无法做出重大的改变。
媒体类型注册也许不会删除；媒体类型使用不再可信就会被宣布为OBSOLETE通过更改“预定用途”字段；这样的媒体类型将是在IANA发布的清单中明确标出的。
2.8注册模板
To:[e-mail]
Subject:Registration of MIME media type XXX / YYY
MIME media type name:
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification:
Applications which use this media type:
Additional information:
Magic number(s):
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information:
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Author/Change controller:
(Any other information that the author deems interesting may be added below this line.)
3.外部实体访问类型
RFC2046定义了消息/外部主体媒体类型，即MIME实体可以作为指向实体数据的指针来代替实体中的数据。每个消息/外部实体引用指定访问类型，确定用于检索实际数据的机制。RFC2046定义了一组初始访问类型，但允许注册其他访问类型以适应新的检索机制。
3.1注册要求
新的访问类型规范必须符合下面所说的要求
3.1.1命名要求
每种访问类型都必须具有唯一的名称。这个名字出现在消息/外部实体内容类型中的访问类型参数头字段，并且必须符合MIME内容类型参数语法。
3.1.2机制规范要求
由任何有能力的执行者给定的所有协议，传输和程序访问类型必须在规范中描述访问类型本身或其他的一些公开可用的规范，足够详细的访问类型细节。使用秘密的或私有的专有方法是明确禁止的。在RFC1602有关专利算法标准化的限制也应当遵守。
3.1.3发布要求
所有的访问类型都必须有RFC描述。尽管标准核查和批准被所有访问类型鼓励，RFC可能是信息化而非标准化的流程。
3.1.4安全要求
由于使用访问类型而产生的任何已知的安全问题必须完整而充分描述。不要求访问类型是安全或无风险的，但必须识别已知的风险。一种新的访问类型的发布不需要详尽的安全核查，安全的考虑部分有待继续评估。额外的安全考虑问题应该通过发布访问类型规范的修订版本来解决。
3.2注册程序
新的访问类型的注册从建立一个RFC草案开始。
3.2.1向社区呈现访问类型
将提议的访问类型规范发送到"[e-mail]"邮件列表作为期两周的审查期。这个已经建立起来的邮件列表用于审查提议的访问和媒体类型。提议的访问类型未正式注册不得使用。
公开发布的意图是为了对访问类型规范和任何安全性考虑征求意见和反馈意见。
3.2.2访问类型核查者
当两周的时间过去了，由IETF应用区域总监任命访问类型核查人转发请求到"[e-mail]"，或者因为列表上重大的意见拒绝。
审查人在14天内必须将决定发布到ietf-types邮件列表中。审核员做出的决定可能会被IESG上诉。
3.2.3IANA注册
只要访问类型已通过审核或已经成功交到IESG，IANA将注册访问权限并向社区提供注册。该访问类型的规范也必须作为RFC发布。RFC信息发送到"[e-mail]"（请按照RFC作者的说明进行发布[RFC-1543]）。
3.3注册访问类型列表的位置
访问类型注册将在匿名FTP目录"ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/"中发布，所有注册的访问类型将在定期发布"分配号码"RFC[当前RFC-1700]。
3.4IANA登记访问类型
访问类型审查的身份被IESG传给IANA。IANA仅对访问类型定义起作用，访问类型定义要么被访问类型审核人批准，要么由审核人员转发给IANA进行注册，要么响应IESG的通信，即访问类型定义申诉已经推翻了访问类型审查的裁决。
4传输编码
转换编码是在转换为媒体类型的规范之后应用于MIME媒体类型的转换。传输编码被用于几个目的：
（1）许多传输特别是消息传输只能处理相对较短的文本行组成的数据。在这些文本中可以使用哪些字符也有严格的限制-有些传输仅限于US-ASCII的一小部分，而另一些则不能处理某些字符序列。传输编码被用来将二进制数据转换为文本形式，以便在这种传输中生存下来。这种传输编码的例子包括在RFC2045定义的base64和quoted-printable传输编码。
（2）图像，音频，视频甚至应用程序实体有时相当大。压缩算法通常在减小大型实体的方面非常有效。传输编码可用于将通用的无损压缩算法应用于MIME实体。
（3）传输编码可以被定义为在MIME上下文表示现有的编码格式。
重要：大量不同标准化的传输编码被认为是广泛互操作性的重要障碍，并且被泄漏。尽管如此，下面的过程如果标准化实际上是合理的被定义为提供一种定义附加转换编码的方法。
4.1传输编码要求
传输编码规范必须符合下述的许多要求。
4.1.1命名要求
每个传输编码都必须具有唯一的名称。该名称出现在Content-Transfer-Encoding头字段中，并且必须符合该字段的语法。
4.1.2算法规范要求
传输编码中使用的所有算法（例如转换为可打印格式，压缩）必须在传输编码规范中全部描述。明确禁止在标准传输编码中使用秘密或专有算法。RFC1602对专利算法标准化限制也必须遵守。
4.1.3输入域要求
所有传输编码必须适用于任意的序列字节长度。对特定输入表单的依赖是不允许的。
应该指出的是，7位和8位编码不符合这个要求。除了具有专门的编码的不必要性之外，这里是想禁止沿着7bit和8bit的行添加额外的编码。
4.1.4输出范围要求
不要求特定的传输编码产生特定形式的编码输出。但是每个编码的输出格式必须完整并完整记录。每个说明必须清楚是否每个输出总是处于7bit数据，8bit数据的范围之外，或者是纯粹的二进制数据。
4.1.5数据完整性和通用要求
所有传输编码必须在任何平台上万权可逆；它必须是每个人都能通过恢复原始数据执行对应的解码操作。注意的是，这一要求有效地排除了所有形式的有损压缩以及作为传输编码的所有形式的加密。
4.1.6新功能要求
所有传输编码都必须提供某种新功能。某种程度的功能与先前定义的传输重叠编码是可以接受的，但是任何新的传输编码也必须提供其他传输编码提供的东西。
4.2传输编码定义过程
新传输编码的定义从构建标准RFC草案开始。RFC必须准确完整地定义传输编码，还必须为定义和标准化新的传输编码提供充分的理由。
这个规范必须提交到IESG批准。IESG可以：
（1）完全拒绝规范，不符合标准；
（2）批准组建IETF工作组，按照IETF程序进行规范工作；
（3）直接接受规范并直接放行在标准流程上。
在标准传输编码规范遵循正常IETF规范标准。传输编码被认为是定义的，并且一旦在标准流程上就可以使用。
4.3IANA转换编码注册程序
无需向IANA注册转换编码的特殊程序。所有合法的传输编码注册都必须作为标准RFC出现，因此IESG有责任在新的传输编码获得批准时通知IANA。
4.4注册转换编码列表的位置
转换编码注册将被贴在匿名FTP目录"ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/",所有注册的转换编码将被列在定期发布"分配号码"RFC[当前RFC-1700]。
5.作者地址

   欲了解更多信息，请
   通过Internet邮件联系本文的作者：
Ned Freed
Innosoft International，Inc.
美国加利福尼亚州，91790，
South West Covina 东加维大街1050号
电话：[phone]
传真：[phone]
电子邮件：[e-mail]
John Klensin
MCI
2100 Reston，Parkway
Reston，VA 22091
电话：[phone]
传真：[phone]
电子邮件：[e-mail]
Jon Postel
USC /信息科学研究所
4676 Admiralty Way
Marina del Rey，CA 90292
USA
电话：[phone]
传真：[phone]
电子邮件：[e-mail]

附录A-盛行的媒体类型
1996年以前注册的一些媒体类型，如果按照本文档的指定进行注册，将被置于供应商或个人树中。鼓励用适当的树重新注册这些类型，但不是必须的。本文档中概述的所有权和变更控制原则适用于这些类型，就好像已经在上述树中进行了注册。