Well, I just looked through the "advanced downgrading" video and have concluded that I should spend my available time in some other way than on this thread (at least until a purchase order for writing tutorials shows up). I suppose I should explain: First of all, automated conversation of a local part to Punycode encoding (or punnycode, whatever that is) is not merely a violation of the SMTPUTF8 protocols but violates an important and quite explicit SMTP requirement. So that isn't "Standard Downgrading", it is just broken and will cause significant interoperability problems if the sender and recipient systems are not following the same non-standard conventions. If the UA effort thinks that developing such conventions (or standards) as within its scope, there is a letter I need to write to the ICANN Board and community. As to "Advance Upgrading", this appears to be nothing more than a mechanism for a given user to have an all-ASCII address and one of more non-ASCII ones and to switch between them either manually or automatically. That was exactly the "downgrade" model contemplated during the experimental period of the EAI WG. It turns out that, for Internet email, where any system can attempt to send mail to any other system, it simply cannot be made to work for the general case. It is fairly easy and workable for sending mail with all-ASCII recipient addresses and a non-ASCII backward-pointing address if the sending MUA or the submission server has the necessary tables. Even then, it won't work unless either the MUA or Submission server maintain an accurate whitelist or the submission server has a high degree of assurance that, if the first SMTP receiver it accesses has SMTPUTF8 support, than all others in the path do (the specs strongly recommend that things be configured that way, but there are no guarantees, especially given possibly-transient situations. Move generally, the approach can be implemented and shown to work (and hence to pass various tests) under some specific conditions such as one or more of: (i) The sender and recipient are on the same system, or a system developed by the same organization, with no intervening non-conforming relays. Of course, if those conditions are met, there should be no reason why downgrading (simple, advanced, or otherwise) is needed. (ii) There is a highly-available, robust, and universally-trusted (and presumably non-attackable) Internet-wide directory service in which a user or address can be looked up and other addresses reliably found. (iii) It is possible to establish a direct Internet connection be6ween the system that wants to handle the address but cannot and the system whose domain appears in the relevant address so as to ask that destination system abound alternate addresses. This was examined within the WG -- IIR, there was actually an I-D written to specify how it would work (including over relays, eliminating the "direct connection" requirement) but never posted because of a number of problems that became obvious after careful study. Otherwise, one needs a standard and every system that doss not accept and properly handle SMTPUTF8 needs to conform to it. I hope the contradiction in that is clear to everyone. best, john --On Thursday, November 9, 2017 18:56 +0000 Mark Svancarek <marksv@microsoft.com> wrote:
I started documenting the cases, but didn't finish during the meeting, and haven't resumed since back home. Mea culpa.
From: ua-eai-bounces@icann.org [mailto:ua-eai-bounces@icann.org] On Behalf Of Dr Ajay Data Sent: Thursday, November 9, 2017 10:44 AM To: mark svancarek via ua-eai <ua-eai@icann.org>; barry leiba <barryleiba@computer.org> Cc: `john r. levine` <johnl@iecc.com>; john c klensin <klensin@jck.com> Subject: [UA-EAI] Re : Re: [Ext] EAI Working group Archives
Wow !!. looks like i missed some action in between , however I am refraining myself to complicate it further.
I am inclined to share a video link of Advance Downgrading<https://na01.safelinks.protection.outlook.com/?url =https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeSIb0FFmuS8&data= 02%7C01%7Cmarksv%40microsoft.com%7C22018b199f3e449f9ddd08d527a 1e82b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645849871 7964221&sdata=vTjfszlTfg7RhZJrP2sfIUe3r1qWBZkFyJHkMBYDN0s%3D&r eserved=0>, which explaints the progress I have demonsterated during ICANN60 , proposed to be followed by all EAI providers and as of now working very well for us. Zero problem case / break in communication.
I think, we all should start documenting <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F %2Fmagicboard.in%2Fp%2FDowngradingIssues&data=02%7C01%7Cmarksv %40microsoft.com%7C22018b199f3e449f9ddd08d527a1e82b%7C72f988bf 86f141af91ab2d7cd011db47%7C1%7C0%7C636458498717964221&sdata=m4 nMxLXul3ntAZge4YdNqMArojkMeZTRPRWCPa6GnRg%3D&reserved=0> the possible PROBLEMATIC Scenarios / Cases and Lets try to solve them by defining the protocol / standard. This has to be solved. We can not let it be like this. Fortunately, if we can addresses 5-7 email products, we are done by more than 80% of the world, rest everyone can follow.
Best Wishes. Dr. Ajay DATA | Founder & CEO Get email id like अजय@डाटा.भारत<mailto:अजय@डाट ा.भारत> in your own language, visit www.xgenplus.com<https://na01.safelinks.protection.outlook.com /?url=http%3A%2F%2Fwww.xgenplus.com%2F&data=02%7C01%7Cmarksv%4 0microsoft.com%7C22018b199f3e449f9ddd08d527a1e82b%7C72f988bf86 f141af91ab2d7cd011db47%7C1%7C0%7C636458498717964221&sdata=r2HC tj90rFjco0KX0WVi4H4S7FVgrPsXrVQo23FlHjU%3D&reserved=0>
________________________________ From: Mark Svancarek via UA-EAI <ua-eai@icann.org<mailto:ua-eai@icann.org>> MailId : [75379724] To: Barry Leiba <barryleiba@computer.org<mailto:barryleiba@computer.org>> Cc: "ua-eai@icann.org<mailto:ua-eai@icann.org>" <ua-eai@icann.org<mailto:ua-eai@icann.org>>,John C Klensin <klensin@jck.com<mailto:klensin@jck.com>>,"John R. Levine" <johnl@iecc.com<mailto:johnl@iecc.com>> Subject: Re: [UA-EAI] [Ext] EAI Working group Archives Date: 09 Nov 2017 04:28:13 AM
Thanks for clarifying. I agree with those examples.
/marksv
-----Original Message----- From: barryleiba@gmail.com<mailto:barryleiba@gmail.com> [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba Sent: Wednesday, November 8, 2017 2:47 PM To: Mark Svancarek <marksv@microsoft.com<mailto:marksv@microsoft.com>> Cc: John C Klensin <klensin@jck.com<mailto:klensin@jck.com>>; John R. Levine <johnl@iecc.com<mailto:johnl@iecc.com>>; Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Joseph Yee <jyee@afilias.info<mailto:jyee@afilias.info>>; HEALTH Yao <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>; ua-eai@icann.org<mailto:ua-eai@icann.org> Subject: Re: [Ext] EAI Working group Archives
Just clarifying before I agree p , what is an example of the second case where it`s an unreasonable expectation?
Things related to the many, many weird cases. We`re not going to fix all issues with confusibles, we`ll always have bidi issues and various other troubles that come from mixing scripts, there are many problems that come from the fact that it`s often not sufficient to know the script and not the language (ö vs oe in German and Swedish, for example, or where to sort ö in German vs in Swedish; difficulties caused by the two different Turkish "i" characters; and so on), and a bunch of other things like that which mostly amount to only occasional and mostly fairly minor problems.
"Geez, that text looks silly!", is a minor problem. "It won`t take my password!", is a more serious problem, but there are (unpleasant) workarounds. "It tells me that my domain name / username / email address is invalid!", blocks you completely.
b _______________________________________________ UA-EAI mailing list UA-EAI@icann.org<mailto:UA-EAI@icann.org> https://mm.icann.org/mailman/listinfo/ua-eai
Do not Remove: [HID]20171109042813611[-HID][https://data.in/XGenPlusMessageID :15102530391186546a-#RCPT#.jpg] [http://dlr.tbms.in:8077/XET6408:201711.jpg]