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