Re: [EAI] Rechartering

[John C Klensin <[e-mail]>]

--On Thursday, July 23, 2009 01:16 +0000 Shawn Steele
<[e-mail]> wrote:

>... 
> On a Windows PC that pretty much involves "everything".
> OpenType apparently even has a field for an email address.  I
> can see some partial tests being possible, but I can't imagine
> that a full test of "everything" would be feasible,
> unfortunately.  (I can see where I could talk myself into a
> corner here, I don't mean to not be careful, I just mean that
> we aren't going to catch everything.)

Of course not.  That would require nearly proving a universal
negative. On the other hand, one only needs to find a few
problematic cases to know that there is a problem.

Your Windows "nearly everything" example is an interesting one
simply because one of the ways of making users crazy (another
one of those intra-system examples) is that if there is not a
standard way to parse addresses that either (i)looks for a
balanced/ matching ">" rather than either getting into error
states if a "<" is encountered or getting into problems with
">>" or (ii) is sufficiently centralized in an API that
everything uses so as to be easily changed...

Then it seems to me that you are in big trouble because
deploying EAI with Downgrade --even in the syntax-only form
Charles suggests-- means that users will encounter it working
one way in some places (e.g., accepting non-ASCII addresses but
not alternate address syntax) and in other ways (e.g., accepting
non-ASCII and alternate addresses) in others, even within the
same system.   That is, IMO, much worse even that having
extended (non-ASCII) addresses work in some places but not in
others.

>> But I personally think that the odds of getting a site that
>> can't manage "[e-mail]" to be able to
>> handle <иван@bogus.domain.name <[e-mail]>>
>> within my lifetime are pretty small.
> 
> I'd agree, but [e-mail] should still work :)0

Sure.  But unless it can be parsed out of the above, that isn't
interesting.   Note that, if one had a Unicode-native system and
simply removed the "ASCII address" restriction,
    иван@bogus.domain.name
would parse as the address the user would expect while
    <иван@bogus.domain.name <[e-mail]>>
would almost certainly get some sort of "invalid end of address"
or "invalid unquoted space in the middle of the address" error.
And, if it tried to "fix" that error, as many MUAs and some
other systems would, life would get interesting.

> So, I pretty much agree with your points, but you aren't
> giving me much hope of EAI being adaquate to those criteria in
> the next decade.  I still think some sort of schedule would be
> interesting to help us figure out how to proceed in addressing
> your concerns.

Again, if you are in a hurry, the key question is whether we
need downgrading.  If we don't, a large fraction of the issues
I'm raising just disappear and I have no trouble working through
a schedule (in your model) or a requirements plan (in Harald's).

    john