<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="">I totally agree with Jordyn <div class="">and Mark "Just capture the string and send a test message.”</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2017, at 10:38 AM, Jordyn Buchanan via UA-discuss <<a href="mailto:ua-discuss@icann.org" class="">ua-discuss@icann.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Also worth remembering that "works according to the universe at the moment the RegExp was written" is how we got into a lot of today's UA mess in the first place. Just because dotless domains or some other rule is in place today, I'd want to avoid encoding them into a regexp that we tell people to use since the rules may change again and I don't want to have another group following along in our wake 10 years from now trying to undo the code that we told everyone to write.<div class=""><br class=""><div class="">Jordyn</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Sep 14, 2017 at 1:27 PM, Rubens Kuhl <span dir="ltr" class=""><<a href="mailto:rubensk@nic.br" target="_blank" class="">rubensk@nic.br</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br 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="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
<br class="">
Rubens<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br 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="">
>> 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="">
>>> 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="">
>><br class="">
>> 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="">
><br class="">
> Don Hollander<br class="">
> Universal Acceptance Steering Group<br class="">
> Skype: don_hollander<br class="">
><br class="">
><br class="">
><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>