[Bug 24660] New: Constraint validation on input type="email" and punycode conversion

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24660

            Bug ID: 24660
           Summary: Constraint validation on input type="email" and
                    punycode conversion
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: denis@w3.org
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

One of the constraint validation on the input type="email" [1] talks about
punicode conversion:
[[
Constraint validation: While the user interface is representing input that the
user agent cannot convert to punycode, the control is suffering from bad input.
]]

After talking with the guys from the i18n WG (Richard Ishida, Martin J. Dürst
and John C Klensin), it appears this section is not accurate and should be
probably revised.

John C Klensin:
[[
Ideally, it should remove the discussion of the Punycode
algorithm and "punycode strings" entirely.  They have never been
correct and, with the approval of IDNA2008, became less so.
They should be replaced it with a discussion of U-labels and
A-labels with a reference to RFC 5890-5893 and a caution, per
RFC 6055, that, if a putative domain name is seen by the browser
application in U-label form, it should be kept in that form as
long as possible.   It would probably also be wise to advise
that only A-labels (and potentially U-labels) be used when
writing HTML references -- whatever the merits of the ongoing
arguments about mappings and support for different mappings in
different implementations, it is definitely much safer and less
prone to ambiguity and IDNA2003 -> IDNA2008 and Unicode version
differences to use the A-label form.

If an implementation is using a high-quality IDN resolver
library (or name resolution algorithm that incorporates one),
that is probably all the HTML writer needs to know. If someone
is trying to evaluate such an implementation, they really need
to rely on the IDNA RFCs not a summary in the HTML spec.
]]


[1]
http://www.w3.org/html/wg/drafts/html/CR/forms.html#e-mail-state-%28type=email%29

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 14 February 2014 09:24:45 UTC