Draft on IDN Tables in XML
Mark Davis ☕
mark at macchiato.com
Thu Mar 1 20:43:42 CET 2012
A quick note.
A sequence of multiple code points can be specified as a variant of a
single code point. For example, the sequence of "o" then "e" can be
specified as a variant for an "o with umlaut" (U+00F6) as follows:
<char cp="00F6">
<var cp="006F 0065"/>
</char>
It should be possible for a sequence to map to a character or sequence,
rather than restricting to single code points. So the cp in either case
should allow space-delimited hex codes. Eg (where x and y are code points)
<char cp="x y">
<var cp="y x"/>
</char>
===
<char cp="200c">
<var cp="0000"/>
</char>
I think this would be less prone to errors as simply
<char cp="200c">
<var cp=""/>
</char>
===
<var cp="0673" when="arabic-isolated"/>
The spec needs to have an unambiguous way to determine when a character
satisifies the 'when' clause.
------------------------------
Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**
On Thu, Mar 1, 2012 at 11:15, Kim Davies <kim.davies at icann.org> wrote:
> Colleagues,
>
> I have posted a first draft regarding a format that could be used for
> representing IDN Tables in XML to the I-D Repository:
>
> https://datatracker.ietf.org/doc/draft-davies-idntables/
>
> After discussion with a number of folks that felt this would be good work
> to undertake, I've put together a first cut which is not comprehensive, but
> I think goes some way toward a potential format.
>
> Unless there is interest in this being a more formal activity, my
> assumption is to aim to publish the final result independently as an
> Informational RFC. However, the mechanism of publication is secondary to
> coming up with something useful that would benefit TLD registries and other
> implementors. A list of design goals, from the document, is as follows:
>
> • MUST be in a format that can be implemented in a reasonably
> straightforward manner in software;
> • The format SHOULD be able to be checked for formatting errors,
> such that common mistakes can be caught;
> • An IDN Table MUST be able to express the set of valid code points
> that are allowed for registration under a specific zone administrator's
> policies;
> • MUST be able to express computed alternatives to a given domain
> name based on a one-to-one, or one-to-many relationship. These computed
> alternatives are commonly known as "IDN variants";
> • IDN Variants SHOULD be able to be tagged with specific
> categories, such that the categories can be used to support registry policy
> (such as whether to list the computed variant in the zone, or to merely
> block it from registration);
> • IDN Variants MUST be able to stipulated based on contextual
> information. For example, specific variants may only be applicable when
> they follow another specific code point, or when the code point is
> displayed in a specific presentation form;
> • The data contained within the table MUST be unambiguous, such
> that independent implementations that utilise the contents will arrive at
> the same results;
> • IDN Tables SHOULD be suitable for comparison and re-use, such
> that one could easily compare the contents of two or more to see the
> differences, to merge them, and so on.
> • As many existing IDN Tables are practicable SHOULD be able to be
> migrated to the new format with all applicable logic retained.
>
> It is explicitly NOT the goal of this format to:
>
> • Stipulate what code points should be listed in an IDN Table by a
> zone administrator. What registration policies are used for a particular
> zone is outside the scope of this memo.
> • Stipulate what a consumer of an IDN Table must do when they
> determine a particular domain is valid or invalid; or arrive at a set of
> computed IDN variants. IDN Tables are only used to describe rules for
> computing code points, but does not prescribe how registries and other
> parties utilise them.
>
> I'd appreciate any feedback.
>
> cheers,
>
> kim
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20120301/7ad76a59/attachment.html>
More information about the Idna-update
mailing list