<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>Andrew, We all know the answers as discussed in meeting also yesterday which you missed.. however to be clear.. my email is asking question and members views , I am not suggesting anything here.</div><div><br></div><div>If we know the concurrent views, it will form the part or document for EAI .</div><div><br></div><div>We already buried that discussion of companies doing whatever they want..None of our and UASG concern. </div><div><br></div><div>Thanks.</div><div><br></div><div><br></div><div id="composer_signature"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Email Powered by XgenPlus - Worlds Most advanced email.</div><div><br></div><div style="font-size:100%;color:#000000"><!-- originalMessage --><div>-------- Original message --------</div><div>From: Andrew Sullivan <ajs@anvilwalrusden.com> </div><div>Date: 11/03/2018 09:22 (GMT-05:00) </div><div>To: ua-discuss@icann.org </div><div>Subject: Re: [UA-discuss] Issue needs discussion and closure </div><div><br></div></div>Hi,<br><br>I am now even more regretful that I couldn't make yesterday's session,<br>since it clearly was interesting. Some comments below.<br><br>On Sun, Mar 11, 2018 at 08:19:39AM +0530, Ajay Data wrote:<br>> <br>> 1. Sender ID as xn--anything in local part.<br>> <br>> If email server receives an email FROM xn--anything@validdomain , should<br>> email server at receiving end Do..<br>> <br>> a. the conversion of xn--anything to UTF8 string.<br>> b. Leave it the way it was received i.e xn-anything<br><br>I don't know what 1.a means. As far as I know, there is no protocol<br>of any kind specified anywhere that that talks about algorithmic<br>transformations of local-parts from an ASCII-compatible-encoding (ACE)<br>to UTF-8. The prefix 'xn--' is not a magic universal transformation<br>indicator: it works for individual labels in domain names when IDNA is<br>in use, and that's it.<br><br>If we want a reliable protocol mechanism that can do this<br>transformation, I think it probably needs some protocol engineers to<br>work on it. I will observe that the IETF's EAI working group twice<br>declined to do this kind of mapping, and it might behoove those who<br>are interested in seeing such a mapping to go and review the prior<br>discussions about why it was not taken up before. But I will suggest<br>that people consider the differences between RFCs 821 and 822, and RFC<br>952, as a short cut to understanding why "punycode for local-parts"<br>was not really a good idea.<br><br>I think you should expect that a local-part-prefix for this kind of<br>transformation indicator would be just about anything other than xn--,<br>since that is in use for domain name labels and overloading this for<br>email local-parts would be quite a bad idea. (Please remember that<br>"xn--" is added to the A-label after the Punycode algorithm is run<br>over the candidate U-label.)<br><br>I'm also pretty nervous about your use of "mail server" there, since<br>it suggests that intermediate mail servers should be doing<br>transformations. This is definitely a bad idea: section 2.3.11 of RFC<br>5321 prohibits it.<br><br>All of that said, of course, it's the Internet: your network, your<br>rules, and you can do what you want with local-parts in your mail<br>system. Just don't expect it to work predictably with others.<br><br>> 2. Is Mixing of scripts is allowed in mailbox local part While creating a<br>> mailbox like..<br>> <br>> a. scripta@scriptbdomain - ajay@ਡਾਟਾਮੇਲਭਾਰਤ<br>> b. scripta+scriptc@scriptbdomain ajayअजय@ਡਾਟਾਮੇਲ.ਭਾਰਤ<br><br>I don't know what "allowed" means in this context, since practically<br>anything can go in a local-part. It has always been possible to mix<br>scripts in the domain-part, because the DNS is a distributed hierarchy<br>so there can only be rules zone by zone (which might be label by<br>label, and might not be), and those rules are set by the zone operator<br>(ICANN makes rules for the root zone, and through contractual<br>mechanisms makes them for gTLDs, but that's the extent of ICANN's<br>control). I can imagine proposing good pratices for restricting the<br>scope of scripts to be used in local-part identifiers based in part on<br>what server-part identifiers are in use. <br><br>> 3. Alias ID on MUA:<br>> <br>> We already agreed that Downgrading of Alias is good practice<br><br>I literally don't know what that means, but I will observe that<br>"downgrade" was a failed experiment in the EAI protocol and was<br>deprecated. Moreover,<br><br>> and to be followed<br>> by email servers while communicating with legacy systems<br><br>…how do you know when you're communicating with "legacy systems"?<br>Your only knowledge is of the next mail hop, which might not be the<br>MTA that does the final delivery. We do not have a mechanism to<br>specify the mail path (mercifully, bang addresses went out a long time<br>ago), and therefore we don't have a mechanism to make sure that the<br>mail path the whole way through can do ESMTP, never mind EAI.<br><br>>, however we have not<br>> discussed how Alias will be made available on MUA and if there are many Alias,<br>> than which will be used for downgrading.<br><br>I also don't understand what that means. I'm also not sure what it<br>would mean to make rules about what MUAs can do.<br><br>Best regards,<br><br>A<br><br><br>-- <br>Andrew Sullivan<br>ajs@anvilwalrusden.com<br>.<br></body></html>