On Sep 19, 2012, at 6:53 AM, John C Klensin <john-ietf@xxxxxxx> wrote: > 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@xxxxxxxxxxx> 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? (I assume that to be rhetorical :-) ) > 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. I'm willing to accept that the work group decided this was the best that could be done. My concern is that the current situation (5721bis normatively [with a MUST] references 5738 bis, which informatively references the downgrade drafts (as examples), which are themselves standards track) seems internally inconsistent. > > john > >