I have not yet seen a reasonable justification for nested encoding, so
I propose that we vote on whether to allow it in RFC-XXXX or not.
I believe John, Stef, Ned, (Mark?), and myself are agreed on the following
statement: nested decoding should not be required of RFC-XXXX UAs.
Unless someone violently objects, can everyone out there agree on this
statement pending the November WG meeting?
-------
Indeed, as Ned states,
...The 822 extensions seem firm enough to me. The SMTP extensions
are the place where all the trouble lies...
the question is how to deal with RFC-ZZZZ and 821. If RFC-ZZZZ->821
gateways are pure and ignore RFC-XXXX content-transfer-encodings, then we
land in Mark's 'silly' gateway problem. We have two bad solutions:
A) Reopen the RFC-XXXX discussion to require a high level header indicating
the 'highest' content-transfer-encoding and
B) Build RFC-ZZZZ->821 Gateways such that they dynamically determine
which encoding to use by looking at the bytes.
And we have two good solutions:
1) Build RFC-ZZZZ->821 Gateways such that they understand the RFC-XXXX
content-transfer-encodings as per Ned's latest suggestions.
2) Ignore the problem. Allow mail encoded by a ZZZZ->821 Gateway to be
decoded by a 821->ZZZZ Gateway, by the user, by a nested decoding
RFC-XXXX UA, by /dev/null, or by divine intervention.
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)?
enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com