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

[Paul Hoffman]

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?

>Registry recommendations' powers tend to peter out extremely fast 
>with distance from the registry.

Of course. But the WG is relying on registry rules and 
recommendations for many other things that are being changed from 
IDNA2003. We need to be consistent on this point: can we remove 
things from the IDNA protocol and have them be enforced by 
registries, or can't we?

>>There is a second place. In draft-klensin-idnabis-issues-07.txt, 
>>section 1.5.4.1.1 prohibits labels that have a hyphen in positions 
>>3 and 4 unless they are A-labels. This is completely unnecessary.
>>
>>
>This prohibition was made by ICANN in order to prevent speculation 
>against prefixes in the time period before IANA announced the 
>selection.

Yep. So? That was years ago, and we're not ICANN.

>As long as we never have to change the prefix, or introduce a second 
>prefix for another purpose, it is unneccessary. How much do you want 
>to bet that it will be?

It is unnecessary regardless of introducing a second prefix. We 
learned the first time that there are plenty of prefixes available, 
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.