Author marten
Recipients marten, r.david.murray
Date 2013-02-28.04:08:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1362024526.93.0.577080407792.issue17305@psf.upfronthosting.co.za>
In-reply-to
Content
I found an interesting link about this issue:

http://www.unicode.org/faq/idn.html

I also checked a domain name of a client that ends with 'stra├če.de': IE, Firefox and Chrome still use IDNA2003, Opera already does IDNA2008.

In IDNA2008 a lot of characters aren't allowed any longer (like symbols or strike-through letters). But I think this doesn't have any practical relevance, because even while IDNA2003 formally allowed these characters, domain name registries disallowed to register internationalized domain names containing any of these characters.

Most registries restricted the allowed characters very strong, e.g. in the .de zone you cannot use Japanese characters, only those in use within the German language. Some other registries expect you to submit a language property during the domain registration and then only special characters within that language are allowed in the domain name. Also, most registries don't allow to register a domain name that mixes different languages.

So IDNA2008 is the future and hopefully shouldn't break a lot. I don't know of any real life use of the IDNA encoding other than DNS / URLs. I don't know how many existing modules in PyPI working with URLs already make use of the current encodings.idna class but I guess it would cause more work if they all would have to change their code to use name.encode('idna2008') or work with an outdated encoding in the end if unchanged than just silentely switching to IDNA2008 for encodings.idna and add encodings.idna2003 for those who really need the old one for some reason. Reminds me a bit on the range() / xrange() thing. Now the special new xrange() is the default and called just range() again. I guess in some years we'll look back on the IDNA2003/2008 transition the same way.
History
Date User Action Args
2013-02-28 04:08:46martensetrecipients: + marten, r.david.murray
2013-02-28 04:08:46martensetmessageid: <1362024526.93.0.577080407792.issue17305@psf.upfronthosting.co.za>
2013-02-28 04:08:46martenlinkissue17305 messages
2013-02-28 04:08:46martencreate