 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: casing, etc. Unlike IDN, I tried to make clear that
I'm suggesting no mapping be done prior to encoding, it's merely an encoding. The
server side would still do whatever it wants with casing, which means that it
MUST decode it to Unicode, then do whatever mapping it wants. (Differently
cased shäwn and SHÄWN would get different encodings and could not be compared
in the encoded form.) That makes matching of the ACE forms more difficult, but
avoids problems with casing rules being interpreted differently. Re: partial downgrade. I cannot imagine how allowing
mail to be delivered, but not providing for replies to work is helpful. There’s
no way for a sender to know if they were ignored or just had a mail mixup. I
don’t think that the “reply” anecdote you describe is appropriate in the modern
world. We have a much more reliable system now and reply-all is expected to
behave. I think that either we need to have no downgrade at all,
or we must have nearly-complete downgrade. I also think that nearly-complete
downgrade would require an algorithmic technique as we’ve pretty much proven
that pairing (by <<>> or other means) breaks pretty rapidly. I don’t think the downgrade technique discussion blocks
any of the non-downgrade specs from proceeding. Obviously EAI doesn’t “need”
downgrade, it just might ease the transition. -Shawn -----Original Message----- --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 |