Ned writes...
The type field has NOTHING to do with the transfer encoding used. It might
suggest an appropriate transfer encoding to use -- maybe.
...
I think this is true. I'm not sure that it is quite where we thought
we were a while back, but I think it has been adequately demonstrated.
But...
A gateway that is choosing an appropriate encoding without full knowledge of
all types might do well to use a combination of the type, an analysis of
the data, and some heuristics to encode things. No other approach seems
appropriate.
This is scary, and dredges up all of the old fears about gateways and
other critters creatively encoding and improving messages beyond
recognition.
If no other approach is appropriate within the present RFC-XXXX model
(and I think that is probably true), then this makes a case that a new
header should be introduced at the level of the message parts that may
need to be encoded (to eliminate the nesting problem). And that header
should be [nearly] required for 8bit transport. Let's call it, in
memory of another useful concept, "Klensin-has-flipped-out", with the
following rules:
(1) Klensin-has-flipped-out MUST NOT appear as part of the same header
set as content-transport-encoding (however that is spelled today); you
get one, or the other, or neither.
(2) The argument to Klensin-has-flipped-out is chosen from the list of
possible arguments to content-transport-encoding, e.g.,
quoted-printable, base64, plus some keyword/symbol that implies "none
required".
(3) A mail agent intending to convert and forward an 8bit message
into a 7bit environment must examine the message (part by part for
compound messages to avoid nested encodings) for Klensin-has-flipped-out
headers.
Case 3.1: one is found that specifies "none required"
the klensin-has-flipped-out header is discarded in the converted
message.
Case 3.2: one is found that specifies a transport encoding
the specified transport encoding is applied to the message or
relevant body part, and the klensin-has-flipped-out header is
replaced by a content-transport-encoding header.
Case 3.3: The klensin-has-flipped-out header does not appear.
The agent may choose to either:
3.3.1. Immediately bounce the message.
3.3.2. Inspect the message or relevant body part for octets with
the high bit set. If none are found, treat the message as if
"none required" had appeared, otherwise bounce.
No error-prone and/or unpredictable heuristics. No trying to overload
the content-type. Conversion facilities have to understand how to parse
RFC-XXXX headers and multipart messages (a heavy burden, IMHO), but they
don't need deep semantic knowledge of types and their implications.
Conversion specifications are provided by the sending user or system,
which presumably knows what it is doing and what the message represents.
Plain ASCII inside a message that is transported over 8bit facilities
doesn't get converted to anything, it stays plain ASCII. And all of the
burden is borne by those who want to send messages over 8bit connections
and want to provide for in-transit conversions.
One could add an additional case above in which the argument would have
the semantics of "forbidden", such that, if any klensin-has-flipped-out
header appeared in the message with "forbidden", the agent would be
required to bounce the message rather than attempting conversion. That
would probably eliminate the need for a separate conversion authority
header.
While I'm not completely happy with this, it seems like a plausible
alternative. Or have I really flipped out?
--john