Domain names with leading digits (Re: Determining the basic
phoffman at imc.org
Mon May 5 20:32:03 CEST 2008
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
>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
We can't tell if that is true.
>But we can't run a double-blind experiment on that theory.....
More information about the Idna-update