[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] who should be doing IDN filtering

At 10:52 AM -0800 2/17/05, Erik van der Poel wrote:
...assuming we can make the language tag available via some dns tricks or some API... 

I don't see that happening.  The IDN working group decided quite
deliberately that domain names would not contain any meta-info like
language tags; they're just text strings.

Right. If you want to re-engineer the IDN bits-on-the-wire protocol in ways that were considered and rejected, feel free to submit a new Internet Draft and see if there is community interest.

First, I cannot speak for Eric here, but it seems to me that "DNS tricks" could include having a (new?) DNS record for the language(s). This would not embed the language tag in the domain label itself. The language tag could be looked up in DNS. (However, I don't like this whole language business anyway, as I indicated in other emails.)

I will say it again: put together a fully-formed proposal. Suggesting anything that requires understand of the DNS beyond simple A records needs and Internet Draft or at least a stable web page. Few people on this mailing list (myself included) are facile with alternate DNS records and the like.

Second, with all due respect, Paul, Adam et al, stringprep and nameprep are 2 amazing pieces of work, but I feel they did not go far enough. I think it is probably worth exploring whether we might map homographs to "base" characters in a new "prep", perhaps another profile of stringprep, to combat the IDN spoofing problem.

The IDN WG did explore that, in depth; it's all in the archives. You may disagree with the conclusion, but please don't minimize the difficult decision-making that went into the protocol design and development.

Third, there seems to be some resistance to continuing IDN work in the IETF space.

Correct. Without some indication of what the work is, how it relates to current protocols, and who will do it, there is resistance. If those three are made clear, the IETF could be much more interested. The same is true for any standards organization.

So, an Internet Draft may not be appropriate.

Internet Drafts are always appropriate, even if the work is being done somewhere else. They give a single place to look for the latest version. Yes, they have formatting and can't-always-publish issues, but they usually work well.

Michel has indicated that the Unicode Consortium is working on the homograph problem, so maybe we can place our bets there.

They are working on specifying the problem and listing some proposed solutions. They are not working on protocol changes.

Alternatively, if some registries (e.g. CJK) wish to have their own rules (i.e. RFC 3743 "JET"), then they can of course do so. I certainly do not want to have a balkanized net, but the degree of balkanization is what matters. I.e. if we only have 2 methods (CJK vs the rest), that's better than having numerous methods.

Many people spent a lot of work trying to get coordination and/or cooperation for creating those lists. So far, the results have been less than stellar. The cultural imperatives and political exigencies make that work very, very difficult despite all the good effort.

--Paul Hoffman, Director
--Internet Mail Consortium