March 2012 - vip - lists.icann.org

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 10, 2012

March 10, 2012

Hi Shawn, On Mar 8, 2012, at 8:42 AM, Shawn Steele wrote: > How do these tables stay in-sync? I mean, what happens when it disagrees with what is actually in the DNS zone files? I think the simple answer is that is registry policy, and varies from zone-to-zone. It is not something where a specific approach needs to be harmonised. For the typical use case, the registry consults with the IDN table at registration time to compute the set of variants. Then, based on a specific domain's policy, the set would typically be recorded in the registry system (as delegated, reserved, blocked, etc.). I imagine if the table changed on which the registry based its policy, it would need its own procedures for dealing with that, but that would be outside the scope of the specification. Some may opt to only use the changed set on new registrations and grandfather in the old ones, depending on the reason why the maintain variants. kim

1 0

Draft on IDN Tables in XML
by Kim Davies March 8, 2012

March 8, 2012

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

4 6

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 7, 2012

March 7, 2012

Hi Thomas, On Mar 1, 2012, at 12:21 PM, Thomas Roessler wrote: A few quick comments on the XML format level upon skimming this (mostly nit-picking): - you don't seem to identify the namespace URI in the normative text, it's hidden in the RNG schema - you don't use the namespace in your examples. - the example in 3.4 doesn't follow the specification for the description element: You either need a CDATA construct, or you need to entity-escape the pointy brackets. - in the specification for the description element, don't talk of "CDATA" as an element. It isn't, but rather a particular way to mark up textual data: http://www.w3.org/TR/xml/#sec-cdata-sect So: The content model for <description> is text; if content includes markup, then CDATA is a convenient method to write that out. - MIME-type -> media type All great fixes I'll work into the next revision. - To the unique identifier point in your issues list -- agree that it might be useful to give the table a unique identifier. I probably wouldn't choose an ID attribute, but would include a "this version" and "latest version" URI in the <meta> section. Sounds good to me. - I may be missing something, but what's the extension model for the @when attribute on <var>? Are certain names there reserved for IANA, and others up for grabs? Want to use URIs for these names, so everybody can coin their own without stepping on others' toes? Something else? Good points, the mechanism for specifying "when" attributes is undefined right now. Right now I know to implement some tables we need to support context in Arabic script strings. I don't know if it is knowable in advance all the types of contextual modes that will need to be supported. If we assume they can not be, then I agree there needs to be a mechanism to keep track of them so the format doesn't extend in competing directions and lose its utility. Hope these are useful, Very, thanks! kim

5 4

Re: [vip] Draft on IDN Tables in XML
by Andrew Sullivan March 7, 2012

March 7, 2012

Hi, On Wed, Mar 07, 2012 at 12:47:36PM +1100, James Mitchell wrote: > 2) The set of code points (or sequences of code points) that are considered equivalent by the registry Could we please not use "equivalent" for this? That word has caused enough trouble already. > The table should not attempt to place rules on the use of code > points within a label as these rules are often non-trivial. One can > easily tell whether a name is registered by performing a DNS lookup > or a WHOIS query for the name. Alternatively a registrar will be > able to notify a potential registrant should a name be considered > "invalid". Withouth rules on the use of code points within a label, the table needs to be supplemented by something else in order to create a complete policy. Where would you want to put those rules? > Further to the above the table should not attempt to define those > variants that are activated/allowed/blocked. An active variant can > be determined from a query to the DNS or WHOIS and these protocols > will have to used considering a variant may have been activated > post-registration. Additionally the rules for determining whether a > variant can be activated are non-trivial. Consider the example > below. See above. Of course they're not trivial. But they need to be expressed somewhere so that one can unambiguously determine whether a string is a candidate to be a U-label in a zone. If you can't determine that, then the policy doesn't actually cover everything it's supposed to. > To avoid the somewhat common mistake of incorrectly defining equivalence I suggest that equivalent sequences of code points are defined in one place. For example > > <char cp="0627"> > <var cp="0625"/> > </char> > <char cp="0625"> >  > </char> > > should be expressed as > > <equivalent> > <char cp="0625"> > <char cp="0627"> > </equivalent> This won't work for cases where the alternatation goes only one way. In Russian, for instance, IE (U+0435) can be used (casually, though not formally) where IO (U+0451) is used; but it is never the case that IO can be used where IE is used. Trivially, in French it is sometimes the case that one substitutes undecorated characters for decorated characters; but you don't do things the opposite way. Now, of course, you might just say, "Do them all in order to avoid confusion." But this is an example where at least some registries have talked about wanting to ensure blocking for some cases and withholding for others; and in that case, "equivalence" is certainly the wrong concept and symmetry is not what you get. Best, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

1 0

Re: [vip] Draft on IDN Tables in XML
by Patrik Fältström March 7, 2012

March 7, 2012

On 7 mar 2012, at 14:21, J-F C. Morfin wrote: > Nothing in protocols forces me to use an UTF-8 keyboard or printer (as long as punycode is supported somewhere down the line, in the IDNA case). As the email from Kim was explicitly tagged with information that it was in charset UTF-8 it is possible for you, and up to you and your tools to do the best of the situation. Patrik

1 0

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 7, 2012

March 7, 2012

Hi James, On Mar 6, 2012, at 5:47 PM, James Mitchell wrote: > I think this work should focus on identifying only: > > 1) The set of code points that can be used for registration > 2) The set of code points (or sequences of code points) that are considered equivalent by the registry > > The table should not attempt to place rules on the use of code points within a label as these rules are often non-trivial. One can easily tell whether a name is registered by performing a DNS lookup or a WHOIS query for the name. Alternatively a registrar will be able to notify a potential registrant should a name be considered "invalid". I'm not sure I understand what you are asking this to rule out. The design goals state the format is not designed to restrict registry policy, rather act as a method of expressing what it is so others can re-use it as they see fit. I don't see the use case where it could be conceived this would be used in place of a DNS or WHOIS lookup. An IDN table confers nothing about what labels are already allocated in a registry. The most value this format can bring is if it can express as many rulesets are possible in relation to IDN policies. If there is a substantial population of IDN tables that can not be expressed with it, I am not sure it is any more beneficial than the current situation. > Further to the above the table should not attempt to define those variants that are activated/allowed/blocked. An active variant can be determined from a query to the DNS or WHOIS and these protocols will have to used considering a variant may have been activated post-registration. Additionally the rules for determining whether a variant can be activated are non-trivial. Consider the example below. > > <char cp="0627"> > <var cp="0625"/> > </char> > > And a registered name of "0627 0627". It is unclear from the definition above whether the label "0627 0625" is valid because it does not describe whether the substitution should have been applied across the whole label or whether it can be applied to one character. This is only a trivial example however I can provide many more complex rules. I think we're in agreement on this. With the above table and the "0627 0627" string, presumanly it would generate a set of 3 variants: ("0627 0625", "0625 0627", "0625 0625"). Now what the registry does with those variants is the registry's business. As we've seen with the JET guidelines, different registries have taken the same base table but resulted in different approaches to which labels are delegated, reserved or otherwise handled. That said, a suggestion has already been made to me that a registry could optionally specify an attribute as to whether a variant would result in blocking, delegation or something else. This doesn't mean a consumer of the table needs to follow that hint if they wish to repurpose the table. > To avoid the somewhat common mistake of incorrectly defining equivalence I suggest that equivalent sequences of code points are defined in one place. For example > > <char cp="0627"> > <var cp="0625"/> > </char> > <char cp="0625"> >  > </char> > > should be expressed as > > <equivalent> > <char cp="0625"> > <char cp="0627"> > </equivalent> What about one-way variants? It seems kind of clumsy to have them specified in potentially two different duplicative ways. I am not sure how common it has been that registries mess up their tables, but you could probably easily lint your table to pick up where equivalence doesn't exist, and fix it if appropriate. kim

1 0

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 1, 2012

March 1, 2012

Hi Mark, Thanks for the comments: On Mar 1, 2012, at 11:43 AM, Mark Davis ☕ wrote: 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> I agree about the need for this functionality, however given the dual role of the <char> element as specifying both membership in the table for eligibility purposes, and as the target for a specific mapping, I am not sure of the best way to do it. If we take this approach, the question becomes how does one express the eligibility of "x" and "y" in a table? Can it be assumed both "x" and "y" are eligible in any context, or should it be assumed "x" is only eligible when followed by "y", and therefore you would need to explicitly write the following to indicate eligibility of both as: <char cp="x"/> <char cp="y"/> <char cp="x y"> <var cp="y x"/> </char> Another alternative would be to completely decouple <char> from <var>, and have var something like <var from-cp="x y" to-cp="y x"/> <char cp="200c"> <var cp="0000"/> </char> I think this would be less prone to errors as simply <char cp="200c"> <var cp=""/> </char> Good idea. <var cp="0673" when="arabic-isolated"/> The spec needs to have an unambiguous way to determine when a character satisifies the 'when' clause. I struggled with how best to handle Arabic contextual forms and I am not really sure the approach used is the right way to do it. What is in there right now feels awfully ad-hoc. I am wondering if there is some other specification that can be leveraged here, but at the same time not making this specification too unwieldy to implement. Even though there are no IDN tables yet (that I am aware of) that utilise some form of context other than those that use Arabic contextual form, I am sure there is potential for it in the future. kim

1 0