Re: [EAI] Rechartering

[Shawn Steele <[e-mail]>]

I appreciate the concerns about moving too fast, and I don't disagree with your assessment of the risk.

My concern is the standardization of UTF-8 email in China.  I'd rather that the IETF standards, including downgrade, were compatible with China's standards.  Otherwise we could end up with a de-facto standard of whatever China is (or isn't) doing with downgrade.

I'm also concerned that the quirks of downgrade aren't going to be very discoverable in an laboratory setting :(.  I don't foresee any problems that can't be corrected with the current approach to downgrade, however it's the unforeseen that's the problem.  At the leisurely pace it's been proceeding, I'm afraid that the industry won't wait for the working group, particularly if the Chinese standards proceed without the IETF WG standards.

I also fear a Chinese EAI standard without downgrade more than a downgrade with quirks.  Also, hopefully, "downgrade" will eventually stop being used, so even if it's really bad, at least it should be limited :)

So IMO moving cautiously/slowly is also a risk, and it's rapidly becoming a larger risk than the proposed documents in their current state.  I'm aware of at least 2 other attempts/approaches to "international email" that were shot down/deferred to wait for a real EAI standard from the IETF.  I doubt the users in those communities will wait forever.

-Shawn

________________________________________
From: John C Klensin [[e-mail]]
Sent: Sunday, July 19, 2009 1:55 PM
To: Shawn Steele; Harald Alvestrand
Cc: [e-mail]
Subject: Re: [EAI] Rechartering

--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