mime-rfc“content-type”参数混淆?不清楚的RFC规范

我正在尝试为 multipart/related 在C++/QT中。

到目前为止,我已经为头部编写了一些基本的解析器代码,我正在阅读RFC以了解如何尽可能接近规范地完成所有工作。不幸的是,RFC中有一部分让我有点困惑:

从 RFC882 第3.1.1节:

每个标题字段都可以被看作是 由字段名和字段体组成的ASCII字符。 为了方便起见,这个概念的领域主体部分 实体可以拆分为多行表示;这 被称为“折叠”。一般规则是无论在哪里 可以是线性空白(不只是LWSP字符),CRLF 后面紧跟至少一个lwsp char 插入的。因此,单线

好的,所以我简单地分析一个头字段,如果一个CRLF后面跟着线性空白,我简单地用一种有用的方式来连接这些字段,以得到一个头行。我们继续……

从 RFC2045 第5.1节:

在RFC822的增广的BNF表示法中,一个内容类型的头字段 值定义如下:

 content := "Content-Type" ":" type "/" subtype
            *(";" parameter)
            ; Matching of media type and subtype
            ; is ALWAYS case-insensitive.

[…]

 parameter := attribute "=" value

 attribute := token
              ; Matching of attributes
              ; is ALWAYS case-insensitive.

 value := token / quoted-string

 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

可以。因此,如果您想指定 Content-Type 带有参数的头,只需这样做:

Content-Type: multipart/related; foo=bar; something=else

…相同标题的折叠版本如下:

Content-Type: multipart/related;
    foo=bar;
    something=else

对的?很好。当我不断阅读RFC时,我在 RFC2387 第5.1节(示例):

 Content-Type: Multipart/Related; boundary=example-1
         start="<950120.aaCC@XIson.com>";
         type="Application/X-FixedRecord"
         start-info="-o ps"

 --example-1
 Content-Type: Application/X-FixedRecord
 Content-ID: <950120.aaCC@XIson.com>

 [data]
 --example-1
 Content-Type: Application/octet-stream
 Content-Description: The fixed length records
 Content-Transfer-Encoding: base64
 Content-ID: <950120.aaCB@XIson.com>

 [data]

 --example-1--

嗯,这很奇怪。你看到了吗? 内容类型 页眉?它有许多参数,但并非所有参数都有一个“;”作为参数分隔符。

也许我只是没有正确地阅读RFC,但是如果我的解析器严格按照规范定义工作,那么 type 和 start-info 参数将导致单个字符串,或者更糟的是,分析器错误。

伙计们,你们对此有何看法?只是在RFC中的一个打字错误?还是我错过了什么?

谢谢!