由于每个广域文件系统都会产生新的可能性,因此预先知道某个文件从这个文件系统可以
或不可以直接访问的机器集是非常困难的.所以提供直接使用的文件名和一个或多个这个文
件可以被访问的位置是有意义的.某个操作可能会试着通过FTP或其他协议,使用匿名或提示
用户输入必要的密码来获取远程文件.如果一个外部主体可以通过多重机制被访问,那么发送
者可以在一个封装的"multipart/alternative"实体的主体内包含多个"message/external-body"实
体主体.
然而,正如mail-server(邮件服务器)访问类型所表明的那样,external-body机制的目的不是用
来限制文件的获取.除此之外,我们可以想象,例如通过一个视频服务器获取视频片断的外部
引用.
由于外部主体没有报头字段用来声明它的类型,所以如果它是除无格式US-ASCII文本之
外的其他格式的话,那么出现在"message/external-body"数据主体中内含的报文字段必须用来
声明外部主体的媒体类型.类似的,除了"7bit"之外的任何Content-transge-encoding(内容传送
编码)也必须在此声明.因此,对于附言格式中涉及的对象,完整的"message/external-body(报文/
外部主体)"报文应该与下面类似:
From:Whomever
To:Someone
Date:Whenever
Subject:whatever
MIME-Version:1.0
Message-ID:<id1@host.com>
Content-Type:multipart/alternative;boundary=42
Content-ID:<id001@guppylake.bellcore.com>
ontent-Type:message/external-body;name="BodyFormats.ps";
site="thumper.bellcore.com";mode="image";
access-type=ANON-FTP;directory="pub";
expiration="Fri,14Jun199119:13:14-0400(EDT)"
Content-type:application/postscript
Content-ID:<id42@guppylake.bellcore.com>
Content-Type:message/external-body;access-type=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
expiration="Fri,14Jun199119:13:14-0400(EDT)"
Content-type:application/postscript
Content-ID:<id42@guppylake.bellcore.com>
Content-Type:message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri,14Jun199119:13:14-0400(EDT)"
Content-type:application/postscript
Content-ID:<id42@guppylake.bellcore.com>
getRFC-MIME.DOC
注意上面的例子,"7bit"的缺省Content-transfer-encoding(内容传送编码)是假定用于外部附
言数据的.
与"message/partial"类型相似,"message/external-body(报文/外部主体)"媒体类型是透明的,也
就是在外部主体中传送数据,而不是那个类型的主体和数据一起传送.因此,对于
"message/partial",外面和里面部分的报头必须按照同一规则合并.特别的,这意味着
Content-type(内容类型)和Subject(主题)字段可以不用保护,但From字段必须得到保护.
注意,由于外部主体不和外部主体的引用一起传送,所以他们必不需要遵循应用于引用本身
的传送限制.特别的,Internet邮件传送可能会附加上7bit和行长度限制,但这些不会自动作用
在二进制外部主体引用上.因此一般来说,Content-Transfer-Encoding(内容传送编码)并不是必
须的,尽管这是允许的.
注意,"message/external-body(报文/外部主体)"类型的报文主体遵循RFC822报文的基本语
法.特别的,任何出现在第一对连续的CRLFs之前的都是报头信息,而之后的都是主体信息,这
对于绝大多数访问类型来说都是被忽视的.
5.2.4其他message(报文)子类型
一般来说,MIME的实现必须将未得到承认得"message"子类型当作和
"application/octet-stream"相等效.
未来试图与电子邮件一同使用的"message"子类型将被限制采用"7bit"编码.除了"message"
类型之外,某个如果不可能被限于采用"7bit"编码的类型也是可以使用的.
6.实验的媒体类型值
为了被通过相互协商得到同意的系统使用,以字符"X-"开头的媒体类型值是一个私有值.
任何没有得到严格和公开定义的格式必须以'X-"作为前缀来命名,公开详细说明的值将不能
以"X-"作为开头使用.(在Andrew系统中广泛使用的较老版本采用"X-BE2"名,所以新的系统
可能选择采用不同的名字)
大体上来说,"X-"顶层类型的使用效果非常不好.不管何时,只要有可能,实现者应该发明已
存在类型的子类型.在很多情况下,一个"application"的子类型将比一个新的顶层类型更合适.
7.总结
这五个离散的媒体类型为标签实体如"audio","image"和其他各种数据提供了一个标准化
的机制."multipart"和"message"的复合媒体类型允许在一个单一的报文中出现不同类型实体
的混合和分等级结构.一个出色的参数语法允许数据格式细节的更深入说明,特别是交替的字
符集的详细说明.附加的可选报头字段为特定的扩充提供各种机制,这些扩充被许多实现者承
认是值得的.最后,一定数量的有用的媒体类型将通过承认用户代理为一般性使用提供定义,
特别如""message/partial"和"message/external-body".
8.安全性考虑
安全问题在"application/postscript"类型,"message/external-body"类型,和RFC2048的上
下文中讨论.实现者应特别注意任何媒体类型的安全性暗示,这些媒体类型会导致在接收者环
境中任何操作的执行.在这种情况下,对"application/postscript"类型的讨论可能会被当作一种
考虑其他媒体类型和远程执行能力的模型.
9.作者地址
需要更多的信息,可以通过以下的因特网邮件联系该文挡的作者：
NedFreed
InnosoftInternational,Inc.
1050EastGarveyAvenueSouth
WestCovina,CA91790
USA
电话:+18189193600
传真:+18189193614
EMail:ned@innosoft.com
NathanielS.Borenstein
FirstVirtualHoldings
25WashingtonAvenue
Morristown,NJ07960
USA
电话:+12015408967
传真:+12019933032
EMail:nsb@nsb.fv.com
多用途互联网邮件扩展协议是因特网工程任务工作小组对扩展RFC822工作的成果.你可
以通过以下方式联系该小组主席GregVaudreuil:
GregoryM.Vaudreuil
OctelNetworkServices
17080DallasParkway
Dallas,TX75248-1905
USA
EMail:Greg.Vaudreuil@Octel.Com
附录A：语法集
附录包含了本文档详细说明的所有语法地完整BNF语法。
然而，这个语法是不完整的。它通过名字和RFC822中定义的多个语法规则相关联。
为了不在此重复这些定义和冒造成两者之间无心的差异的危险，本文档只是给读者简单的涉
及RFC822中其余的定义。碰到未定义的术语，可查阅RFC822中的定义。
boundary:=0*69<bchars>bcharsnospace
bchars:=bcharsnospace/""
bcharsnospace:=DIGIT/ALPHA/"'"/"("/")"/
"+"/"_"/","/"-"/"."/
"/"/":"/"="/"?"
body-part:=<"message"asdefinedinRFC822,withall
headerfieldsoptional,notstartingwiththe
specifieddash-boundary,andwiththe
delimiternotoccurringanywhereinthe
bodypart.Notethatthesemanticsofa
partdifferfromthesemanticsofamessage,
asdescribedinthetext.>
close-delimiter:=delimiter"--"
dash-boundary:="--"boundary
;boundarytakenfromthevalueof
;boundaryparameterofthe
;Content-Typefield.
delimiter:=CRLFdash-boundary
discard-text:=*(*textCRLF)
;Maybeignoredordiscarded.
encapsulation:=delimitertransport-padding
CRLFbody-part
epilogue:=discard-text
multipart-body:=[preambleCRLF]
dash-boundarytransport-paddingCRLF
body-part*encapsulation
close-delimitertransport-padding
[CRLFepilogue]
preamble:=discard-text
transport-padding:=*LWSP-char
；创建者绝对不能产生非零长度的transport-padding，
；但接收方必须能够处理由报文传输添加的padding。