Hi Francisco, I came across an edge case that I think could be resolved with a change to the idnmap extension, to extend the <check> response.
It involved a domain that was syntactically valid in both Chinese and Japanese, but was not available for registration in Chinese as a variant domain was already registered. The server returned a <domain:name avail="1"> element in the <check> response, because the domain was available to register in Japanese. However, the client submitted a <create> command with the "zh" in the <idn:table> element, and the server rejected the command. Had the client submitted the <create> command with "ja" in the <idn:table> element (or had it omitted the <idn:data> element altogether) then the command would have succeeded. In this situation, it would be useful for the server to be able to tell the client what IDN tables a domain is valid in, so the client can submit the right table in the <create> command. Here's a possible syntax for this: S: <extension> S: <idn:chkData xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"> S: <idn:cd> S: <idn:aname>xn--espaol-zwa.example.com</dn:aname> S: <idn:tables> S: <idn:table>latn</idn:table> S: <idn:table>es</idn:table> S: </idn:tables> S: </idn:cd> S: </idn:chkData> S: </extension> What do you think? -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
