Comment 10 for bug 612111

Arik writes:

> Hi Uday,
>
> I don't read the rfc the same way. I see that the boundary line is
> proceeded by a "body part" (no mention of required new line) which is
> in turn a message.

The part we are concerned with section 5.1:

    After its boundary delimiter line, each body part then consists of
    a header area, a blank line, and a body area. Thus a body part is
    similar to an <RFC 822 message> in syntax, but different in meaning.

"body part" here is each part of a multipart. Note the three
components of the body part. "header area" and "body area" could
possibly be empty, but not the "blank line".

The reference to "RFC 822 message" is unfortunate. It is being used
as an analogy for the whole "body part". Since the "body area" could
in turn be a real RFC 822 message, this can be confusing. So, I have
put the RFC 822 message in angle brackets. You can complete ignore
what is inside the angle brackets. It doesn't affect anything.

    A body part is an entity and hence is NOT to be interpreted as
    actually being an <RFC 822 message>. To begin with, NO header fields
    are actually required in body parts. A body part that starts with
    a blank line, therefore, is allowed and is a body part for which
    all default values are to be assumed. In such a case, the absence
    of a Content-Type header usually indicates that the corresponding
    body has a content-type of "text/plain; charset=US-ASCII".

> This message can have headers but it is permitted not to as well,
> but I don't read it as having two sets of headers (MIME and message
> headers). It says a body part that starts with a blank line is
> allowed but it looks to me like this should then be interpreted as
> having all default values [for header values].

Note that this stuff is written at the beginning of 5.1, describing
all kinds of multiparts, not only 'multipart/message' things. For
instance, it could be multipart/alternative where the "body parts" are
text/plain or text/html or whatever else. So, there need be no
messages here. They are *like* messages in that they have a header
area, blank line and body area.

In our case, the body area is an actual message. So, it will have its
own message headers, blank line and message body.

Hope that clarifies the confusion.

What the VM parser would do is

- skip the beginning boundary line
- parse all lines until a blank line as MIME headers of a part
- skip the blank line
- parse all the stuff till the next boundary as the body of the part.

And, then if the "body" is a message, display it as a message (for
which a separate message header and message body are needed).

Cheers,
Uday