erm.. instead of
"if you can't figure it out, bounce"
why not
"if you can't figure it out, use base64"
With the understanding that there are no show-stoppers here for me
one way or the other, let's review the problem we are trying to solve.
As RFC-ZZZZ is now structured (and I have yet to see a concrete
proposal for a different structuring), anything wanting to send using
8bit transport is going to need to do several "special" things. It must
do some protocol negotiation to get agreement for the 8bit transport.
It must provide at least enough RFC-XXXX structure to identify the
character set (however RFC-XXXX ends up specifying that) for character
data, and to identify whatever else is going on for other types of data.
It isn't that big a deal to ask it to throw in a preferred encoding
specification. One could even do it in the envelope if we didn't have
multipart messages and an "encode only at the bottom level" rule.
I assert without proof that it is always better to be explicit about
what is needed/wanted than to make the receiver or converter guess.
Now, if one is a would-be converter, there is no "just convert to
base64" option, since that might imply nested encodings. There is, at
most, a "parse the message one part at a time and apply base64 to any
parts you can't otherwise recognize". Now that doesn't bother me, but
it is not a big advantage over insisting that the sender supply the
information. And it does provide the "opportunity" for converting plain
ASCII to base64, which some people have felt is a disaster case (not a
"nothing is lost" case).
So my instinct is to insist that senders provide this information and
that we let converters have "open season" on any [by definition bogus]
messages that arrive without it.
But I don't think it is terribly big deal one way or the other; I
could easily live with David's suggestion.
--john