punyspace summary

[JFC Morfin]

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