ietf-822
[Top] [All Lists]

Compression, and nested encodings

1991-04-09 08:07:43

The question that remains, I think, is a simple one: how many
troublesome cases like Vincent's example will there really be, and how
important are they?

There is one more significant case we decided not to look at at St.
Louis for fear of getting a migraine.  Many people believe that
compression should be included in the message format.  I'm not sure
where the best place to put it is but both of the current headers are
good ideas.

Compression can be viewed as another level of encoding, which
is independent of the base encoding of a part.  This is a
tar|compress|uuencode case.  These are all ways of altering the data
representation and are not mutually exclusive.  I have heard people
suggest that this concept of nested encodings is a good thing.

Another way to view compression is as a separate data type.  This is:
        type: fax|compressed
        encoding: uuencode
This argues for nested content-type fields. This idea stems from
Nathaniels question about other strange encoding cases.  I'm not sure
the need for nested content-types is justified by the compression
case, but is another possibility for such a facility.

In the case of 8 bit nroff, or LaTeX or any of our favorite mark-up,
document enhancement languages, we should not try to identify what is
contained in the part.  What is a LaTeX document with boxes and charts
called?  Text?  Think of this as a parallel of ODA.  We just name it
and send it.

If the application cannot differentiate the data, it is not up to the
mail message format protocols to define it for the application.  Think
of Word Perfect.  It can represent many foreign characters, but I do
not think that we need to declare in the content-type header what
characters are used in the document. Mail is just providing transport
to these applications.

If the nroff has a 8 bit character in it, then it obviously needs to
be encoded, so specify that.  This is wierd in that nroff may or may
not need encoding, but I do not think we need to define a character
set for it.  We may have to be explicit in the definition of the Type:
nroff whether it needs to be encoded or not when sending over a normal
7 bit datapath, and that will largely determined by whether or not the
program itself is capabile of dealing with 8 bit characters.  If it
is.... it must be encoded!  Quoted Printable was defined for just such
cases.

Thoughts?

Greg V.








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