punyspace summary

Vint Cerf vint at google.com
Sun May 18 04:17:15 CEST 2008


you forget perhaps that the internet is based on voluntary adoption  
of standards. IETF does not and cannot enforce; and ICANN has limited  
means to do so through SOME contracts with SOME parties but not at  
all levels of DNS nor resellers nor some other operators.

so we just have to write the best technical specifications we can and  
make them available.


On May 15, 2008, at 7:59 PM, JFC Morfin wrote:

> At 16:00 15/05/2008, Vint Cerf wrote:
>> Jefsey, I would recommend against any attempt to sanction any non- 
>> standard uses of punycode. This particular representation should  
>> be applied only to validly derived punycode from permitted unicode  
>> dtrings. V
> Vint,
> unfortunately I did not chose IDNA nor punycode. Yet, this is what  
> we have, sanctioned by RFCs and all the work already done. SHOULD  
> are not technically biding. IMHO we MUST make punycode misuse more  
> complex than possibly rewarding. This calls for some thinking: a  
> warning in the security section cannot be enough when some TM  
> owners will discover they (at random) have to spend much much more  
> to protect their name than others, due to an Internet non-end to  
> end core-process.
> ".su" case (which is not unique as a TLD, and is the general SLD  
> case) shows that the motivation is that users can use extended  
> algorithms, what I name "sunycode" for super punycode. Why would  
> someone do that: greed, fun, hack. We had alt-roots, we cannot  
> afford alt-idns.
> Can we entrust the success of IDNA in the ways IE and Firefox may  
> differently disrespect the RFCs in order to best protect the users.  
> Which TLD Manager is going to guarantee and support names he does  
> not know if they will really work in real life, depending on  
> releases, browsers,  nameserver (as some nameserver softwares will  
> most probably decide to "enforce" the standard) as will most  
> probably do firewalls too.
> We have a problem. IMHO each of its aspects are to be clearly  
> identified and delimited. Then answers must be found together with  
> all the stakeholders.  If we want to match the Nov 08 target, or to  
> have an international consensus to postpone it, I really think this  
> open round must be organised at the ICANN Paris meeting.
> jfc

More information about the Idna-update mailing list