Following up on my earlier note about a comment from you that
really applies to the strategy on which all four documents are
really based...
--On Tuesday, September 18, 2012 20:44 -0500 Ben Campbell
<ben(_at_)nostrum(_dot_)com> wrote:
...
Along the same lines, section 7 seems to go to lengths to
illustrate why downgrading is somewhere between hard and
problematic. Do we really believe that downgrading will ever
be the "least bad"?
As compared to what, Ben?
One alternative is to not support delivery of SMTPUTF8 messages
at all except in environments in which it can be guaranteed that
all IMAP and POP clients that might contact the servers are
already upgraded. It is operationally possible to make that
guarantee in a few scenarios, but they are rare. In those
scenarios, many people in the WG would say "do that" (easily
managed by not having the delivery servers accept SMTPUTF8
messages until the POP/IMAP client upgrades are complete).
But, for all of the more usual cases in which the IMAP/POP
server operator cannot control exactly what clients might be
used, the only alternate is to not allow such messages, ever.
We don't think that is a desirable choice (or we wouldn't have
done the work in the WG) but nothing in these protocols require
that anyone deploy i18n mail.
For the other alternatives, yes, downgrading --by one of these
scenarios or some other one-- is, indeed, likely to be "less
bad" than others in some operational scenarios. In particular,
one alternate is for the server to silently delete all messages
requiring SMTPUTF8 (EAI) capability if a client connects that
doesn't support the needed capability. If only because the user
might later come back with a more capable client (or a message
access mechanism that doesn't use a POP or IMAP client at all),
that messaging-deleting alternative is almost certainly the
worst option of all, making almost anything else "less bad".
And, again, yes the WG discussed these issues at length, perhaps
even ad nauseam.
john