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.
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.
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. 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.
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.
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.
4) discard-text incorrectly requires a terminating CRLF to any text.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up