[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[firstname.lastname@example.org: [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
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...
Ietf-not43 mailing list
--- End Message ---