[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[anewton@ecotroph.net: [Ietf-not43] IDN's and IRIS]



IRIS is one of the proposed protocols (in the IETF CRISP Working
Group) to replace whois.
--- Begin Message --- The discussion yesterday on IDN's proved quite useful and from it there probably need to be a few tweaks to the IDN support in IRIS.

But first, some basic assumptions (I am not an IDN expert, so forgive when I mess this up):

1) The IDN process, in simple terms, goes from it's Unicode orginal form through a process called nameprep and then a second process called punycode. The punycode process outputs 7-bit domains that are compatible with legacy software. So...

  Unicode ---------> Nameprep ----------> Punycode
           (lossy)             (lossless)

At the output of nameprep is where certain judgements are made with regard to code point equivalences, thus creating these things called domain variants. Domain variants are perfectly legal according to the IDN specs. The big difference is that a domain variant may end up in the registration system, but will not end up in a zone file (intentionally).

2) The data stored by the registration system for IDN's maybe the original unicode, the nameprep output, and the legacy 7-bit domain (produced by punycode in this case). Or any combination of the three.

3) Some registrations will be IDN-aware while some will function in a legacy capacity. The major difference being that IDN-aware registration systems undertake special process of xn--* domain names, while legacy systems will not. This does not mean an IDN cannot be registered in a legacy registration system.

All that being said, IRIS accounts for all of these assumptions but could use some tightening up on the specification and a few tweaks.

1) The <domain> (and <domainVariant>)object should contain an optional <idn> (or something) element for domains showing the nameprepped name.

2) The <findDomainsByI18NName> search should incorporate an <exactMatch> qualifier for finding exactly the matching <domain> and <domainVariant> objects associated with a nameprepped name.

3) The cardinality on the references to the <domain> objects in the <domainVariant> object should not be restricted one since it is possible to have multiple variations that are registered.

4) Add a new entity class for IDN's specifically, and specify that the intended format of entity names in the domain-name entity class is 7-bit legacy while the intended format of entity names in the idn and domain-variant entity classes is nameprepped utf-8.

I know there is probably something else I forgot...

Any comments?

-andy

_______________________________________________
Ietf-not43 mailing list
Ietf-not43@xxxxxxxxxxxxxxxxxxxxxx
https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

--- End Message ---