Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-5738bis-09

[Ben Campbell <[e-mail]>]

On Sep 19, 2012, at 6:53 AM, John C Klensin <[e-mail]> 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
> <[e-mail]> 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
> 
>