Mark - I am against changing things which aren't broken. Outside of one
or two typos in the spec, the only thing that is broken are a couple of
early implementations. I would rather fix the broken implementations
than penalize correct implementations.
Marshall,
For whatever it is worth, I think there is a distinction to be made
here. With regard to the tspecials and period, my sense is that many
years of experience has taught us that lots of people have trouble
getting quoting right and, hence, if we can design things in a way that
minimizes the need for quoting, we will have something that is much more
robust. I think designing for robustness and in a way that makes it
easier for lazy and careless people to get something right is A Good
Thing. And, at least to the degree to which I understand the
procedures, the purpose of a proposed standard is to give us an
opportunity to look at things in the light of implementations and then
get it right; if we are going to say "well, it went out that way and
therefore we are stuck with it for all time" we are, to put this in a
deliberately offensive way, not much better off than the ISO folks.
Ultimately, I think this has a lot to do with robustness and ease of
building conforming implementations and nothing to do with figuring out
whether the spec or the present implementations are more broken.
That said, I find it very hard to get worked up about the tspecials
issue. It is, at worst, a small irritation that takes only a tad of
extra effort to get right, no matter how we ultimately define "right".
And the next version of the MIME RFC should probably get a tutorial note
or two explicitly pointing out the implementation implications of
whatever plan is chosen.
The requirement about two leading blank lines is another matter
entirely. One of the quite explicit goals of the MIME effort was to
avoid breaking, or putting new requirements on, MTAs, even MTAs that
were, if not actually broken, a little on the shakey side. I think
we've got a decade of experience with a lot of mail transport and
queuing and delivery software that appears to be working today. That
experience says that, regardless of what one learns from a narrow and
careful reading of RFC-821 and 822, anything that is going to deal with
message formats ought to assume that the 822 structure consists of
--822 header structure--
--blank line denoting end-of-headers--
--zero or more additional blank lines--
--message body in practice--
--zero or more surplus blank lines--
That is today's transport environment in practice. All MIME ought to
be doing is adding or changing the 822 header structure and then the
*trimmed* message body in practice. Writing rules so that a bunch of
extra blank lines at the top don't get construed as a preface (or
whatever we are calling it this week) is a good thing; writing rules so
that the presence or absence of spare ones at the end don't cause
problems is an equally good thing.
The problems arise because some of those transport and/or delivery
systems split headers from bodies (deleting the delimiting blank line
entirely) and then recombine them (adding a delimiting blank line) if
necessary. That is a process in which leading or trailing blank lines
in or around the actual message body get lost very easily. This problem
is one of several reasons we've kept rejecting the use of line counts
for various purposes.
If MIME does something that results in our having to get hyper-picky
about exactly how many CRLF pairs can/must appear between the 822 header
structure and the first body part delimiter, or between the end of the
last body part delimiter and the physical end of message, we are almost
certainly to end up in broken environments because our transport and
delivery mechanisms don't "know" that this is important. If we have to
declare them broken and go "fix" them, we have lost the battle to make
MIME a user- and user-agent-only approach.
And I'm a lot more concerned about that principle and those (often
elderly) transport and delivery implementations than I am about the fine
details of a few recent implementations of a *proposed* standard.
john