<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
Yes indeed. Whatever directionality the text is affects the display ordering and not the memory ordering. So memory order will always be (or should be according to current best practice) <a href="mailto:mailbox@domainname.tld" class="">mailbox@domainname.tld</a> and
so one processes/validates as usual without regard for the display order. That is the current best practice.
<div class=""><br class="">
</div>
<div class="">When presenting to the user than one uses display order. Which reminds me of a blog article I wrote some time ago because with appropriate html/css one can determine how it is displayed😀 <a href="http://schappo.blogspot.co.uk/2016/10/computer-science-internationalization.html" class="">http://schappo.blogspot.co.uk/2016/10/computer-science-internationalization.html</a> Oh
...and... <a href="http://schappo.blogspot.co.uk/2016/03/arabic-email-addresses.html" class="">http://schappo.blogspot.co.uk/2016/03/arabic-email-addresses.html</a></div>
<div class=""><br class="">
</div>
<div class="">André Schappo</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 14 Sep 2017, at 18:41, Asmus Freytag <<a href="mailto:asmusf@ix.netcom.com" class="">asmusf@ix.netcom.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On 9/14/2017 10:27 AM, Rubens Kuhl wrote:<br class="">
<blockquote type="cite" class="">The BiDi issue suggests to me that even enforcing the non-dotless rule is too much for a simple regex, as shabaka.example@don is a valid Arabic EAI , while the same ASCII combination is not valid even if a .don TLD gets delegated.<br class="">
[non-empty]@[non-empty] looks better to me.<br class="">
</blockquote>
<br class="">
Isn't the bidi limited to the display side, that is, in back storage there should not be alternative ordering of host and local parts?<br class="">
<br class="">
A./<br class="">
<blockquote type="cite" class=""><br class="">
<br class="">
Rubens<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">Em 14 de set de 2017, Ã (s) 13:58:000, Don Hollander <<a href="mailto:don.hollander@icann.org" class="">don.hollander@icann.org</a>> escreveu:<br class="">
<br class="">
Thanks Jim.<br class="">
<br class="">
The BiDi issue, with raw data input, is which side has the domain side.<br class="">
<br class="">
usually you’ll encounter <a href="mailto:mailbox@domainname.tld" class="">mailbox@domainname.tld</a><br class="">
<br class="">
But in Arabic or Hebrew you’ll encounter tld.domainname@mailbox<br class="">
<br class="">
Don<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On 15/09/2017, at 3:44 AM, Jim Hague <<a href="mailto:jim@sinodun.com" class="">jim@sinodun.com</a>> wrote:<br class="">
<br class="">
On 12/09/2017 19:44, Don Hollander wrote:<br class="">
<blockquote type="cite" class="">One RegEx has stood out as being simple and correct. I’d like the UASG<br class="">
to consider recommending this in our documentation. Toward that end,<br class="">
this thread is for discussion.<br class="">
<br class="">
/^.+@(?:[^.]+\.)+(?:[^.]{2,})$<br class="">
<br class="">
Regular expression check in Javascript. This accepts any Unicode<br class="">
characters, only insisting that the domain must have more than one label<br class="">
and the TLD is 2 characters or longer.<br class="">
</blockquote>
Note that this in the context of an in-browser check. I only examined a<br class="">
small random subset of the sites surveyed in the main evaluation, and<br class="">
obviously without access to server code could only examine client-side<br class="">
operations. In all the sites I examined, the only check performed was<br class="">
against one (or in one case two) regular expression(s). No decomposition<br class="">
of the email address was attempted, and certainly no translation of the<br class="">
domain to Punycode.<br class="">
<br class="">
It was in that context that I highlighted the above regex, on the basis<br class="">
that it's probably the only sensible option to suggest to organisations<br class="">
as a low-impact UA improvement (I won't say fix) at the moment. If a<br class="">
future evaluation exercise verifies that an existing Javascript module<br class="">
does the right thing, that would be a better alternative, but that would<br class="">
involve more substantial modifications to site code.<br class="">
<br class="">
I agree that modifying it to allow 1 character TLDs would be sensible.<br class="">
<br class="">
I also agree with the page referenced at the start of the thread (which<br class="">
I read before working on the report) that just checking for '@' is about<br class="">
all one should attempt, certainly client-side.<br class="">
<br class="">
Turning again to the above regex, of course, being a proposed regex for<br class="">
validating email addresses, it's got an obvious deficiency. It needs to<br class="">
add support for other label separators (e.g. open dot).<br class="">
<br class="">
Mark Svancarek raised the excellent point of bidi in the domain.<br class="">
Personally I'm not confident I understand the bidi rules. But if the<br class="">
regex requires at least one label separator character in the domain and<br class="">
non-empty labels, will that work, given that if the regex allows 1<br class="">
character TLDs then a valid TLD is simply a non-empty label?<br class="">
-- <br class="">
Jim Hague - <a href="mailto:jim@sinodun.com" class="">jim@sinodun.com</a> Never trust a computer you can't lift.<br class="">
</blockquote>
Don Hollander<br class="">
Universal Acceptance Steering Group<br class="">
Skype: don_hollander<br class="">
<br class="">
<br class="">
<br class="">
</blockquote>
<br class="">
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>