ietf-smtp
[Top] [All Lists]

Re: RFC2046 question/problem

2001-09-28 01:44:10

On Thu, 27 Sep 2001 ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

Strictly speaking the ietf-822 list is where this should be discussed.

Thanks. Sorry for being off-topic.

The problem I see is that the CRLF line separating the header from the
body is trying to do double duty. RFC(2)822 claims this line as the
separator between the headers and body.

Actually, RFC 1521 said that two CRLFs were needed if no preamble was
present. This was discussed at length and very explicitly changed in
RFC 2046 so that only a single CRLF was required. Some examples were
also changed to make it clear that this usage is legal.

Sorry to bring up something which has been wrangled over in depth before.

By my reading, RFC2046 (top of page 20) claims this line as part of the
MIME boundary - i.e. part of the body: "The boundary delimiter MUST occur
at the beginning of a line, i.e., following a CRLF, and the initial CRLF
is considered to be attached to the boundary delimiter line rather than
part of the preceding part."

Um, so what? This is talking about the case where a boundary is
preceeded by a part. It isn't talking about the case where there's a
preceeding header.

OK. I misinterpreted the "rather than part of the preceding part." clause.

I didn't appreciate that that was supposed to exclude the case where the
boundary line was preceded by a preamble. (I took the word 'part' in its
general sense rather than in the sense of "only meaning a body part").

Nothing else I can see in the prose seems to point to the lack of CRLF on
the initial boundary.

I suppose a wording change where the last sentence is more clearly
qualified is in order, but regardless, your intepretation stretches
the words that are there well past the breaking point.

Additionally, the ABNF matches the single-CRLF interpretation. If no
preamble is present the a multipart-body begins with the boundary,
right after the CRLF that terminates the header.

Ah, thanks yes. The ABNF is clear on this.

So - it seems that messages formatted like the above (which include the
example in RFC2046) are not compliant with RFC2046 since the body lacks
the leading CRLF for the boundary.

Nope. That't not what the prose says, nor is it what the ABNF says,
nor is it what the examples show,h nor is it what MIME interpretations
support or create in practice.

I agree on all points, with an "agree to differ" on the prose, as
mentioned above.

I'll change the prose to make the intention more clear in the next revision.

Thanks very much for your quick and helpful response. It has cleared up my
understanding significantly. I'll try and read more carefully in future.

regards,

jb


<Prev in Thread] Current Thread [Next in Thread>