Re: who should be doing IDN filtering

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