Draft on IDN Tables in XML

[Ram Mohan]

Kim,

I am not certain registries would want to use an automated/machine-readable
mechanism for importing tables from other registry IDN implementations.
Implementations vary widely from one registry to another, each IDN
implementation often requires hand-verification of allowed code points
combined with business policies.



Let’s try an example:

CDNC regularly publishes and updates the set of valid codepoints in the Han
script, along with contextual and variant generation rules/guidelines.
Publishing those set of rules in this rich format would be useful; however,
registries will still need to manually verify both the codepoints and the
rules for variant generation, and create business rules for allocation and
delegation of applied for strings.



Feels like a nice to have, not a must have.



-Ram



---------------------------------------------------------------------------------

Ram Mohan

(o) +1.215.706.5700 x103  (m) +1.215.431.0958  (f) +1.215.706.5701

rmohan at afilias.info | Skype: gliderpilot30 | Twitter @rmohan123

---------------------------------------------------------------------------------



*From:* Kim Davies [mailto:kim.davies at icann.org]
*Sent:* Monday, March 12, 2012 9:24 AM
*To:* Jaap Akkerhuis
*Cc:* idna-update at alvestrand.no; Dillon, Chris; Abdulrahman I. ALGhadir;
vip at icann.org
*Subject:* Re: Draft on IDN Tables in XML



Hi Jaap,



On Mar 12, 2012, at 3:34 AM, Jaap Akkerhuis wrote:


As far as I know, the idea of the tables have always been to provide
a public central place where the registries could list which
characters they support and which they don't in their registrer
plolicies. It is an "for your information only" registry and meant
for human consumption.

And Kim, do correct me if this isn't the case anymore.



It is certainly correct that the notion of tables is to publicly share
registry policy as it relates to code points that are accepted for
registration. I think, however, it is a bit beyond merely informational, as
a key driver in publishing them has been to allow sharing and re-use by
other registries. Having a machine readable format that allows the tables
to be imported and repurposed aids this greatly.



One of the reasons I feel this is a good initiative is an increasing number
of tables appear to be published as PDF files with various contextual rules
described in paragraphs of normative text. It would be nice to reverse this
trend and have a format rich enough that it can express most if not all
registry policies in a common way using a set of agreeable primitives.



kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20120314/01b089e9/attachment.html>