Unicode position on local mapping

[Andrew Sullivan]

On Tue, Feb 17, 2009 at 05:14:32PM -0800, Mark Davis wrote:
> 
> B) Registry local mapping.
> 
> C) Client local mapping.

> For (B), I'm not sure what you think, but for me is clearly a case where
> local mappings make sense, and are being currently implemented (under a
> different name, bundling). 

> For (C), this is the area that the UTC position is actually addressing;

I think we need to disambiguate these two cases, so let's always call
(B) "Bundling" and (C) Client local mapping.  Then we won't get into
trouble about whether "mappings" are allowed only to discover that we
mean two different things by "mappings".  

I think that there is nothing whatever in the current drafts that
implies restrictions on (B).  I think what would be very nice is a way
for clients to look up the inclusion rules for (B) and do some
preprocessing with the rules in order to make their queries more
efficient.  But ultimately, (B) puts all the power into the hands of
the registries at registration time, and avoids clients having to know
a lot.  This is good, in my view, because it puts the responsibility
of what is in the zone squarely with the zone operator.

> And the thought of the thousands of user agents; browsers, IMers, emailers,
> plus search engines, (plus varying by versions!) sending <a href="Å.com"> to
> "aa.com" instead of "å.com <http://xn--5ca.com>" is a nightmare. Before
> allowing that nightmare, we really need to hear a compelling case for it!

I completely agree.  My understanding is that the argument for local
mappings is twofold:

1.  Some things really really need never to be looked up.

2.  Some things in the class (1) are nevertheless natural in some
natural languages, so a way to make them useful is needed.

If both of those premises are true, I have suggested before, then I
think we need to revisit the assumption that DNS can be hacked on
until it can satisfy this use-case.  But I confess I do not understand
what cases there are that meet these two conditions.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.