There's a big difference in the way on-the-wire and local formats are used.
On-the-wire formats, as format=flowed is targeted to be, have to
interoperate really well with the installed base of applications that
communicate using it. In this case it is e-mail client software and
gateways. I posted a sample of text/paragraph to this mailing list some
months ago to find out how well it worked. It was clear that you could not
send this format in e-mail with impunity. Many mailers treated it as an
attachment and that's why it was withdrawn. Format=flowed doesn't have this
Local formats (or applications where you can negotiate format like HTTP),
are a little different. If you're looking for a type to use with some local
application of the MIME type scheme, then text/paragraph makes a lot more
sense. It allows you to label the format you have correctly. In my
implementaiton of format=flowed, the mail messages is actually stored in
text/paragraph while the user is editing it and while it remains a draft
message. It is converted to format=flowed upon sending because storing
format=flowed locally for outgoing messages makes no sense. (I don't have
to actually label it internally as text/paragraph since that's the only
form of text used).
So I don't think there's anything wrong with perusing and registering it
even as text/paragraph, but I would like to see text saying that it has
been found unsuitable for on-the-wire e-mail use and suggest format=flowed
In general, using MIME typing for lots of other applications, internal
representations, etc seems like a good idea to me.
At 8:56 PM -0700 10/22/98, Ashley Yakeley wrote:
At 1998-10-22 19:55, Keith Moore wrote:
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.
Well this may explain the withdrawal, but I'd like to suggest
re-submitting it in some form... or perhaps there's some way it can be
registered without being an RFC, perhaps as 'text/vnd.paragraph'.
else might find it useful in another environment (say the way),
but I doubt it, because HTML is more functional and already widely
Text/paragraph as such is already very widely used, and very useful, but
by necessity it can only be inaccurately labelled 'text/plain' by systems
using MIME to type data, such as Java's data-transfer mechanism and some
HTML may be more functional, but obviously it's rather unwieldy for many
applications which need nothing more than plain text.
Ashley Yakeley, Seattle WA