ietf-822
[Top] [All Lists]

Re: Re: Character-set header (was Re: Minutes of the Atlanta 822ext meeting)

1991-09-10 11:02:03

------------------------------ 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

<Prev in Thread] Current Thread [Next in Thread>