Excerpts from internet.ietf-822: 10-Sep-91 Re: Character-set header (w..
Greg Vaudreuil(_at_)nri(_dot_)resto (4049)
BINARY: Is not intended to be displayed in any fashion to the user.
This is use for program code, directory dumps, and other data
which is not explicitly input to a program but rather to be
used in its native form. The most rational thing to do with
this information is to write it to a file at the users request.
APPLICATION: This is information which must be processed by an
application before it is viewable or usable to a user. It is
explicitly revisable. This implies nothing about the nature
of the user display to be used.
I think this is a clearer explanation than any of my previous attempts,
and I applaud it! However, I think it misses slightly on one important
score: clarifying the importance of the intent of the sender. The
intent of the sender is very different when he sends data that is
intended for mail-based display/interaction, and when he just sends raw
(binary) data to be written to a file. This differential intent was
always what I intended to capture by the binary/application split. If
the content-type is application, then the hope, at least, is that your
mail system will be hooked up to somethign that can handle it
on-the-fly. If the content-type is binary, that probably doesn't make
any sense, and might even be undesirable. So I'd like to take Greg's
prose and strengthen it somewhat with this explicit notion of intent.
From a functional standpoint, binary and application could easily be
merged. There's no need to keep them distinct unless some information
is conveyed by doing so. I believe that this is the case. Imagine you
get two messages, with types application/foo and binary/bar. Your mail
reader can't handle either one. In the case of binary/bar, however, you
know that no upgrade to your mail system is plausible, because it's just
non-mail-oriented binary data anyway. In the case of application/foo,
you might think about enhancing your mail reader to understand it. In
other words, it makes sense to think of something happening
automatically for application, but not for binary. Does that make sense?
Excerpts from internet.ietf-822: 10-Sep-91 Re: Character-set header (w..
John C Klensin(_at_)infoods(_dot_)m (2245)
I'm quite uncertain about your binary/application distinction and don't
think it holds up in practice. One could, for example, argue that
machine code is as much decompiler fodder as source codes (which we
would presumably identify as "text-plus", right?) are compiler-fodder.
I'd prefer to make the distinction at least partly in terms of
"processability" -- the "application" type is intended as processable in
the sense that it can be parsed, modified, edited, etc. The binary
isn't. In this sense, it's like the difference between compiled &
interpreted code. Is this a fuzzy difference? Slightly, yes. As John
points out, you can decompile things, too. That's why I'm most
interested in emphasizing the intent of the sender rather than the
format of the data. -- Nathaniel