5. 1. 5 Digest子类型
这个文档定义了multipart内容类型的digest子类型。这个类型在语句构成上跟
"multipart/mixed"是一致的，但语义是不同的。尤其是，在摘要中，主体部分缺省的内容类
型值是在"text/plain"和"message/rfc822"之间变化的。这样做就允许了易读的摘要格式，它对
RFC934的兼容性非常的好（除了引用文惯例）。
注意：虽然在不同于"message/rfc822"的摘要的主体部分指定一个内容类型值是可行的，
比如一个"text/plain"部分包含了摘要内容的描述，事实上这样做是不可行的。
"multipart/digest"内容类型是用来发送报文集的。如果需要"text/plain"部分，它将作为
"multipart/mixed"报文的单独的部分包括进来。
这种格式的摘要看起来如下：
From: Moderator-Address
To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="---- main boundary ----"
------ main boundary ----
...Introductory text or table of contents...
------ main boundary ----
Content-Type: multipart/digest;
boundary="---- next message ----"
------ next message ----
From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion
...body goes here ...
------ next message ----
From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion
... another body goes here ...
------ next message ------
------ main boundary ------
5. 1. 6. Parallel 子类型
这个文档定义了"multipart"内容类型的"parallel"子类型。这种类型在句法上与
"multipart/mixed"是一致的，但是语义是不同的。特别的，在一个并行实体中，主体部分的
顺序并不是非常重要的。
这种类型的一个普通的介绍就是把各部分同时在可能的软硬件上显示出来。然而，组织
代理会意识到许多邮件读者不具备这种能力，无论如何都会顺序地显示各部分。
5. 1. 7其他的Multipart子类型
其他的Multipart子类型将会出现。MIME的实现通常必定把无法被识别的multipart子
类型等同地视为"multipart/mixed"。
5. 2. 报文媒体类型
在发送邮件时，通常希望封装在另一个邮件报文中。一种特殊的媒体类型"message"就
是被定义来实现这个功能的。特别的是，"message"（报文）的"rfc822"子类型就是用来封装
RFC822报文。
注意：报文的子类型或许被定义来接受或丢弃报文。然而，接受或丢弃的报文可以被当
成多部分报文来处理，其中第一部分包含了所有的控制和描述信息，第二部分
"message/rfc822"类型是被接受或丢弃报文。在这种方式下，组和起来的接受或丢弃的报文
将会保留在原始报文中的类型信息，允许它正确地递交给接受方，因此它是被倡导的。
报文的子类型常常在在允许编码的地方加上限制。这些限制的描述和每一种特定的子类
型都是关联的。
邮件网关、中继和其它的邮件处理代理通常是改变RFC 822报文的顶层（top-level）报
头。特别是，他们频繁地增加、删除、追加头文件字段。这些操作对封装的即内含在message
类型的报文主体内的报头来说是明确禁止的。
5. 2. 1 RFC 822子类型
"message/rfc822"的媒体类型指出：主体按照RFC 822报文的句法包含了封装的报文。
然而，不象顶层的RFC 822报文，这些限制（也就是说每个"message/rfc822"主体必须包含
一个"From", "Date"和至少一个目的头文件）被删除了，以这样的要求来替代：也就是说必
须出现"From", "Subject", 或 "Date" 中的一个。
应当注意到：尽管使用了数字"822"，但是"message/rfc822"实体并不严格限于与RFC 822
完全一致。"message/rfc822"对象的语义也不必限定于RFC 822中定义的语意。更明确的是，
"message/rfc822"报文可以是消息条款或一种MIME报文。
除了"7bit"、"8bit"或"binary"外，其它的编码对"message/rfc822"实体的主体来说都是不
允许的。报头字段在任何情况下都是US-ASCII，主体内的数据仍可编码，在这种情况下，
处在封装的报文内的Content-Transfer-Encoding（内容传送编码）的报头字段将会反映这一
点。在封装的报文头的Non-US-ASCII text可以指定为使用RFC 2047中描述的机制。
5. 2. 2 Partial子类型
"partial"子类型是用来把大的邮件分成几个独立的片段进行传送，然后由接受方的用
户代理自动地组装。（这思想与IP分组后用基本的IP协议组装相似。）当中间传输代理限制
了单个可传送报文的大小时就可使用这种机制。媒体类型"message/partial"就这样指出，主体
包含了一个大的邮件的片段。
因为"message"类型的数据从不会用base64或quoted-printable（加引号的可打印）类型
编码，若"message/partial"邮件在支持binary或8bit传输的环境中构建，那就会出现问题。
这问题就是binary数据将会被分成多部分的"message/partial"报文，每一部分要求二进制传
输。若这些报文在网关遇到了7bit的传输环境，除了等待所有的片段组装成内部的报文，
然后把组装的数据以base64或quoted-printable类型编码，没有合适的方法进行7bit的编码。
虽然不同的分组可以经由不同的网关，但是这仍然是不可接受的解决办法。因此规定了
"message/partial"类型邮件必须有7bit（默认）的内容传输编码。特别的，即使在支持binary
或者8bit传输的环境中，使用8bit或binary的内容传输编码对"message/partial"类型的MIME
邮件来说是明确禁止的。这也就反过来意味着内部的报文决不能使用8bit或binary编码。
因为一些报文传输代理选择自动地把大的报文分段，并且因为这些代理使用不同的分
段极限，所以部分的报文片段在重新组装以后，可以看出他们是由部分的报文组成的，这是
明确允许的。
在"message/partial"类型的内容类型字段必须规定三个参数：首先是ID，这是一个唯一
的标志符，是使用来匹配所有的分段。（通常，标志符必须是一个message-id；如果放在双
引号中，它可以是任何的message-id,与RFC 2045中给出的BNF参数是一致的。其次是
number,一个整形，是分段号，它指示了每个分段的次序。最后是total，另一个整形，是分
段的总数。在最后一个分段上必须由这个字段，在之前的分段上它是可选的（虽然最好写上）。
同样注意：这些参数的顺序是任意的。
这样，三部分报文的第二部分可以是下列报头字段的任一种：
Content-Type: Message/Partial; number=2; total=3;
id="[email protected]"
Content-Type: Message/Partial;
id="[email protected]";
number=2
但是第三部分必须指定总的分段数：
Content-Type: Message/Partial; number=3; total=3;
[email protected]
请注意：分段编号从1而非0开始。
当一个邮件以这种方式被分解成的片段组合在一起，结果总是一个完整的MIME邮件，
它可能有自己的内容类型报头字段，因此可能含有任何其它的数据类型。
5. 2. 2. 1报文分段和重组
重组分段报文的语义必须是"inner"报文的语义，而不是包含内部报文的报文语义。这就
使得以单独的分组报文发送一个大的audio报文成为可能，而且对接受方与其说是一个包含
一个audio报文的封装报文，不如说是一个简单的audio报文。那就是说，封装的报文是透
明的。
当产生和重组"message/partial"类型的报文片段时，被封装报文的报头必须与封装实体的
报头合并。在这个过程中必须遵守下列规则：
（1）分片代理必须只用边界线把报文分割。引入这条限制是因为在点上而非在行的末
尾进行分割，反过来依靠报文传输能够保留不以CRLF序列结束的报文语义。许多传输是不
能保留这种语义的。
（2）除了那些以"Content-"或特定的报头字段"Subject"、 "Message-ID"、
"Encrypted"、 "MIME-Version"开始的报头外，其它所有来自初始嵌套报文的报头字段都必
须按序复制到新的报文中去。
（3）以"Content-"加上 "Subject"、 "Message-ID"、 "Encrypted"和 "MIME-Version"字
段开始的嵌套报文头字段必须按序添加到新报文的报头字段。任何不以"Content-"开始的嵌
套报文头字段将被忽视或丢弃。（除了"Subject"、 "Message-ID"、 "Encrypted"和"MIME-
Version" 字段）
（4）第二或以后嵌套报文的所有报头字段都会被重组过程丢弃。
5. 2. 2. 2 分割和重组实例
如果一个audio报文被分割成两个部分，第一部分可以是这样：
X-Weird-Header-1: Foo
From: [email protected]
To: [email protected]
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 1 of 2)
Message-ID:
MIME-Version: 1.0
Content-type: message/partial; id="[email protected]";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID:
Subject: Audio mail
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here ...
第二部分可以是这样：
From: [email protected]
To: [email protected]
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
MIME-Version: 1.0
Message-ID:
Content-type: message/partial;
id="[email protected]"; number=2; total=2
... second half of encoded audio data goes here ...
然后，当分割的报文重组后，显示给用户的结果报文应该是这样：
X-Weird-Header-1: Foo
From: [email protected]
To: [email protected]
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail
Message-ID:
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here ...
... second half of encoded audio data goes here ...
分割报文第二和以后片段的报头中包括"References"字段，参考先前片段的Message-Id
对邮件读者理解和跟踪参照来说有益的。然而，象参考字段这样的字段是完全可以任意选择
的。
5. 2. 3 External-Body(外部主体)子类型
External-Body(外部主体)子类型表明实际体数据仅仅是被引用,而不被包含在内.既然这
样,参数就描述一种访问外部数据的机制.当一个MIME实体是 "message/external-body"类型,
它包括一个报头,两个连续的CRLFs,以及用于被压缩报文的报头.如果出现另一对连续
CRLFs,用于被压缩报文的报头就结束.然而由于被压缩的报文主体本身是外部的,它并不会
出现在随后的区域内.以如下报文为例:
Content-type: message/external-body;
access-type=local-file;
name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID:
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
称之为"影子主体(phantom body)"的结尾区域对大多数的外部主体报文来说是被忽略的.
然而,当访问类型是"mail-server(邮件-服务)"时,它用于包含某些辅助信息.
在文档中定义的使用影子主体(phantom body)的唯一访问类型是"mail-server(邮件-服务)",
但未来在其他规范中可能会定义另外一些使用这一区域的访问类型.
在所有"message/external-body(报文/外部主体类型)"实体中,这些被压缩的报头必须包含
一个Content-ID(内容ID)字段作为唯一标识用来引用数据.当访问类型是"mail-server(邮件-服
务)"时,这个标识被用于缓冲机制和数据接收的识别.
注:正如这儿所说明的,用于描述external-body(外部主体)数据的标记,例如文件名以及邮件
服务命令在US-ASII字符集中是必须的.
如果在实际应用中存在问题,那么可能就需要一种新的机制作为MIME的未来扩充,要么
为"message/external-body(报文/外部主体)"定义最新的访问类型,要么通过其他一些机制.
与"message/partial(报文/部分)"一样,类型"message/external- body(报文/外部主体)"的MIME
实体必须一个7bit(缺省)的
content-transfer-encoding(内容传送编码).特别的,对于"message/external- body(报文/外部主
体)"类型的实体来说,即使在支持binary(二进制)和8bit传输的环境中,binary(二进制)和8bit
的内容编码传送的使用也是被明确禁止的.
5. 2. 3. 1. 普通external-body(外部主体)参数
可以和任何"message/external-body(报文/外部主体)"一起使用的参数是:
(1)ACCESS-TYPE--表示被支持的访问机制的命令,通过它可以获取文件和数据.这个命令
不区分大小写.它的值包括但不限于"FTP", "ANON-FTP", "TFTP",
"LOCAL-FILE","MAIL-SERVER".
如RFC 2048中描述的,除以"X-"开头的测试值以外,其他值都必须到IANA注册.这个参数不
是无条件的命令,它必须出现在每个"message/external-body(报文/外部主体)"中.
(2)EXPIRATION--过了这个日期(在RFC822"date-time(日期-时间)中定义,RFC1123中得到
扩充,允许在年字段有4个数字)之后,外部数据的存在将得不到保证.这个参数可以和任何
access-type一起使用,并一直是可选的.
(3)SIZE --数据大小(八位字节).这个参数的目的是为了帮助接收方决定是否耗费必要的资
源取回外部数据.注意这儿,它描述了数据在标准形式下的大小,标准形式就是在任何
Content-Transfer-Encoding被应用之前,或者数据被解码之后.这个参数可以和任何access-type
一起使用,并一直是可选的.
(4)PERMISSION --一个不区分大小写的字段,它表明客户试图修改数据是否是可以的.默认
情况下,或者如果permission值"read",前提条件就是他们不允许"read",并且如果数据被重新得
到过一次,它就不在需要了.如果permission值是"read-write",那么前提条件就是无效的,并且
任何本地拷贝必须仅仅被看作一个高速缓冲器. "Read" 和 "Read-write"是唯一被定义的
permission值.这个参数可以和任何access-type一起使用,并一直是可选的.
这里定义的access-types精确语义将在下面各节中描述.
5. 2. 3. 2 'ftp' and 'tftp' Access-Types(访问类型)
FTP或者TFTP访问类型表明报文主体可以被作为分别使用 FTP [RFC-959] 或者 TFTP
[RFC- 783]的文件一样访问.对于这些访问类型来说,以下这些附加参数是强制需要的:
(1) NAME -- 包含实际主体数据的文件名.
(2) SITE --通过使用给定的协议,文件可以获取的机构.它必须是一个完整的经过资格认
证的域名,而不是一个随便取的绰号.
(3) 通过使用FTP,任何数据在被重新得到之前,用户通常被要求为通过site参数命名机构提
供登录id和密码.基于安全方面的原因,id和密码不被作为content-type(内容类型)指定,而必须
从用户那里获得.
另外,以下一些参数是可选的:
(1) DIRECTORY -- 通过NAME命名的数据可以被重新得到的目录.
(2) MODE --一个不区分大小写的字符串,它表明找回信息时要用到的模式.跟TFTP协议
[RFC-783]中所说明一样,对于"TFTP"访问类型来说有效的值是"NETASCII", "OCTET","
MAIL".
对于 "FTP" 访问类型来说有效的值是"ASCII", "EBCDIC", "IMAGE",和 "LOCALn",其中的
"n"是一个十进制整数,例如8.和FTP协议[RFC-959]中说明的一样,以"A" "E" "I" and "L n"代
表相应的类型.注意,对MODE参数来说,"BINARY" 和"TENEX"是无效,应该以"OCTET"或者
"IMAGE"或者 "LOCAL8"代替.如果MODE参数没有被详细说明, 对TFTP来说,其缺省值
为"NETASCII" ,其他协议的缺省值为"ASCII".
5. 2. 3. 3 'anon(匿名)-ftp'访问类型
除了指定位置不需要给出用户名和密码这一点以外,在其他方面,"anon-ftp"和"ftp"访问类
型都是一样的.可以替换的是,ftp协议可以用"anonymous"和相对应的用户邮件地址作为密码
登录.
5. 2. 3. 4 'local-file(本地文件)'访问类型
"local-file"访问类型表明实际主体可以像本地机器上的文件一样被访问.针对这一访问类
型,定义了两各附加参数:
(1) NAME --包含实际主体数据的文件名.这个参数对于"local-file"访问类型来说是不可
少的.
(2) SITE --已知有权访问数据文件的机器或机器集的指定域.这个选项参数用来描述数据
引用的本地位置, 在那里那些文件是可见的.星形将被用来作为匹配一部分域名的通配符,例
如"*.bellcore.com",它表明一组在其上数据直接可见的机器集,但单一的一个通配符将被用来
表示一个完全可用的文件,例如通过一个全局文件系统.
5. 2. 3. 5 'mail-server(邮件服务)'访问类型
'mail-server(邮件服务)'访问类型用于表示来自邮件服务器的实际主体是可用的.针对这一
访问类型,定义了两个附加参数:
(1) SERVER -- 从中可以获取实际主体数据的邮件服务器的指定地址.对于"mail-server"
访问类型来说,这个参数是不可少的.
(2) SUBJECT --用于获取数据的邮件所使用的主题.注意,不推荐在邮件服务器上键入主
题,但这些服务器是已知存在的.这个参数是可选的.
由于邮件服务器所接收的语法是各种各样的,有些是多行,所以发送到邮件服务器的整个命
令不会像content-type(类容类型)报头字段中的参数一样被包含在内.当媒体类型是
"message/external-body(报文/外部主体)"和访问类型是mail-server(邮件服务)时,将以"phantom
body(影子主体)"作为替代提供.
注意,MIME本身并不定义邮件服务器的语法.而是允许在影子主体(phantom body)包含任
意的邮件服务器命令.实现必须将影子主体(phantom body)包含在报文主体中,这个报文被发
送到邮件服务器以获取获取相关数据.
和其他访问类型不同,mail-server(邮件服务)是异步的,它的发生是不可预知的.基于这个原
因,拥有一种机制是非常重要的,通过它返回的数据能与最初的"message/external-body(报文/
外部主体)"实体相匹配.为了有利于匹配,MIME邮件服务器必须在返回报文和原先的
"message/external-body(报文/外部主体)"实体上使用相同的Content-ID(内容ID).
5. 2. 3. 6 External-body(外部主体)安全问题
"Message/external-body(报文/外部主体)"实体产生两个重要的安全问题:
(1) 通过Message/external-body(报文/外部主体)引用访问数据能使报文接收者有效的执行
一个报文创建者详细指定的操作.因此对于报文创建者,他可以欺骗报文接收者执行他们本不
愿做的某种操作.例如,使接收者在不知情的情况下违反安全策略,创建者可以指定一种操作,
试图获取某些未被接受者授权的信息.基于这一原因,有能力处理外部引用的用户代理必须描
述他们准备让接受者执行的操作,并在执行它之前,请求得到明确的允许.
'mail-server(邮件服务)'访问类型特别容易受到攻击,导致接受者发送一个内容由原先报文
发送者指定的新报文.在试图处理MIME "message/external-body(报文/外部主体)" 时,任何被
创建的请求报文都必须包含一个自动产生的明显标记.
(2)有时MIME会在提供某些报文完整性和真实性保证的环境中被使用.如果是在当前,这
种保证将只被用于报文的实际指示性内容-他们可能会也可能不会被应用到那些通过MIME
的"message/external-body(报文/外部主体)"机制访问的数据上.特别的,即使报文系统本身是安
全的,它也有可能破坏特定的访问机制.
值得注意的是,在MIME机制有效或无效这两者之一必定存在这个问题.和一个包含某个文
档的FTP位置的临时引用也会带来类似的问题,这个文档本身包含在一个加密报文的文本中
--唯一的不同是,MIME提供这类信息的自动获取,而用户可能会将未获得保证的信任放置在
这些自动获取机制中.
5. 2. 3. 7 实例与深入说明
当external-body(外部主体)机制被用于和"multipart/alternative"媒体类型相关联时, 他扩展
"mutipart/alternative"的功能以包含下面这种情形,就是相同的实体以相同的格式提供 但通过
不同的访问机制.这样做的话,报文的创建者必须首先按照先前的格式,再通过先前的访问机
制定制这些部分.接收者的浏览器将根据其格式和访问机制验证这个列表.
由于每个广域文件系统都会产生新的可能性,因此预先知道某个文件从这个文件系统可以
或不可以直接访问的机器集是非常困难的.所以提供直接使用的文件名和一个或多个这个文
件可以被访问的位置是有意义的.某个操作可能会试着通过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:
Content-Type: multipart/alternative; boundary=42
Content-ID:
ontent-Type: message/external-body; name="BodyFormats.ps";
site="thumper.bellcore.com"; mode="image";
access-type=ANON-FTP; directory="pub";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID:
Content-Type: message/external-body; access-type=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID:
Content-Type: message/external-body;
access-type=mail-server
server="[email protected]";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID:
get RFC-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" 类型, 和RFC 2048的上
下文中讨论.实现者应特别注意任何媒体类型的安全性暗示,这些媒体类型会导致在接收者环
境中任何操作的执行.在这种情况下,对"application/postscript"类型的讨论可能会被当作一种
考虑其他媒体类型和远程执行能力的模型.
9. 作者地址
需要更多的信息,可以通过以下的因特网邮件联系该文挡的作者：
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
电话: +1 818 919 3600
传真: +1 818 919 3614
EMail: [email protected]
Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA
电话: +1 201 540 8967
传真: +1 201 993 3032
EMail: [email protected]
多用途互联网邮件扩展协议是因特网工程任务工作小组对扩展RFC822工作的成果.你可
以通过以下方式联系该小组主席Greg Vaudreuil:
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
EMail: [email protected]
附录A：语法集
附录包含了本文档详细说明的所有语法地完整BNF语法。
然而，这个语法是不完整的。它通过名字和RFC822中定义的多个语法规则相关联。
为了不在此重复这些定义和冒造成两者之间无心的差异的危险，本文档只是给读者简单的涉
及RFC822中其余的定义。碰到未定义的术语，可查阅RFC822中的定义。
boundary := 0*69
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
body-part := <"message" as defined in RFC 822, with all
header fields optional, not starting with the
specified dash-boundary, and with the
delimiter not occurring anywhere in the
body part. Note that the semantics of a
part differ from the semantics of a message,
as described in the text.>
close-delimiter := delimiter "--"
dash-boundary := "--" boundary
; boundary taken from the value of
; boundary parameter of the
; Content-Type field.
delimiter := CRLF dash-boundary
discard-text := *(*text CRLF)
; May be ignored or discarded.
encapsulation := delimiter transport-padding
CRLF body-part
epilogue := discard-text
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
preamble := discard-text
transport-padding := *LWSP-char
；创建者绝对不能产生非零长度的transport-padding，
；但接收方必须能够处理由报文传输添加的padding。