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

[Erik van der Poel]

On Fri, Feb 27, 2009 at 8:49 PM, John C Klensin <klensin at jck.com> wrote:
> 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.

I find it mind-boggling too, and for that reason alone, it may not be
a good idea. Things are likely to go wrong somewhere.

>>> 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.

The zone owners make their own decisions, and implementers may or may
not give them their own mappings. So the approach does not scale, as I
said in my other email.

> 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?

Yes, this would be a problem.

>> 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.

You can't be serious.

> 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.

If implemented correctly, we would not introduce "different"
information, because it would check whether the display string maps to
the original. You're right about DNAME, so that would be a
limitation/difficulty.

> 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.

Such edge cases would be their own fault.

Anyway, I think I have reached the point where I can no longer come up
with refinements that might make the semi-proposal widely acceptable,
so I will stop pursuing it (again :-)

Erik