punyspace summary

[JFC Morfin]

At 16:12 15/05/2008, Gervase Markham wrote:
>jefsey wrote:
>>In (1) the split is against the punycode process. It should 
>>therefore be a positive point if there was a very strict document 
>>that would be completed by an IETF (or Unicode, or ICANN) 
>>guaranteed program everyone could use for legal checking of the 
>>nature of an "xn--". The resulting funycodes are public domain and 
>>anyone can build private extensions through Sunycodes (specialised 
>>punycode like process).
>
>What would be the advantage in doing such experiments or building 
>such extensions within the xn-- prefix, as opposed to using another prefix?

Not our cup of tea. Since Anaxagoras we know that nature hates 
emptiness. My architectural rule nr.1 is "if something can be 
developped, is fun, permits to make money, or to hurt someone it will 
be used" - which matches RFC 1958 only principle (except that 
principle everything may change).

It is better to acknowledge the funyspace and reserve it to private 
use (it will be most probably used anyway) that to leave it to 
hackers. Because private sunycodes will react, while punycode only 
will be previsible.

Why? Because I reasonably expect a tremendous extension of graphemes 
with semiotic support and multilingualisation at the semantic strata. 
IDNA is not to be developped for the current ASCII internationalised 
Internet, but for the Multilingual Semantic Internet and I will not 
bet on the ISO 10646 size in 2020.

Your suggestion to use another prefix could be considered. I only 
suggest that using the same prefix for the current and future 
solution is in line with RFC 1958 guidelines. Also, using this empty 
space for something hackers (or existing commercial projects) will 
also need, is a way to protect it as stable for everyone.

jfc