Bundling vs Mapping

Erik van der Poel erikv at google.com
Wed Feb 25 17:30:29 CET 2009


You may be comparing apples and oranges here. (sizeof(.arpa) bugs and
.museum, vs decimal/hex/octal number -> dotted decimal IPv4 address,
vs "bugs" in URI handling in the area of IDNA.)

If and when a particular "buggy" usage proliferates to the point that
you cannot reverse it, the "bug" effectively becomes a feature.
Descriptive documents are then helpful to newcomers. (This is a long
time after prescriptive documents have failed to force implementers to
change their ways.)

The question here is what exactly you consider to be a "bug" in
current URI handling in the area of IDNA. The next question is whether
the implementers are willing to change course. I have been trying to
ask that question for a couple of years now. Neither MSIE nor Firefox
representatives have given much of an opinion, which is
understandable, given the confusion and uncertainty.

Erik

On Wed, Feb 25, 2009 at 7:29 AM, Eric Brunner-Williams
<ebw at abenaki.wabanaki.net> wrote:
> 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
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>


More information about the Idna-update mailing list