<div dir="auto">To me, personally speaking, both a-label and u-label should be "universally accepted" in forms.<div dir="auto"><br></div><div dir="auto">In a utopian world, it should just be the u-label always, but that assumes everything works correctly everywhere with ux, forms and what not.<div dir="auto"><br></div><div dir="auto"><div dir="auto">It has been my experience that if someone is entering an a-label they are not the standard user, and they are doing so to override ux concerns and eai.  They have some understanding of how a/u works, have something functional with the domain name, and are wanting to ensure that the domain they entered works correctly, bypassing the ux / other systems (eai) that may not be working as expected.</div><div dir="auto"><br></div><div dir="auto">If a person filling out a form takes the initiative on entering the appropriate registry's a-label, they should not be penalized for it.<br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 13, 2017 15:56, "Richard Merdinger" <<a href="mailto:rmerdinger@godaddy.com">rmerdinger@godaddy.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mark,<br>
I can’t speak for the spec itself, but there should be some normalization that takes place so that the user can input either the u-label or the a-label form.  If the spec doesn’t allow for this flexibility, I think is should be augmented to do so.<br>
<br>
Richard Merdinger<br>
VP, Domains<br>
<a href="mailto:rmerdinger@godaddy.com">rmerdinger@godaddy.com</a><br>
<br>
<br>
<br>
On 11/13/17, 10:24 AM, "UA-discuss on behalf of Mark Svancarek via UA-discuss" <<a href="mailto:ua-discuss-bounces@icann.org">ua-discuss-bounces@icann.org</a> on behalf of <a href="mailto:ua-discuss@icann.org">ua-discuss@icann.org</a>> wrote:<br>
<br>
    My interpretation is that the user is a human who must enter a string of text into a web form, where it is cast as type Email (which can subsequently be converted into ULABELs if the typed-in string includes ALABELs).<br>
<br>
    It's the first part, where the human user is typing an ALABEL into a web form, that concerns me.<br>
<br>
    Is this the wrong interpretation?<br>
<br>
    -----Original Message-----<br>
    From: UA-discuss [mailto:<a href="mailto:ua-discuss-bounces@icann.org">ua-discuss-bounces@<wbr>icann.org</a>] On Behalf Of Andrew Sullivan<br>
    Sent: Sunday, November 12, 2017 10:34 PM<br>
    To: <a href="mailto:ua-discuss@icann.org">ua-discuss@icann.org</a><br>
    Subject: Re: [UA-discuss] Progress on HTML and email...<br>
<br>
    On Mon, Nov 13, 2017 at 05:47:20AM +0000, Mark Svancarek via UA-discuss wrote:<br>
    ><br>
    > The assumption is that all local parts are ASCII letters-digits and that IDNs in the domain part should be expressed in punycode.  This is of course doubly broken, because humans can’t really use punycode.<br>
    ><br>
    > Fixing the local part is a good start and I encourage it.  But if the domain name part continues to prohibit Unicode, it won’t actually help anyone.<br>
    ><br>
<br>
    The domain part does not actually prohibit Unicode in the strict sense.  There's a note in the document that says<br>
<br>
        This syntax allows e-mail addresses with Internationalised Domain<br>
        Names using punycode, such as example@xn--d1acpjx3f.xn--<wbr>p1ai. A<br>
        user agent should represent that in the user interface as<br>
        example@яндекс.рф<br>
<br>
    So, the user-agent is asked to do the IDNA transformation from A-label to U-label for display purposes.  Since under IDNA2008 that ought to be a 1:1 and fully reversible operation, it shouldn't be a big deal.<br>
    It's true that this input restriction won't produce an EAI address, but that is trivial to fix, also, if you do the IDNA transformation.<br>
<br>
    Best regards,<br>
<br>
    A<br>
<br>
    --<br>
    Andrew Sullivan<br>
    <a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
<br>
<br>
<br>
<br>
</blockquote></div></div>