Problem in defs for Fake A-Label
John C Klensin
klensin at jck.com
Mon Mar 23 19:27:45 CET 2009
Mark,
I see a tradeoff between making yet more layers of definitions
and terminology whose only function is to clarify other
definitions and sufficient parsimoniousness of definitions to be
clear. Put differently, sometimes more terms produce
definitional overload with the result that people understand
less and not more.
With that qualification, I have no objection to making this
change if others agree with you about both the needed fix and
the way to fix it.
john
--On Monday, March 23, 2009 10:57 -0700 Mark Davis
<mark at macchiato.com> wrote:
> John, there is a problem in defs with Fake A-Label
>
> Defs:
>
> Some labels that are prefixed with "xn--" may not be the
> output of the Punycode algorithm, or may fail the other
> tests outlined below or violate other IDNA restrictions and
> thus are also not valid IDNA- labels. They are called
> FAKE-A Labels for convenience.-
>
>
> Protocol:
>
> Fake A-labels, i.e.,
> invalid strings that appear to be A-labels but are not,
> MUST NOT be placed in DNS zones that support IDNA.
>
> But in ASCII-LABEL for Fake A-Label you have:
>
> (3) Note that a Fake A-Label has a prefix "xn--"
> but the remainder of the label is NOT the
> valid output of the Punycode algorithm.
>
> I think what we should have is: XN-Label (as defined), with a
> subclass P-Label (the remainder is valid punycode), with a
> subclass A-Label (corresponds to U-Label). Then we have:
>
> - P-Label corresponds 1:1 with Unicode Label (any Unicode
> string with at least one non-ASCII character)
> - A-Label corresponds 1:1 with U-Label
>
> A Fake A-Label is {XN-Label - A-Label}, and not {XN-Label -
> P-Label}, which is what (3) says.
>
> Mark
More information about the Idna-update
mailing list