Re: [EAI] Rechartering

["YAO Jiankang" <[e-mail]>]

----- Original Message ----- 
From: "Shawn Steele" <[e-mail]>
To: "John C Klensin" <[e-mail]>; "Harald Alvestrand" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 21, 2009 2:37 PM
Subject: Re: [EAI] Rechartering


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

As Xiaodong has already pointed out it, China's standards will be full compatible with IETF EAI WG RFCs. we will also follow the downgrade rfc. Actually, many chinese care for the downgrade issue very much. 

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

it is better that industry powers such Microsoft, yahoo, google can join this beta test.

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

The first chinse email standard is mainly based on RFC4952. ohter standards will follow RFC5335 5336 5337 5504. if we can move the standard track soon,
china will follow the new IETF standard. Chinese are eager to IETF EAI standard track too. 

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

I am also involved in the chinese EAI standards' work. the chinese standard will support downgrade.


Yao Jiankang

> 
> 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
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima