Running code is a good way to test theory.
In my opinion, you can't even write this kind of code until you know
exactly (i.e. formally) what it's supposed to do -- specifically, what
every given sequence of octets means.
It's a chicken-and-egg problem. You can't write the code until know
what it's supposed to do, but for something like this (where implementors'
mistakes defy explanation by logic or physical laws) you can't figure out
what the code needs to do until you guess at a solution and see how well
it works with the installed base.
The text/paragraph form
turned out not to interoperate, while format=flowed does.
But I'm right, aren't I? Text/paragraph fails to be handled correctly by
many existing UAs which don't like unrecognised text/*, but it's still
useful for many applications. I think there's room in the world for it no
matter what solutions anyone comes up with for mail and news.
Perhaps. But the people who designed text/paragraph were trying to
solve the mail/news problem. So to them it's a failure. Someone
else might find it useful in another environment (say the way),
but I doubt it, because HTML is more functional and already widely
deployed.
The root of my argument is that MIME is no longer just for the Internet
Mail of its acronym: it's becoming a general data-typing scheme. I don't
think proposed MIME types should be rejected just because they confuse
some existing mail UAs -- the obvious example here is text/html, which
can annoy mail recipients but works well over HTTP.
text/html is a good example of a type name that in hindsight many
of us wish had not used 'text' as a top-level content-type. The web
would have worked just as well had HTML been called application/html.
Email would have worked *much better*, because recipient's user
agents wouldn't insist on displaying application/html as if it were
text, and therefore nobody's UA would generate HTML in email by default
until the capability to display it were *very* widely deployed.
Keith