MIME RFC "Content-Type" parameter confusion? Unclear RFC specification -

I implement an original MIME parser for multipart / related in C ++ / Qt I am trying to

So far, I am writing some basic parser code for the header, and I am studying RFC so that it is possible to do everything for the specification as much as possible. Unfortunately, there is a part in RFC which confuses me a bit:

Section 3.1.1:

Each header field can be viewed as a single, logical line ASCII's character, which includes field-name and field-body. For convenience, the regional part of this conceptual unit can be divided into a multi-line representation; It is called "fold", the general rule is that wherever a line-white-space can be done (not only LWSP-Character), a CRLF can be inserted at least one LWSP-Charter immediately after that. Thus, a single line

is fine, so I parse only one header field and if the CRL is with the linear white space, then I can only specify one header line As a result of them, I stop them in a useful way. Let's proceed ...

Section 5.1:

In the enhanced BNF notation of RFC 822, a content-type header field value is defined as: / P>

  content: = "content-type" ":" type "/" subtype * (";" parameter); Matching media type and subtype; Always case-insensitive  

[...]

  parameter: = attribute "=" value attribute: = token; Matching properties; Always case-insensitive Value: = token / cited-string token: = 1 *  

OK It seems that if you want to specify a content-type header with parameters, just do this:

  Content type: multicast / related; Foo = bar; Some = and  

... and the combined version of the same title will look like this:

  Content-type: Multipart / related; Foo = bar; Something other  

is correct? good. As I had read RFC, I came to the following in Section 5.1 (examples):

  Content-type: Multipart / related; Boundary = example-1 = "& lt; 950120.aaCC@XIson.com>"; Type = "App / X-Fixed Records" Start-Inform = "- OS" - Example -1 Content-Type: App / X-Fixed Record Content-ID: & lt; 950120.aaCC@XIson.com> [Data] - example-1 content-type: application / octet-stream content-description: fixed length record content-transfer-encoding: base64 content-id: & lt; 950120.aaCB@XIson.com> [Data] --example-1--  

Hmm, that's weird. Do you see the content-type header? It has several parameters, but not all "in the form of parameter delimiter".

Perhaps I have not read RFC correctly, but if my parser works strictly as defined by specification , Then the result of the type and start-info parameter will be a single string or worse, parser error.

Friends, what do you think about this? Just a typo in RFC? Or did I miss something?

Blessed

This is a typo Example Parameters should be delimited correctly with semicolons, Although folded, the fold does not mean to change the words of the headers, only to allow for readability and to account for those systems which are line length restrictions.