At 04:41 05/02/09, John C Klensin wrote:
>It is perhaps worth noting that the 3490 suggestion that "visual >indications where a domain name contains mixed scripts" may be >problematic as a recommendation for actual implementations: >although inverting them would probably help, the tables for >which characters fall into which of the huge number of scripts >in the world represent far more baggage for an implementation to >carry around than the nameprep/stringprep tables required by >IDNA.
Not necessarily true. The relationship between scripts and blocks in Unicode is fairly straightforward; there are extremely few blocks that contain two real scripts (as opposed to one script and 'neutral' stuff such as punctuation, or one script and unassigned codepoint). The experience from existing implementations is that stringprep/nameprep comes in at something like 100 to 200 KB. Strictly checking for normalization (NFC in the case I implemented) comes in at 40-50 KB. My guess is that script checking could probably be done at something around 10 KB, maybe even less. And the number of scripts around the world isn't really that huge; Unicode at the moment has around 40, and while that doesn't include Egyptian hieroglyhps, is't very comprehensive for what you need for domain names.
By this, I don't want to imply that simple script checking is the way to go. Maybe it is, maybe it isn't.
>Similarly, for an application to check the characters/ scripts >supported by a particular ccTLD, as suggested by one of the >contributors to your blog, is problematic. One would really not >like to carry around a list of ccTLDs and their permitted >characters in an application, first because that could be a very >large set of tables, second because the lists change as ccTLD >policies evolve and tables in deployed applications are >notoriously hard to update, and third because it does nothing >for gTLDs. One could design a bit of protocol that would >permit querying the ccTLD for the accepted character list (or a >protocol similar to that described in >draft-klensin-name-munging-03.txt could be trivially extended), >but that would add overhead and raise issues about authoritative >and authenticated lists and do nothing for third level >subdomains and below.
[You mentioned this yourself on the IDN list, I'll just also mention it here so that it's documented.]
Besides the fact that it seems rather useless to design such a protocol if we already have one: DNS. Because this is only about existing domain names, it's easy: if it resolves, it must have been allowed. The cases where it resolves but wasn't supposed to are due to bugs or security attacks,... that should be addressed by different means.
Regards, Martin.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf