组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：王俊丽（王小毛&nbsp;&nbsp;&nbsp;wangjunli_1029@163.net）<br />
译文发布时间：2001-9-10<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Postel<br />
Request&nbsp;for&nbsp;Comments:&nbsp;1590&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISI<br />
Updates:&nbsp;1521&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;March&nbsp;1994<br />
Category:&nbsp;Informational&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
<br />
多媒体类型注册过程<br />
(RFC&nbsp;1590&nbsp;——Media&nbsp;Type&nbsp;Registration&nbsp;Procedure)<br />
<br />
目录<br />
本文的地位：	2<br />
摘要	2<br />
1．&nbsp;介绍	2<br />
2.&nbsp;媒体注册类型过程	3<br />
2.1.&nbsp;提出注册社团的要求	3<br />
2.2.&nbsp;注册时向IANA提交内容类型	3<br />
3.&nbsp;具体问题的声明	3<br />
3.1.&nbsp;MIME要求有限的内容-类型	3<br />
3.2.&nbsp;印刷规格的要求	4<br />
3.3.&nbsp;安全考虑确定	4<br />
3.4.&nbsp;推荐和标准作用	4<br />
4.&nbsp;安全考虑	4<br />
5.&nbsp;致谢	4<br />
6.&nbsp;作者地址	5<br />
7．参考资料	5<br />
附录&nbsp;A&nbsp;IANA媒体类型注册过程	5<br />
<br />
本文的地位：<br />
&nbsp;&nbsp;本文提供了因特网通信信息，它并不是任何因特网的标准，本文的分布是不受限制的。<br />
摘要<br />
&nbsp;&nbsp;&nbsp;在一些协议中允许用数据来代表不同的“媒体”，例如，文本、图像、音频、视频，而且<br />
还可以用数据表达这些媒体中不同的编码格式，例如（在视频中）jpeg，gif，ief和tiff。在<br />
多媒体网际信息扩充协议（MIME）[1]中，定义了一些多媒体数据对象的初始类型和使用因<br />
特网安排数字权威（IANA）来注册附加类型的过程。在注册MIME内容-类型和子类型的<br />
要求和管理过程中，和媒体类型的其它应用中存在着一些问题。本文提出了这些问题，并具<br />
体讲了新媒体类型（内容-类型/子类型）注册的过程。而且，本文也总结了这些媒体类型的<br />
应用范围，使得它在其它应用中可以用到相同的的注册和规格。<br />
1．&nbsp;介绍<br />
RFC1521[1]中定义了用MIME来注册新数据类型的过程。设计注册机制是为了对给定的<br />
数据类型加以验证，而且为了防止命名的冲突。随着新的多媒体协议和存取机制的发展，这<br />
一过程有望为因特网协议形成一个通用的注册服务。这些类型以前被称为“MIME”类型，现<br />
在我们称它们为“媒体类型”。<br />
媒体类型（内容-类型/子类型）注册过程最初在匿名邮件环境中被定义，在这一邮件环<br />
境中，当远程的邮件系统能力不为所知时，为了增加协同能力，有必要限制媒体类型的数量。<br />
当媒体类型应用于新的环境，而且在这一环境中媒体类型的增加不会阻碍协同能力时，原始<br />
过程应当受到极度限制，而且必须是通用的。<br />
本文提出了产生的具体问题，而且就媒体类型注册提供了一个管理过程。而且这一过程<br />
也提出了将用到X.400MHS中的对象标识符（OIDs）映射为媒体类型所需的注册要求。<br />
2.&nbsp;媒体注册类型过程<br />
以下是IANA用来复查和认可新媒体类型的过程。这并不是一个正式的标准过程，而是<br />
一个在没有十分超时的情况下允许团体发表评论和理智检核的管理过程。<br />
2.1.&nbsp;提出注册社团的要求<br />
发送一个被提议的媒体类型（内容-类型/子类型）到“ietf-types@cs.utk.edu”邮件<br />
列表中。邮件列表建立的唯一目的是复查被提议的媒体类型，被提议的内容-类型并未被正<br />
式注册，它必须用“X-”标记子类型名。<br />
公众张贴的目的是在于获得关于内容-类型/子类型名字选择的评论和反馈，关于版本和<br />
外部轮廓信息的明确参考资料，选择哪种OIDs和安全部分复查。需要说明的一点时，提出<br />
的媒体类型不必对于每种可能的应用都有意义。如果媒体类型是有有限的或者是具体的用<br />
途，那么它在提交是应当加以标注。<br />
2.2.&nbsp;注册时向IANA提交内容类型<br />
两周后，向IANA提交提出的媒体类型以便注册。请求和支持文档发到iana@isi.edu，经<br />
过一段复查时期，IANA将注册媒体类型，在IANA分支中安排一个OID，并使这个媒体类型<br />
注册可行。<br />
媒体类型注册将记入匿名FTP录，ftp.isi.edu:in&nbsp;notes/media-types，媒体类型将列在定期<br />
出版的“Assigned&nbsp;Numbers”RFC[2]中。媒体类型描述可能印刷为信息RFC，通过将它发送<br />
到“rfc-editor@isi.edu”(请遵照RFC作者[3]的指导)<br />
3.&nbsp;具体问题的声明&nbsp;<br />
3.1.&nbsp;MIME要求有限的内容-类型<br />
问题:&nbsp;在异步邮件环境中,发送者对远程的邮件代理能力的信息不可知,最大的协同能<br />
力的获取可通过限制那些期望被广泛应用的“普通”内容-类型的数量。这就是限制可能的<br />
内容-类型的原因，这样导致了在注册过程中，注册内容-类型的明显阻碍耽搁。<br />
评论：&nbsp;“普通”内容-类型格式的需求不要求限制新的内容-类型注册。实际上这一限<br />
制可能导致由具体问题中分散的注册而引起的阻碍协同能力。如果一套有限的内容类型被推<br />
荐为特殊应用，那么这应当被应用或环境具体化分离应用声明而证实。<br />
3.2.&nbsp;印刷规格的要求<br />
问题：&nbsp;内容-类型注册要求一个RFC来具体化数据格式或者是一个印刷的数据流规格的<br />
参考。因为共有的规格对大量广泛应用和交换的对象是不可行的，所以在用内容-类型注册<br />
的文件附属和分布时，这一要求可能是过于受限制了。<br />
评论：&nbsp;MIME要求一个具体的内容-类型文件以便于清楚地确定一个一定义的类型。在<br />
注册内容-类型时，通过确定一个特定的软件包和版本，这一目的可以被满足，而且在注册<br />
中也是允许的。在一个不可用的规格中适当应用媒体类型应当在注册中不成问题。<br />
3.3.&nbsp;安全考虑确定<br />
　　&nbsp;问题：&nbsp;注册过程要求任何与内容-类型相关的已知安全问题的确定。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;评论：&nbsp;虽然并不要求内容-类型的安全或免于冒险。但是，已知的冒险应当是被确定<br />
的。内容-类型的公众并不要求彻底的安全检查，而且安全部分从属于连接评估。附加的安<br />
全考虑应当由IANA在RFC上定期公布。<br />
3.4.&nbsp;推荐和标准作用<br />
问题：&nbsp;数据类型注册用不着IANA或IETF的赞同或推荐，甚至不必证明规格是足够<br />
的。<br />
评论：为了成为因特网的标准，协议、数据对象或者其它的，都必须通过IETF标准过<br />
程，这一过程对注册媒体类型的便利和实际需要来说实在是太难而且也是太长了。所以就希<br />
望时不时的发行一些特定用途的陈述，以此来支持那些被证明特别有用的数据类型。<br />
4.&nbsp;安全考虑<br />
本文并未提出具体的安全问题，而是概括了一个媒体类型的安全检查过程。<br />
5.&nbsp;致谢<br />
在本RFC中大多数是John&nbsp;Klensin和Greg&nbsp;raudreuil-编写，我所作的工作只是修改了一<br />
些句子，删除了某些短语，重新安排了一些段落。也就说，对于所有不好的思想或是有损的<br />
句子，我都是有责任的，而他们对于所有好的思想都是有贡献的。<br />
6.&nbsp;作者地址<br />
&nbsp;&nbsp;&nbsp;Jon&nbsp;Postel&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;USC/Information&nbsp;Sciences&nbsp;Institute<br />
&nbsp;&nbsp;&nbsp;4676&nbsp;Admiralty&nbsp;Way&nbsp;<br />
&nbsp;&nbsp;&nbsp;Marina&nbsp;del&nbsp;Rey,&nbsp;CA&nbsp;&nbsp;90292<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;310-822-1511<br />
&nbsp;&nbsp;&nbsp;Fax:&nbsp;&nbsp;&nbsp;310-823-6714<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;Postel@ISI.EDU7.&nbsp;<br />
7．参考资料<br />
&nbsp;&nbsp;&nbsp;&nbsp;[1]&nbsp;Borenstein&nbsp;N.,&nbsp;and&nbsp;N.&nbsp;Freed,&nbsp;"MIME&nbsp;(Multipurpose&nbsp;Internet&nbsp;Mail<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Extensions)&nbsp;Part&nbsp;One:&nbsp;&nbsp;Mechanisms&nbsp;for&nbsp;Specifying&nbsp;and&nbsp;Describing<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;Format&nbsp;of&nbsp;Internet&nbsp;Message&nbsp;Bodies",&nbsp;RFC&nbsp;1521,&nbsp;Bellcore,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Innosoft,&nbsp;September&nbsp;1993.<br />
&nbsp;&nbsp;&nbsp;[2]&nbsp;Reynolds,&nbsp;J.,&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Assigned&nbsp;Numbers",&nbsp;STD&nbsp;2,&nbsp;RFC&nbsp;1340,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USC/Information&nbsp;Sciences&nbsp;Institute,&nbsp;July&nbsp;1992.<br />
&nbsp;&nbsp;&nbsp;[3]&nbsp;Postel,J.,&nbsp;"Instructions&nbsp;to&nbsp;RFC&nbsp;Authors",&nbsp;RFC&nbsp;1543,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USC/Information&nbsp;Sciences&nbsp;Institute,&nbsp;October&nbsp;1993.<br />
<br />
附录&nbsp;A&nbsp;IANA媒体类型注册过程<br />
MIME已经被设计为有扩展机制的，而且希望随着时间的增加，内容-类型/子类型对集<br />
合和他们对应的参数将不断增加。一些其它的MIME领域，显著特征集合，消息外部类型<br />
的存取-类型参数，和可能的内容-转换-编码值，都可能有新的定义值。<br />
总之，内容-类型头文件中的参数是用来向不同内容类型传递补充，而且当内容-类型和<br />
子类型定义好时，它们的用途也就被定义了。新参数不应当被定义作介绍新功能的一个方法。<br />
为了便于内容-类型和子类型（媒体类型）的旨在一种有序的，规格的，公开的状态下发展，<br />
MIME和其它应用对本RFC中定义的媒体类型应用注册过程，它是以IANA作为这些数据<br />
的中心注册处。<br />
为了简化和标准化媒体注册过程，本附录给出向IANA新值注册的模板。每个是以邮件<br />
消息模板形式给定，在注册是添入。<br />
新内容-类型/子类型值的注册：<br />
注意总体上期望MIME由子类型来扩展，如果需要一个新的基础高-水平类型，他的规<br />
格必须公开为一个RFC或者是以一个RFC适当形式提高，而且它是属于因特网标准过程。<br />
RFC1590——Media&nbsp;Type&nbsp;Registration&nbsp;Procedure&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;多媒体类型注册过程<br />
1<br />
<br />
5<br />
ＲＦＣ文档中文翻译计划<br />