...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.
Actually, I'm not interested in such a DNS record. I was merely trying to point out that Eric's original phrase "dns tricks" could be interpreted differently (i.e. different from Adam's and your interpretation). Maybe Eric could clarify his original email (if he wishes to do so).
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.
It sounds like I upset you (and/or other people), and I'm sorry.
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.
When I first read this a few hours ago, I thought you were slamming the door shut on me, but on closer reading, it seems that that is not the case.
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.
Here again I must apologize to all the parties concerned. My comments were insensitive, and I hope not to repeat this mistake.
Erik
