Domain names with leading digits (Re: Determining the basic
approach)
Harald Tveit Alvestrand
harald at alvestrand.no
Mon May 5 18:50:57 CEST 2008
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
More information about the Idna-update
mailing list