------------------------------ Start of body part 1
First.. I to wasn't able to keep up with that e-mail explosion y'all
did last month. Geez, it was like debating how many bits can dance
on the end of a byte. Anyway..
Someone this morning talked about a potential problem with using MESSAGE
body parts and returning them through 7-bit only paths. Wouldn't a
MESSAGE body part (as opposed to the MESSAGE HEADER) be encodable? That
is, there is no need for an MTA to dig into a message to look for MESSAGE
body parts in the performance of its duties, so why would it hurt if
that body part got encoded?
------------------------------ Start of body part 2
As for the list posted by Greg Vaudreuil, I have a few comments..
I agree with these general statements 100%:
1) Top level content-type as an indicator of display required.
2) Top level content-type as an indicator of the transport encoding to
select either by the sending UA or by a gateway if conversion is
required.
----- Suggested text for content types --------------
..
TEXT PLUS: Requires a text oriented display only. Application software
may enhance the appearance of the text, but IS NOT REQUIRED to
gather the general idea of the message. The message is fully
revisable by a knowledgeable operator without use of an
application program.
(I understand this to include LaTeX, .nroff, and richtext,
This list should also include SGML, SCRIBE, texinfo, etc ..
MESSAGE: Implies nothing about the display. Contains a fully formated
822 conformant message which may contain any combination of
other content-types.
For an X.400 message, what to do? Should it be transmorgrified
into an 822 message? This may not be easy since that is an MTA function.
SubTyping may be useful here ..
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.
Yeah.. like some people have said .. this is a catchall for stuff which
doesn't fit. And like you say, for stuff which isn't likely to be
useful in an e-mail UA.
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.
(This is where I would put Word Perfect files, Framemaker
data {all forms}, and Lotus spreadsheets. If PostScript is
explicity revisable, it can go here, otherwise it is an IMAGE
form)
Well.. this isn't *quite* the interpretation or intention I was
having towards the use of this type. The sort of things I had
been intending to use APPLICATION for are:
-- Servers like info-server(_at_)sh(_dot_)cs(_dot_)net,
service(_at_)nic(_dot_)ddn(_dot_)mil,
listserv(_at_)bitnet-sites(_dot_) These are query/response things which
(to an extent) do not make sense in a fully connected network
like the existing Internet. On the other hand the Internet is
just an island in a larger see of slightly connected networks.
E-Mail is a convenient bridge which crosses the chasms between
the islands.
There are trends which cause these servers to exist in the
first place, and I don't see that these are going away.
-- FAX gateway with originator-specified formatting.
-- Containing information which is to be used by the displaying UA in
formatting the display of the message.
These two are nearly the same thing. That is, embedding formatting
information into the message. Y'know.. place my picture next to
the From: field, put up this banner over the top saying
InterGalactic Memorandum
etc.. whatever they want to put there...
-- System maintainence & Usenet like control messages. It might make it
easier to administer a building full of e-mail users if you knew which
mail readers (and more importantly, which version) each is using. So
you send out a message to "everybody" with
Content-Type: Application / Control / Send-Version
-- New user registration. You get a new employee in, show them their
desk & part of the familiarization process gets them set up with e-mail.
To do so they fill out a form & send it to a daemon which collects
these things & automagically verifies information and sets them up
with POP/IMAP/P7 service & etc.
-- Other sorts of transactions.. ordering supplies from Company Stores for
instance.
------------------------------ End of body part 2