Bundling vs Mapping
Eric Brunner-Williams
ebw at abenaki.wabanaki.net
Wed Feb 25 16:29:39 CET 2009
I've been busy for most of the past two days doing DNSSEC (and trying
not to comment on the DLV vs ITAR controversy that's blown up on the ops
list) while this list has been very busy with Esszett and Final Sigma,
and without distracting from that subject there are two points I'd like
to make:
The first is to generalize on a misconception that Martin made several
days ago:
That's of course possible. But that basically means asking to pay again
for something that the registrant thought they already had as part of
their registration.
Martin doesn't know how the CDNC registries proposed to make the
protection of user expectations transparent to (and costless to) the end
user, he wasn't there when we struggled with the issue, pre-IDNA2003
WGLC. And I don't expect him to ever stop trying to correct me about the
SC/TC problem.
He and probably everyone not present at the Delhi Registry Constituency
meeting when Edmund Chung and I urged Paul Twomey and Peter Dengate
Thrush ("ICANN Staff" hereafter) to consider variant strings in new gTLD
proposals so that the same user expectation could have been met and made
transparent and costless knows that this proposal was rejected, and by
whom. Peter and Paul responded immediately that each distinct sequence
of code points was (a) a separate application, and (b) potentially
awarded to separate applicants -- in their (incorrect) view, variant
strings were just another registry operator business exploit that we
were trying to get "for free".
The real point here isn't that Peter and Paul need clue, rather that
anyone who contributes to the IDNA mailing list on _policy_, in
particular on registry policy, and generalizes from a very limited set
of knowledge and experience to some general rule, could ask if their
views are consistent with a larger body of knowledge and experience,
rather than assert their generalization as fact.
I wouldn't take it amiss if everyone were to extend their agreement to
the proposition that variant strings for gTLD applications ought not to
cost the registry applicant an arm and a leg each, nor result in
separate parties, contracts and practices for two or more members of a
set of variant strings for a particular application string. Hitting
ICANN's greedbot that's currently demanding $185,000 per variant, plus
$75,000 per year per variant, with a large cluebat, would be slightly
more useful than complaining about registry greed and stupidity, which
is where Shawn's note about "all the variants of some IDN form of
mYdOmAiN.com", which started this thread, and the prior "doesn't scale"
notes by others earlier in related threads, depart.
The second is to comment made by Patrick:
If we talk about domain names, lets talk about domain names. If we are
to talk about URIs, lets talk about URIs.
I know I'm a minority of one (or more, but not a lot more) that views
the proper scope of the Working Group to be mechanisms for extending the
range of characters which may form valid DNS text labels from the ASCII
LDH set. Whether DNS text labels are correctly processed by anything
other than resolvers is outside of scope -- when .museum went into the
root there were sizeof(.arpa) assumptions in some people's code that
simply _were_not_controlling_. I went to the effort of pointing out to
ICANN that the "stability of the internet" requirement stated in the
Guidebook for Applicants (GfA) that applications not be all digit (or
the hex or octal equivalents) was an overspecification, and in the
revised GfA published this week ICANN retained the
no-digits-or-hex-or-octal requirement and "stability of the internet"
rational, offering as a rebuttal that there is some code would function
incorrectly, evaluating strings with the apparent decimal value greater
than 255 (octal and hex equivalents omitted for space) as having an
apparent decimal value less than 255.
The real point here is that other people's bugs are their problem. Their
disinterest in the problem domain ought not be controlling on the range
of solutions properly considered (else we'd be the Microsoft standards
publication user group). Like Patrick, I am sympathetic to the issue of
how to do mapping and use of IDNs in URIs, but there must be forward
progress there, not non-progress here.
Eric
More information about the Idna-update
mailing list