Well, recognising at least a handfull of changes to the content-type
definitions note, I think it was a usefull endevor. I would like to
try the same with a new definition of transport-encoding.
I agree with klensin that a huristic, scanning, guessing approach to
conversion is really not the preferable way to go. I also believe
that content-type should have nothing to do with transport encodings.
Related to encoding, there are two independent pieces of data needed,
what the data requires for transport and what the encoding should be.
This list has imparted both meaning to one field, and that is not
necessarily bad if one understands what is happening. I argue that
there are really not "silly states" if we understand that content-type
is totally independent of encoding, and that there are two independent
concepts in the encoding header.
I already know the terms are not the best, but the idea is what
counts. I considered separating the two axis into a multi-part line
but I do not see the advantage that complexity gains in a 2X2 matrix.
Data type | Line Limited Binary
Data Encoding ----|----------------------------
|
Quoted Printable | 8line 8bin
|
Base 64 | Almostbinary Binary
The key to this proposal is the definitions of the encodings. Note:
THESE ARE DIFFERENT FROM THE PREVIOUS MEANINGS
7bit. This is a traditional 7 bit mail message. Never needs
encoding, never should be encoded. This is the default.
8line This is a 8 bit message which requires an 8 bit texual
datapath. If this is encoded, it must be in quoted printable.
8bin This is a 8 bit message which requires an 8 bit texual
datapath. If this is encoded, it must be in Base 64.
Almostbinary This is a 8 bit message which requires a full binary transport
capability. If encoded, it must be in Quoted Printable.
Binary This is a 8 bit message which requires a full binary transport
capability. If encoded, it must be in Base 64.
Greg Vaudreuil