Bundling vs Mapping

[Eric Brunner-Williams]

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