The "no consecutive hyphens" prohibition (was: Re: Domain names with leading digits (Re: Determining the basic approach))

[John C Klensin]

--On Monday, 05 May, 2008 09:22 -0700 Paul Hoffman
<phoffman at imc.org> wrote:

>...
>>> 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.

I agree with both of those.  The only relevancy of ICANN in this
context is that, for registries who follow ICANN's advice
(independent of whether they are required to do so), this is not
a new restriction.  I do note that there appear to still be RACE
names floating around (with a different prefix) and that folks
periodically try to propose, and locally implement, different
IDN schemes with different prefixes.

>> 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.

Ok.  This is where we disagree.

What belongs in an IETF protocol, especially one that is
justified partially on the basis of extending the LDH principle
into Unicode space, is what is necessary to support good,
mnemonic, IDNs.   Given that, and remembering that it is easier
to relax rules later than to impose tighter ones, please turn
your statement around and answer the question of why one would
need hyphens in both the third and fourth positions of a domain
name.  If the answer is "changed prefix" or "some new protocol
use of a special-format name" (similar to the "_" prefix for
some SRV labels), then it would be entirely appropriate to
update these documents to permit those additional uses (and no
way to prevent it).  If it is something else, I'm interested in
hearing more about it.   But I believe the question, today, is
"do we gain anything by permitting those labels" rather than a
need to prove that they are harmful.

    john