Parsing the issues and finding a middle ground -- another attempt
Erik van der Poel
erikv at google.com
Wed Mar 4 16:54:38 CET 2009
Yes, there are dangers in allowing local mapping. But the IETF cannot
tell the client implementers what to do in their UI, nor can the IETF
tell registrars what to do in their registration process.
So, we can either avoid talking about local mappings at all, or we can
realize that it is too late, because we have already mentioned them,
so now we need to make recommendations.
On Wed, Mar 4, 2009 at 7:39 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> On Wed, Mar 04, 2009 at 07:20:28AM -0800, Erik van der Poel wrote:
>> One of the most important contexts for URLs/URIs/IRIs is HTML. In that
>> context, I'd prefer to do no mapping, or, if really necessary, only
>> /global/ mapping. We'd have interoperability problems if browsers
>> started performing language-specific (local) mappings to domain names
>> in URLs in HTML.
>> Local mapping might be useful in the URL bar, where browsers accept
>> bare host names (without the leading "http://").
> So the distinction I think you want to make is between (roughly) "user
> types something in" (where local mapping might be allowed) and
> "hostname in some other protocol-using context" (where local mapping
> is not allowed). Is that right?
> If so, I'd like to note that the "user types something in" case is one
> I'm really worried about. We have enough complaints already about
> confusability &c. without applications being explicitly permitted to
> rewrite a substantial number of characters into absolutely any other
> character or even combination of characters (for that's what "local
> mapping" really means).
> It's true that characters that are already covered by the protocol may
> not be mapped. But if there were no significant gaps in what the
> protocol is covering, nobody would be arguing for mapping at all.
> Since how those characters are to be mapped is to be a matter of local
> policy, what we're really saying is that there is a class of
> characters that will be typed by a naïve user into what it thinks is a
> context for name resolution, and there is no way to tell just by
> looking at the protocol what range of results the user might expect.
> I did ask before that we not talk about "resolution" except in the
> absolutely strict sense, and I'm delighted that we went in that
> direction. But I think we have an obligation to users to appreciate
> that they will naturally model their expectations on what they know of
> traditional DNS resolution, and I don't think we should do too much
> violence to that model. In my view, local mapping does a great deal
> of violence to such a model, precisely because the results from
> _exactly the same_ typing can be different in different applications,
> on different machines, in different locale settings, or just from time
> to time.
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update