I believe John, Stef, Ned, (Mark?), and myself are agreed on the following
statement: nested decoding should not be required of RFC-XXXX UAs.
I believe that I'm in agreement with this, but...
-- I'm not sure what it means unless we figure out a way to prevent
anything (including gateways) from ever creating one of these. I have
argued, I think with some agreement, that such a bad cannot be expected
to work.
-- I understand what options a UA which does not support this has in
handling it. Regardless of what behavior I would prefer, can it
recognize this case without having the ability to decode and reject the
message? Or is it impossible to recognize the case such that the
multiply-encoded thing always gets dumped on the user?
Now, as I understand it, Ned's (pragmatic and reasonable) position is
that the UA must recognize the nested encoding case because there is no
way to prevent it from arising. And, because users really want
intelligable mail delivery, rather than technical excuses, once the
situation is recognized, the nested encoding just has to be decoded.
That makes a statement that a "UA is not required to support nested
encodings" useless in practice.
Maybe I'm completely confused, but I think that is a lot of what has
been driving this discussion.
Before the debate begins (ha!), is everyone agreed that RFC-XXXX has
nothing to do with this? Does everyone agree that either (1) or (2)
is better than (A) or (B)?
With two qualifications, yes.
Qualification 1: There are alternatives other than 1 and 2, including
the "designated converter" plan that Stef and I floated some months ago.
Used in combination with Ned's proposal or some near-variant (which is,
I think, what we "don't convert" types have been advocating all the way
along), it eliminates both the imposition of serious encoding complexity
on an MTA that "merely" wants to pass 8bit traffic through *and* the UA
complexity of nested encoding.
Qualification 2: The more one says "this is an MTA problem", the more
reasonable it becomes to say "transport encodings are an envelope
problem and not a header one". That *does* have something to do with
RFC-XXXX.
--john