To me, personally speaking, both a-label and u-label should be "universally accepted" in forms.

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.

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.

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.



On Nov 13, 2017 15:56, "Richard Merdinger" <rmerdinger@godaddy.com> wrote:
Mark,
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.

Richard Merdinger
VP, Domains
rmerdinger@godaddy.com



On 11/13/17, 10:24 AM, "UA-discuss on behalf of Mark Svancarek via UA-discuss" <ua-discuss-bounces@icann.org on behalf of ua-discuss@icann.org> wrote:

    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).

    It's the first part, where the human user is typing an ALABEL into a web form, that concerns me.

    Is this the wrong interpretation?

    -----Original Message-----
    From: UA-discuss [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan
    Sent: Sunday, November 12, 2017 10:34 PM
    To: ua-discuss@icann.org
    Subject: Re: [UA-discuss] Progress on HTML and email...

    On Mon, Nov 13, 2017 at 05:47:20AM +0000, Mark Svancarek via UA-discuss wrote:
    >
    > 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.
    >
    > 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.
    >

    The domain part does not actually prohibit Unicode in the strict sense.  There's a note in the document that says

        This syntax allows e-mail addresses with Internationalised Domain
        Names using punycode, such as example@xn--d1acpjx3f.xn--p1ai. A
        user agent should represent that in the user interface as
        example@яндекс.рф

    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.
    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.

    Best regards,

    A

    --
    Andrew Sullivan
    ajs@anvilwalrusden.com