Re: [EAI] Thinking about requirements / downgrade

[John C Klensin <klensin at jck.com>]

--On Wednesday, September 16, 2009 06:25 +0000 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

>...
>> left-hand sides indiscriminately. This can lead to similar
>> effects as the "Bush hid the facts" bug (see
>> http://en.wikipedia.org/wiki/Bush_hid_the_facts for details).
> 
> Yup.
> 
> But I think it's worth the improvement for behavior in the
> 99.999% case.  Maybe we could get statistics for how many
> account names actually look like this.  Also we could pick
> something really wierd (like the q.-_.z or something).  
> IDN had the same issue, but seems to have succeeded (at least
> in that respect.)

Shawn,

I addressed most of this in a note I sent a few hours ago and
that probably crossed yours in the email.  I won't repeat myself
but, as others have also pointed out, the issues here are much
more complicated than the IDN ones.  In particular, one of the
issues that has generated a lot of traffic on the IDNAbis list
-- the desire to have upper-case letters that are properly
majuscules, not capitals, handled differently depending on
context-- gets a rather different answer here because of the
"local parts get interpreted only by the delivery system"
principle.  For example, while the DNS guarantees
case-insensitive matching for ASCII labels, there are absolutely
no guarantees in email about case sensitivity or insensitivity.
I actually works on a system some years ago in which traffic
for, e.g., joe at example.com was treated as mail traffic for joe
while traffic for jOe at example.com was treated as a command
stream for one of joe's processes or daemons.  The idea didn't
last very long for security reasons --and got replaced by
members of the family of the messy strings I described-- but you
get the idea.

I have to agree with what I think was at least the intent of a
recent note of Harald's -- each of these suggestions needs
careful analysis and explanations of what cases exist, which
ones "work" (and what that implies) and which ones fail and in
what ways.   Without that sort of analysis, asserting that a
particular approach will solve some large percentage of cases
does not, IMO, help us very much (and doing so in a large stream
of messages helps, again, IMO, even less).

That said, let me state a question that I think might be
illuminating, even though I'm not sure whether I think what it
implies is acceptable:

Suppose we were willing to start with "the number of cases in
which downgrading is needed will be fairly few if sending
systems are carefully designed and configured and receiving
systems and their MX intermediaries are configured correctly"
(you, Ernie, Jiankang, and others, including myself, have all
said variations on that).  We also assume that the number of
cases in which it is needed will go down over time, as EAI
deploys more broadly and as various actors understand the
configuration issues better.  Could we then say "whatever
downgrading is needed is about getting messages delivered anyway
but, if downgrading is applied, we no longer expect 'replies' to
work reliably"?  On the one hand, that is a fairly big step.
But it has a lot of precedent (some intentional and some not) in
email systems.  And it would sweep away a lot of issues,
including Harald's exemplar triangular case.

Generating a header/marker to warn the recipient that the
headers may not show all recipients and that "reply all" may not
reach everyone to whom the original message was sent is pretty
easy (reexamining the idea of using group syntax might work well
here).  As far as addresses are concerned, it turns the entire
downgrade story into an envelope one, where we don't have syntax
problems (double angle brackets or otherwise).  It minimizes
long-term damage for short-term/ transitional gains and gives
the various humans involved an incentive to upgrade.   And it
makes things completely predictable, which you've been asking
for, as long as one is willing to count "if you reply to this,
it probably won't work as you expect, but no one prevents you
from trying" as predictable behavior (I actually do, YMMD).

I note that there were many examples and bad jokes about both
X.400 and early versions of Exchange whose substance was that
the only reliable "reply" mechanism involved picking up a
telephone, so, in practice (and perhaps even in theory), we've
never had nearly the same level of expectation about replies
working that we've had about deliveries getting through.

But it is a big step.  Is it one we might be willing to consider?

     john