Domain names with leading digits (Re: Determining the basic approach)

[Paul Hoffman]

At 6:50 PM +0200 5/5/08, Harald Tveit Alvestrand wrote:
>Paul Hoffman skrev:
>>At 5:45 PM +0200 5/5/08, Harald Tveit Alvestrand wrote:
>>>Paul Hoffman skrev:
>>>>At 7:48 AM +0200 5/5/08, Harald Tveit Alvestrand wrote:
>>>>>I THINK, but do not know, that what Paul means by:
>>>>>
>>>>>   11.  Make some currently-legal, non-IDNA labels illegal
>>>>>
>>>>>. . .
>>>>>
>>>>>And the resulting rule is:
>>>>>
>>>>>   o  The first character may not be an EN (European Number) or an AN
>>>>>      (Arabic Number).
>>>>
>>>>Correct, in part (see below). This rule prohibits thousands of 
>>>>current domain names like 3com.com, 1800flowers.com, and a whole 
>>>>lot of others. It could be changed to be a registry 
>>>>recommendation instead of a prohibition on all labels, even ones 
>>>>that don't appear in IDNs.
>>>As currently specified, it would require 3com.com to insert an 
>>>extra, non-numeric domain before they inserted a RTL name: 
>>>RTL.r.3com.com would be OK, but RTL.3com.com would not be. It's 
>>>not a prohibition on "all labels" in the text you deleted above, 
>>>but I'm pretty sure I didn't manage to get this clear & consistent 
>>>in all places in the current version of the document.
>>
>>We read your document differently. It sure sounds like the rules in 
>>section 4 apply to all labels. Where is the text that says that 
>>they don't?
>Section 1.1, the text I quoted in my first mail:
>
>   When labels pass the test, they can be used with a minimal chance of
>   these labels being displayed in a confusing way by a bidirectional
>   display algorithm.  In order to achieve this stability, it is also
>   necessary that the test be applied to labels occuring before or after
>   the label containing right-to-left characters, which prohibits some
>   LDH-labels that are permitted in other contexts.

That's non-normative text. Section 4 is the normative text.

>>It is unnecessary regardless of introducing a second prefix. We 
>>learned the first time that there are plenty of prefixes available,
>as I remember it, in the end, IANA made a pick among 17 or so. Not a lot.

Enough. And we don't need to use the same format for the prefix.

>>and that preventing speculation was probably overkill. We can deal 
>>with this when we think we want another prefix, or ask ICANN to 
>>deal with it. It does not belong in an IETF protocol.
>I may be more pessimistic than you; I think speculation would have 
>been a significant problem if ICANN had not laid down its 
>prohibition.

We can't tell if that is true.

>But we can't run a double-blind experiment on that theory.....

True.