Re: [EAI] Rechartering

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

--On Tuesday, 21 July, 2009 06:37 +0000 Shawn Steele
<[e-mail]> wrote:

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

Well, I don't know how to go much further in speculation in that
direction.  There are people on the list, including the
co-Chair, who presumably know what is going on with Chinese
standardization efforts and they can speak up if they consider
that appropriate.

There are a number of areas in which we've discovered, in more
ways than I (at least) would have initially predicted, that
Chinese is different from other scripts.   Some of them, like
the effects of Han unification and SC/TC relationships, are
perhaps artifacts of Unicode coding decisions, others are more
basic.  It is more difficult in some ways, and easier in others.
Almost every time someone has extrapolated from CJK to other
scripts or in the other direction, they have gotten themselves
into trouble.  

That doesn't change your basic concern, but is an extra argument
why we should proceed with due caution and why an international
standard might be very different from one for use within China
for communication among those who are Chinese-literate.   I
think our Chinese colleagues have recognized that distinction
from the beginning and, again, can speak for themselves.

> I'm also concerned that the quirks of downgrade aren't going
> to be very discoverable in an laboratory setting :(.  

We share that concern.  It is why the "testing" I'm most anxious
to see involves turning EAI loose in the general Internet email
environment and seeing what happens.  That is exactly the kind
of testing Ernie has been trying to do.   While the specific
problems that have been identified can be fixed (some may
require revisiting documents to be sure we all really intend the
same thing), the trend is not encouraging even after only a
handful of tests.

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

While I'm actually anxious to move this along as quickly as we
reasonably can, at this point, I can only remind you and others
about the success rate of proprietary (and even national and
regional) email models and standards that do no interoperate
smoothly with the existing Internet base.  I'm sure you, or
those around you, remember both MSMail and the original,
incompatible with even X.400, Exchange Server model.  Harald
doesn't need to be reminded about X.400 itself, and that list
goes on and on.

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

See above above "quirks".  And, whether "downgrade" is used or
not,  it makes  sufficient changes to the fundamental syntax of
Internet email addresses, and sufficient requirements on systems
processing headers, that it will be with us forever even if no
one is actually using it.  Conversely, it makes implementation
of i18n mail sufficiently more difficult that we just can't
estimate whether having it will speed deployment (by making it
slightly easier for EAI-compliant systems to communicate with
legacy ones) or slow it (by making implementation and deployment
of EAI-compliant systems much more difficult.   The issue with
implementation and deployment are pervasive and may extend into
things that the documents don't talk about.  For example, the
typical address book today maps a name onto one email address
(or maybe "home" and "work" email addresses).  EAI downgrading
essentially requires that address book support more than one
address with the same role.  Is that a big deal?  I don't know--
it will certainly depend on the address book design.  But it is
almost certainly going to require more work than simply making
provision for the existing fields to be in UTF-8 and more
instruction to the user about what is going on.   Part of that
discussion is closely related to one we are having in the
IDNABIS context, which is how much we really expect users to
know and adapt to in order to keep computer systems and networks
happy.  I don't know the answer, but, unlike a few years ago,  I
now suspect that alternate addresses in the protocol will put
more of a knowledge burden on users than just having messages
returned if non-ASCII address doesn't go through.  

As another example of a side effect of the downgrading
architecture, consider the huge number of web sites out there
that ask for email addresses.  We know that many of them,
probably a majority, can't even get a local part that contains a
"+"-delimited subaddress right.  Can they be converted to handle
UTF-8 local parts?  I think so, but, for some systems, it will
require more work and education than we probably anticipate.
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 -- the pointed brackets will
be rejected, the alternate address will confuse it beyond any
hope, etc.   On the other hand, I think a simple
   иван@bogus.domain.name
will work before I convince them to handle that "+".

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

Sure.  But see above.

I'm actually getting very sympathetic to the idea in Charles's
note of doing the rest and then letting downgrading sort itself
out later.  But, in practice, I think that dooms downgrading, at
least along the lines of the current specification.   Without
it, we get to simplify the syntax to make i18n address syntax
just traditional syntax with non-ASCII characters -- not only
does the alternate address syntax go away but so does the
requirement for brackets, etc.  Syntactically, SMTP is actually
pretty easy either way.  But, once you get the provisions for
downgrading out of the syntax of addresses in the mail headers
--and, in practical terms, the addresses that users see-- those
extensions are, in practice, probably gone for good: it won't be
easy to put them back in if systems don't even recognize the
syntax as valid.

But, to partially agree with Charles and say it differently, I
think one can have "quick" without Downgrade or somewhat more
slowly (a lot more slowly if the WG continues at its recent
pace) with it.   I don't have any idea how to choose but I am
determined that, if we have Downgrading, it will be "right" and
its interoperability and implementation characters well-tested
and understood.

    john


     john