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

[Harald Tveit Alvestrand]

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.

>> 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?
Let's list them and do them case-by-case (in another thread, please).
>
>>> 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,
as I remember it, in the end, IANA made a pick among 17 or so. Not a lot.
> 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.

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

                  Harald