On Mon, 14 Nov 1994, Ed Levinson wrote:
Getting the user agent to blat it on the screen sounds like saying
a default is needed for application/{a b c ...].
There is a default for application/*. If the MIME mailer does not know
what to do with the subtype (e.g. hand it off to another program), it
should at least provide the ability for the user to save the data into a
file after removing the transfer encoding. That was in the MIME spec
last time I looked.
Not tenable. But
using text/{a b c ...} forces the recipient to look at it, maybe we
That was the whole point. We wanted to encourage experimentation with
other subtypes of text/* for different kinds of markup for ordinary e-mail
messages. It is highly annoying to users if their mailer tells them "I
don't know what this is. Shall I save it?" for text body parts that are
critical to the message's contents. Hence the "blat to the screen" rule.
In hindsight, the users find the markup annoying anyway, but I think you'd
find that they'd prefer to see the markup than nothing at all.
Kludge proposal: text/char-stream; application=hwatever. Gives
recipeint the choice and one can identify the application. Perhaps
MIME readers could be smart enough to shift between text/char-stream
and application/hwatever. So cute it's ugly ;-), but I couldn't
resist saying it.
No, no, no. There seems to be a misunderstanding. text/* was never
intended for everything that can be represented in ASCII (or any other
charset for that matter). Millions of things can. The real test (IMHO)
is: does the subtype contain information that a user would find useful
directly without processing, or does the subtype contain information that
must be processed further to make it useful?
Some examples: Safe-TCL scripts are written in ASCII, but few users would
find them useful when viewed directly. They only become useful for humans
once passed through a Safe-TCL interpreter. Hence, application/* is the
best place for them, even though they are readable in theory. On the
other hand, personal contact information (PCI) giving name, address, phone
number, etc, and written in ASCII is useful to a user whether or not it is
processed by a PCI-aware application. Hence, text/* is the best place for
that. (There was a draft for PCI floating around some time ago which used
a tagged text format called STIF. Go look it up if you're interested).
Now, there is a question of what to do with newlines in textual things
that are sent under application/*, but I don't really see what the hassle
is. 7bit/8bit/quoted-printable take care of canonicalisation implicitly
and are the encodings most likely to be used for sending textual data.
For base64/binary, choose something (probably CRLF) and document it in the
registration with IANA.
HTML is useful without further processing. RTF is not.
Cheers,
Rhys.