[EAI] General issues and strategy (was: Re: Content Issues [ was: Internationalized Email Internet Draft])
John C Klensin <klensin@jck.com> Fri, 14 October 2016 15:45 UTC
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD3129845 for <ima@ietfa.amsl.com>; Fri, 14 Oct 2016 08:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFvd1d7M3zHR for <ima@ietfa.amsl.com>; Fri, 14 Oct 2016 08:45:30 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91E512944D for <ima@ietf.org>; Fri, 14 Oct 2016 08:45:29 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1bv4fj-000As5-EL; Fri, 14 Oct 2016 11:45:23 -0400
Date: Fri, 14 Oct 2016 11:45:18 -0400
From: John C Klensin <klensin@jck.com>
To: nalini.elkins@insidethestack.com, "HANSEN, TONY L" <tony@att.com>, ima@ietf.org
Message-ID: <8B119C286A3CFDE08C598251@JcK-HP8200>
In-Reply-To: <489025644.216489.1476451836537@mail.yahoo.com>
References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <E125B6AC26988823306936BF@JcK-HP5.jck.com> <489025644.216489.1476451836537@mail.yahoo.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/ZrMA69wBe8nKgnnlHdkvFSCoJ1w>
Cc: Harish Chowdhary <harish@nixi.in>, Peter Saint-Andre <stpeter@stpeter.im>
Subject: [EAI] General issues and strategy (was: Re: Content Issues [ was: Internationalized Email Internet Draft])
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 15:45:35 -0000
Nalini, Given your decision to go for separate threads, which I think is a good one, some general comments: --On Friday, October 14, 2016 13:30 +0000 nalini.elkins@insidethestack.com wrote: > John / Tony, > I am going to split your comments into separate threads so > that I can keep track of each. >... > Yes. I see your point. Let me say first the basic thing > that we are trying to do is to discuss the holistic user > experience of internationalized emails from an operational > point of view. In so doing, the co-mingling happened. We > could do a second draft for content issues or change the > abstract of this one to better state what our real goal is. > Secondly, as you guys know well, there are lots of other > issues with IDN, browser support, etc. What we were > actually hoping is that we could have a forum (perhaps like > DNSOps or v6Ops) where we could come together to define and > discuss such problems, move towards best practices (or work > arounds! Not that I like that, but it happens.) Because we > have not even started on problems that we see such as search > algorithm ranking of IDNs and so on. We were hoping that > others would step up to author such other drafts. A few very general comments about context. This might anticipate some future note from you, so I hope I can get it off quickly... (1) I trust you are aware of the ICANN=-sponsored "Universal Acceptance" effort, which is covering some of this same ground. Personally, I believe they are seriously out in the weeds, doing a good deal of work on assumptions about the DNS and the EAI work that are just not valid for a number of technical reasons, but it would be unfortunate to waste whatever cycles are associated with duplicative efforts. As far as I know, Don Holland is still lead; I think he is on the EAI list but am not sure. (2) I trust you are also aware that there is an IAB I18N program. It has been, again IMO, fairly unhealthy in the last couple of years, largely because the available cycles of the most active and expert people have disappeared into the IANA Transition activity. If you want a forum or workshop, they might be a good place to start. Ted Hardie is lead; I have no idea whether he is on the EAI list. (3) Despite the obvious interest and importance of this issue, I have observed very little actual energy in the IETF for dealing with it or i18n issues more generally. By the time the EAI WG got its documents out, there was little interest in specific work beyond "we just want this to work". By the time the PRECIS WG got its RFCs out, there was little general interest in careful review of documents (resulting in a need to start work on revisions almost immediately thereafter). AFAICT, the strongest and most general sentiment in the WG was "just tell me what to do so I don't need to understand or think about this". That is understandable, but not a good foundation for getting work done. The community has been completely unable to engage with the "non-decomposing character" issue that has paralyzed some important IDNA applications for a couple of years now (IMO, the LUCID BOF, supposedly addressed to that issue, did a good job of illustrating the more fundamental problems with IETF engagement, including a lengthy discussion of just how to spell Zürich in English (or, for that matter, in various versions of German). (4) Even among those who were active in the EAI work, there has been, AFAICT, silence so far except from Tony and myself. I know that some are off chasing general equivalence of DNS names. I believe that effort shows a fundamental lack of understanding of the properties of the relevant data structures but it seems to be getting agenda time in Seoul (see "DNSBUNDLED" on Jari's "New Work in Seoul" BOF list). (5) You should also be sure you understand that many of the issues with non-ASCII identifiers, especially identifiers (5) If you want rapid deployment of fully-internationalized email messages, it is important that you understand that there were alternate hypotheses for how to get both the IDN and that work done. For IDNs, we could have changed the DNS and server matching algorithms (which might have permitted approximate matching and made a number of issues with comparison and normalization much easier) or we could have adopted an "above DNS" model which would have also helped with the matching and search issues. However, there was a great deal of pressure, some of it emotional and paralleling the comments about "English" in your draft, for "fast" and "in the DNS", and that got us the mappings, restrictions, and trick encoding of IDNA. Every bit of new evidence or pressure for synonymous labels and matching that is predictable given local language culture is an argument that we got it wrong and should have gone for one of the other approaches, probably a member of the "Above DNS" family. For EAI, there was a similar choice. We could have stuck with all-ASCII address local parts and focused on better use of encoded names (e.g., by making it clear that not copying a name phrase into a reply or to or from an address book was a very bad practice, encouraging address book lookups by the name phrase or equivalent as well as the address, etc., thereby saving a good many transition and interoperability problems. I note that was the solution adopted by the ITU, an organization with far more representation and influence from countries and people who speak English as a second language if at all, for a broad range of I19n issues. Instead, there was a strong commitment in the WG and those who pushed for it to have all-non-ASCII mailbox addresses and to phase out the encoded word approach. At least a significant fraction of the WG understood the likely (or certain) costs of that decision including slow deployment and interoperability issues that would likely limit EAI use to "within community" communications. If, at any point, you want to argue for discarding SMTPUTF8 and returning to an encoded word model, there are less difficult (but also less culturally and aesthetically attractive) ways to move forward. best, john (BTW, as a further illustration of the "too few people with spare cycles" problem, I'm writing this note rather than working on the current round of PRECIS revision drafts (and they are, in turn, holding up work in URNBIS) and am copying Peter, who I don't think is on the EAI list either, so he knows what is happening.)
- [EAI] [IETF] Internationalized Email Internet Dra… Harish Chowdhary
- Re: [EAI] [IETF] Internationalized Email Internet… HANSEN, TONY L
- Re: [EAI] [IETF] Internationalized Email Internet… John C Klensin
- Re: [EAI] [IETF] Internationalized Email Internet… nalini.elkins
- [EAI] [IETF] Content Issues [ was: Internationali… nalini.elkins
- [EAI] [IETF] Homographic Attacks [was: Internatio… nalini.elkins
- [EAI] [IETF] Display of Email Addresses [was: Int… nalini.elkins
- [EAI] [IETF] Arabic / Bidirectional Writing Syste… nalini.elkins
- [EAI] [IETF] Multiple Addresses [ was: Internatio… nalini.elkins
- Re: [EAI] [IETF] Display of Email Addresses [was:… Andrew Sullivan
- [EAI] [IETF] Relational Databases: UTF8 [was: Int… nalini.elkins
- Re: [EAI] [IETF] Display of Email Addresses [was:… nalini.elkins
- [EAI] [IETF] Migration / Backward Compatibility [… nalini.elkins
- [EAI] [IETF] Terminology [was: Internationalized … nalini.elkins
- [EAI] General issues and strategy (was: Re: Conte… John C Klensin
- Re: [EAI] [IETF] Internationalized Email Internet… nalini.elkins
- Re: [EAI] General issues and strategy (was: Re: C… nalini.elkins
- Re: [EAI] [IETF] Display of Email Addresses [was:… John C Klensin
- Re: [EAI] [IETF] Content Issues [ was: Internatio… Franck Martin
- Re: [EAI] [IETF] Content Issues [ was: Internatio… John C Klensin
- Re: [EAI] [IETF] Multiple Addresses [ was: Intern… John Bucy
- Re: [EAI] [IETF] Multiple Addresses [ was: Intern… nalini.elkins
- Re: [EAI] [IETF] Multiple Addresses [ was: Intern… John C Klensin