I'd like to get some particular clarification wording in the multipart
section of the next MIME spec, namely:
1) A parsing robustness hint. Something like:
An error parsing an enclosed body-part should not cause a reader to
incorrectly parse the enclosing multipart. Since the specified
delimiter is not permitted to occur in a body-part, its occurence
in the input stream will always indicate the end of that body-part.
I have already addressed this issue -- you will see the change in the next
draft that comes out, which is currently under internal review.
2) Cleanup resulting from the fencepost change to delimiters between
1341 and 1521:
NOTE: The CRLF preceding the encapsulation line is conceptually
attached to the boundary so that it is possible to have a part
Per the new grammar, the CRLF is preceeding the boundary and belongs
to the encapsultion, not to the boundary.
We're caught between a rock and a hard place on this one, I'm afraid. While it
is true that the CRLF belongs to the boundary marker and not to the preceeding
part, actually binding it this way in the BNF leads to the old problem where
the first boundary marker's CRLF is separate from the CRLF that comes after the
message header, and then we're back to the problem where two CRLFs are required
at the beginning of the multipart object by the grammar.
I've toyed with the idea of making the first boundary special. The best I've
been able to come up with is:
dash-boundary := "--" boundary
; boundary taken from Content-Type
; field. There must be no LWSP
; between these elements.
multipart-body := preamble dash-boundary CRLF
body-part *encapsulation
close-delimiter epilogue
; No LWSP around dash-boundary.
encapsulation := delimiter body-part
delimiter := CRLF dash-boundary CRLF
; No LWSP around dash-boundary.
close-delimiter := CRLF dash-boundary "--" CRLF
; Again, LWSP around
; dash-boundary or "--".
preamble := discard-text
epilogue := discard-text
discard-text := *text *(*text CRLF)
; To be ignored upon receipt.
body-part := <"message" as defined in RFC 822, with all
header fields optional, and with the
specified delimiter and close-delimiter
not occurring anywhere in the message body,
either on a line by itself or as a substring
anywhere. Note that the semantics of a part
differ from the semantics of a message, as
described in the text.>
I think this is enough of an improvement that I'm using it for now, but
it is a close call.
The grammar for the body-part nonterminal prohibits the delimiter from
occuring anywhere in the message body, but it does not prohibit a
close-delimiter from occuring anywhere in the body-part.
Good point. I've fixed this.
If a
delimiter is allowed to have an arbitrary amount of whitespace between
the boundary and the CRLF, then a parser must have an arbitrary amount
of lookahead in order to determine whether a line is a delimiter or
not.
It isn't allowed to have this. I hope this is clearer now.
3) The grammar is very sloppy w.r.t. where whitespace is allowed.
Since this is not a grammar for a structured field body, one can
hopefully assume that free insertion of linear-white-space is not
allowed. The grammar has comments prohibiting "space" between and/or
around some "--" tokens, but there is nothing in the grammar
permitting whitespace to be there in the first place.
Well, this is part of the price you pay for using ABNF, I'm afraid. I've
changed things to refer to LWSP instead of spaces, but aside from calling
attention to the places where LWSP is not allowed that's about all I can do.
The delimiter and close-delimiter nonterminals should explicitly list
where whitespace is allowed. There should probably be a comment
prohibiting composers from generating this whitespace.
See above.
4) discard-text incorrectly requires a terminating CRLF to any text.
Agreed and fixed.
Ned