Re: [EAI] Rechartering

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

--On Friday, July 17, 2009 8:32 PM +0000 Shawn Steele 
<[e-mail]> wrote:

> We definitely want the "right" result :)  My request isn't
> "just to have a schedule", but rather so that there's
> something we can plan to.  Also, if "right" takes much longer,
> it won't matter.  There's a huge user segment that currently
> doesn't have effective email support because they aren't
> literate in the Latin script.  It'd be nice if those people
> could be enabled to experience what we take for granted, and
> IMHO it's worth risk of not being perfect in order to support
> them in the next year instead of longer.
>...

Shawn,

Personal opinion only...

First, we know from the IDNA experience what the costs are of 
getting into a hurry because of some real or imagined deadline, 
taking shortcuts about decision-making, and getting things even 
a little bit wrong.  We discover that those decisions cause 
problems somewhere, problems that are serious to some 
communities who very much need to have them fixed.  And then we 
find that discussions of fixing them cause someone to say, 
essentially, "no matter how bad the earlier decision was, we 
cannot make an incompatible change, so that community just 
loses".  In the long term, that sort of situation costs us 
global interoperability and everyone loses.

That said, there are conceptually two design elements in the EAI 
work.  On has to do with the basic idea of non-ASCII addresses, 
header fields, and related information.   It is relatively 
straightforward and, although I think more testing is needed, 
all of the evidence so far is that it just works between EAI 
implementations (and communication with non-EAI implementations 
gets handled the same way any "the server doesn't support the 
capability you need" situation --with the exception of 
8BITMIME-- is handled, and that model is very well tested).

The other is the idea of downgrading.  It involves exploration 
of a new area -- new syntax in addresses, new header fields, 
comments that aren't quite comments, header fields with closer 
relationships to other header fields than we are usually 
comfortable about, non-obvious rules about when downgrading is 
permitted, and so on.  We've got some empirical evidence from 
Ernie's tests that different implementations interpret the 
specification a bit differently and that some combinations of 
systems will lose information.

Before the WG can meaningfully move toward standardization, we 
have to sort the downgrading issue out.  If there is strong 
consensus one way or the other as to what to do, then I think we 
can move forward quickly.   If there isn't, we will will 
probably need a lot of empirical evidence about what works and 
what doesn't, what needs respecification, and so on.  That is 
going to take time, especially if we continue at our current 
pace.

In particular, with the understanding that I am not proposing or 
recommending this and don't favor it, suppose the WG reached 
agreement in the next few weeks that speed was more important 
than a downgrade capability, independent of what various of us 
believe about whether downgrading could be sorted out in the 
long run and about how useful it would be.  We'd need to look 
carefully at the IMAP and POP documents, but excising 
downgrading from the rest would be fairly straightforward and 
the dominant concern for "use the experimental docs and 
implementations to see if this can really work in the hostile 
real email world" would vanish.  I'd guess that, if the various 
authors got motivated and moving, we could have a charter 
modified for standards track and updated documents that were 90% 
final by Hiroshima.

But, we keep downgrading in the program and if testing continues 
to be as leisurely as it has been in the past, with results that 
are as ambiguous, it may be a long time.

I note that, while you've made your wishes clear, you haven't 
offered to get a test implementation together on a platform 
entirely different from the ones that have been used so far and 
then both make that test platform available for interoperability 
testing and do significant testing yourself/yourselves.  That is 
the sort of action that would help things move forward more 
quickly.

again, just my opinion.
    john