--On Thursday, 17 February, 2005 11:16 -0800 Paul Hoffman
<[EMAIL PROTECTED]> wrote:
>> Alternatively, if some registries (e.g. CJK) wish to have
>> their own rules (i.e. RFC 3743 "JET"), then they can of
>> course do so. I certainly do not want to have a balkanized
>> net, but the degree of balkanization is what matters. I.e.
>> if we only have 2 methods (CJK vs the rest), that's better
>> than having numerous methods.
>
> Many people spent a lot of work trying to get coordination
> and/or cooperation for creating those lists. So far, the
> results have been less than stellar. The cultural imperatives
> and political exigencies make that work very, very difficult
> despite all the good effort.
Erik,
Let me agree with Paul here (!), especially about the cultural
imperatives and political expediencies. But I think your
comment about "numerous methods" deserves some additional
response. Let me try to put the JET work,
draft-klensin-reg-guidelines, the ICANN guidelines, and a few
other registration-side efforts in perspective.
Registries have always (since long before IDNs and, for the old
host tables, even before the DNS) been able to say "there are
names that we will not permit to be registered here" and/or
"there are entities we will not permit to register here" and/or
"that entity can register, but only with one of these names".
Beyond enforcement of the "hostname" (or "LDH") rule --neither
of which is "English" but which is, itself, a registration
restriction, there has been no uniformity among domains about
what those rules are and how vigorously they are enforced.
We've seen rules about length that are more restrictive than the
DNS limit, rules about national presence, rules about
registration only of names that appear in national business
registers, rules about prohibited "nasty" words, and so on for a
very long list.
That isn't just about TLDs: I've got biases about names in
jck.com, and I enforce them... and so do a rather large fraction
of the enterprise and other domain administrators in the world
whose domains consist of labels for more than a couple of hosts
or functions.
None of these rules or conventions causes any interoperability
(or balkanization) issues at all: a resolver either finds the
name or doesn't, and is indifferent to whether a name that is
not found isn't there because no one wanted to register it or
because they were prohibited from doing so.
We would have interoperability issues if someone tried to change
the resolution rules themselves: a local (and different) version
of the IDNA tables that would map a UTF-8-encoded Unicode string
to a different punycode string than is called for by the IDNA
and nameprep specs would be very bad news indeed. So would
installing a DNS server that would use a set of lookup and
matching rules different from those required by 1034/1035. But
people rarely propose such things and, so far, we have been
fairly successful at talking them out of it when they do...
precisely because such actions would balkanize the network.
So, in general, having different sets of registry restriction
rules in different registries, even unique rules for each
registry, are not a problem. Having individual applications
programs, such as browsers, guess what those rules are for a
given domain is, by contrast, a nightmare. While warning the
user when certain types of anomalies are detected makes a lot of
sense, any sort of "bad name" restriction on a name that is
IDNA-conformant would be really bad news, going far beyond the
messes I tried to warn about in RFC 3696.
There are two groups of folks for whom different restrictions in
different registries are a problem. They involve registrants
who want to register the same name in many domains and the
registrars who need to deal with them (and with those domains).
For the former, the fact that a name may be acceptable in some
domains and not others is tough luck. It has always been tough
luck: IDNs may expand the number of possible reasons for
rejection, but they don't introduce any new problem. For the
registrars, one level of service involves trying to understand
what all the rules are for any domain they support. That is
tough, but not impossible. Another level involves just sending
a proposed name in and seeing if it is accepted. They are, for
most domains, in a very competitive environment; the marketplace
will presumably sort out the best combination of service levels
and pricing. The one piece of that issue that is an IETF story
is that we should try to design registrar-registry
communications protocols to deliver good information back to the
registrar as to why a particular proposed name is being
rejected. My impression is that we are doing that reasonably
well but that we should keep looking for ways to improve things
while keeping them general.
But, again, no interoperability or balkanization problems here
unless someone starts making changes to the resolution or
matching protocols or models.
john
