Parsing the issues and finding a middle ground -- another attempt

John C Klensin klensin at jck.com
Sat Feb 28 05:49:55 CET 2009


Erik,

Parts of this just boggle my mind, partially I'm sure because I
can't think about DNS and display issues in terms of the web
alone.  However, one specific observation below.

--On Friday, February 27, 2009 17:20 -0800 Erik van der Poel
<erikv at google.com> wrote:

>> And how would it work for
>>   string-in-greek.somedomain.biz.
>> which has nothing to do with the .GR TLD?
> 
> If .biz sees .gr's success and wants to emulate it but already
> has too many customers tied to IDNA2003 (e.g. different owners
> of tonos-less and tonos-ful names), .biz may decide not to
> switch. This is purely a business decision. Yes, this means
> that clients need a table of TLDs that use the .gr mapping.
> Not very difficult, but perhaps unpalatable to some engineers.

That example has nothing to do with biz.  If the DNS is to
remain an administratively-distributed hierarchy, "somedomain"
has got to be able to make its own decisions.  Indeed, if one
had 
  string-in-greek.a.b.somedomain.biz
then "a" would have to be able to make its own decisions
independent of any decisions made by "b", "somedomain", or biz.

If those records were not bound to the specific zone in which
the Greek string (or an IDN string more generally) occurred,
then one would have an inheritance problem that would both
reinvent the difficulties we've had with cookie-scoping and
issues with DNAMEs and the path used to reach the particular
name (I think there would be some problems in that area anyway,
but have not done a full analysis).

While you are focusing on a solution for Greece and .GR, I'm
having trouble believing that we would see a browser
implementation for just that domain... or that, if this
mechanism were available, it would not be used for other things.
In particular, if the full range of IDNA2003 mappings were
simulated, wouldn't it effectively permit display of the full
range of compatibility characters, something that virtually no
browser permits today?

> I wouldn't want to increase the size of each HTML file just to
> get the same effect that can be achieved using a single, small
> file at https://<name>.tld/idndisp.txt.

If I understand what you are proposing, and given the comments
above, it isn't one file per TLD, it is one file per zone.  And
HTML files are already considerably cluttered with display
information, so I don't see how this would make things worse.
Note also the DNAME issue -- an alias for a particular subtree
from a different zone would lose all of that information for the
node or, worse, introduce different information.

In addition, this implies that every page accessed by
differences in tails or search requests would have to support
the same mappings, even if those pages use a wide variety of
languages and scripts.   Maybe that is ok, but I'd guess there
would be some strange edge cases out there.

    john



More information about the Idna-update mailing list