Disallowing code points

[Chris Wright]

Martin,

Thanks for the support, clearly I have chosen a bad example (Tatweel), I do agree that there will be 'exceptions' that need to/should be handled (I guess I didn't make that clear) as long as we are not being too liberal in what we decide to grant an 'exception' (in this case I am talking about moving something into the DISALLOW category).

I do have to ask though, WRT Tatweel, you say it is a poor encoding of a historic idea and thus should be disallowed, but as I missing something, what 'harm' could actually be caused by allowing it? I mean I wonder how many other 'historic, bad ideas' remain in the other 90,000 odd PVALID code points that we are not aware of?

I think when talking about moving things into PVALID category we can be a bit more flexible because, as I was trying to get across, registries will do the right thing and it is realistically at the top levels (TLD and 2LD) of the DNS hierarchy where the most 'protection' is needed, if individuals do problematic things with their own domain names, in most cases, they will only be 'hurting', for lack of a better word, themselves.

I understand the point that moving a code point from DISALLOW to PVALID (or even CONTEXT should they remain ;) ) later is relatively easy, where as moving a code point from PVALID to DISALLOW would be difficult if at all possible, especially if we adopt a principle of once a code point is DISALLOWED it is DISALLOWED for ever.

Chris

-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst at it.aoyama.ac.jp] 
Sent: Thursday, 16 July 2009 6:43 PM
To: Chris Wright
Cc: idna-update at alvestrand.no
Subject: Re: Disallowing code points

Hello Chris,

I agree with your mail in general, but Tatweel isn't a historic or dead 
character, it's a (poor) encoding of a typographic variant phenomenon 
from a time where the equation "one byte==one screen cell" was still 
valid (or at least relevant). So disallowing it is absolutely the right 
thing to do.

Regards,    Martin.

On 2009/07/16 15:58, Chris Wright wrote:
> There have been some discussions lately about explicitly disallowing specific code points
>
> I believe that the decisions to disallow specific code points should be kept to an absolute minimum, with strong technically justifiable reasons being required for specific singling out of code points. Again these are in the end 'policy' based decisions that have the potential to impact languages not yet even considered. Registries are required by ICANN/IANA to identify the list of 'characters' that they will allow to be used for registration of domain names in each particular language they would like to support. As per my previous post, Registries are not in the business of doing things to jeopardised the security and stability of their own namespaces. We have the rule system, that is Unicode independent for determining the protocol status of each code point and barring the exceptions, this should be sufficient. If we must make comment on other code points, as per context rules, we should discuss these in the context of Best Common Practices and set forth recommendations 
for
>    registries to follow about which code points that they should consider 'dangerous' and not allow in the definition of their languages.
>
> If we take a single code point like Tatweel, for example, and argue that it's not required to be used anymore and thus should be disallowed, then why not take the whole class of 'dead' languages and disallow those? I have to ask what is the harm in keeping those code points PVALID? At least this is the most flexible approach going forward, and doesn't force us to make decisions now that we may not necessarily have all the information about.  We can publish a BCP discussing the issues with specific code points and educate the registries as to the right thing to do.
>
> Thanks
>
> Chris Wright
> Chief Technology Officer
> AusRegistry Pty Ltd
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp