IDN Forums - Internationalized Domain Names  
Home | idntools | Advertise on idnforums | Premium Membership

Go Back   IDN Forums - Internationalized Domain Names > Internationalized Domain Names > Internationalized Domain Name News

Internationalized Domain Name News Recent IDN related News

LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 1st December 2008, 12:40 AM
Join Date: Dec 2005
Posts: 7,864
iTrader: (60)
Rep Power: 2188
bwhhisc will become famous soon enoughbwhhisc will become famous soon enoughbwhhisc will become famous soon enoughbwhhisc will become famous soon enoughbwhhisc will become famous soon enoughbwhhisc will become famous soon enoughbwhhisc will become famous soon enoughbwhhisc will become famous soon enough
Tina Dam: Compliance with IDN Technical Requirements

Compliance with IDN Technical Requirements
November 12th, 2008 by Tina Dam
One of the main IDN related topics from the just-finished ICANN meeting in Cairo that I think deserves some additional attention was:

Why Compliance with IDN technical requirements are a necessity on a global scale

Overall compliance with technical standards are important for TLD registry operators in order to keep their TLD stable and secure and in that way function and work well for their consumers and communities. Per ICANN Bylaws, interoperability of the Internet is a core value, which requires that technical standards are complied with. In some instances failure to comply with technical standards will only affects the corresponding TLD in isolation and does not interfere with other TLDs - when moving to the topic of IDN TLDs however this fact changes very quickly.

The following will demonstrate how non-compliance with IDN technical standards in one country or territory has a negative effect on the entire Internet community and not solely on that country/territory.

What history has shown us is that when IDNs are implemented in a manner not consistent with the IDNA protocol and IDN Guidelines it has a very negative effect on the community in general. For example, initially, under some TLDs, IDNs were implemented in a way that allowed the individual users and registrants to pick among characters across scripts when making their . registration. This resulted in visual confusability and phishing attacks.

One specific example of this is, where the “a”’s are Cyrillic characters and the rest are Latin letters. This address is visually the same as (all in Latin letters), but physically, to the computer, these are two different addresses. This is damaging the uniqueness principle of the DNS - probably the most important principle of the DNS and what makes it work in a stable manner.

What further happened as a reaction to these kinds of implementations of IDNs is that application developers that need to implement the IDNA protocol in their application software in order for IDNs to work (for example in order for IDN based web addresses to resolve in a web-browser) did not follow the technical standards either. The reason behind this non-compliance has been an attempt to protect users from issues such as the above mentioned phishing attacks. For example, some browser developers have implemented white-listing of TLDs that have implemented IDNs, where the browser developer decides which TLDs are have implemented IDNs in a safe manner based on criteria set by the browser developer.

As a result the end user is presented a variety of different implementations that aim at introducing security levels that really only can be implemented and need to be implemented at the root and TLD registry level. As a consequence if two TLDs support the same language and script, they also can accept the same 2nd level domains, and vice versa, if one lookup a domain name in Unicode in one TLD then one should be able to use the same software to look up the same Unicode domain name in a different TLD - however this will not always be possible. In other instances application developers have introduced mechanisms that prevent domain names in certain scripts from resolving or otherwise functioning adequately.

If IDN implementations continue down a road of non-compliance with IDN technical requirements, such as those present in the IDNA protocol and the IDN Guidelines, it will not be possible to determine what the level of damage will be for the end-user. The worst scenarios could be one of the following two: either that IDNs will be filled with phishing attacks that IDNs will be of no use and users will be scared of using them, or restrictions in the application layer will be so strict that IDNs will for example not resolve in an adequate and at least not in a stable and secure manner. Either way, this does not provide the community what they have asked for and what we are attempting to provide them with the implementation of IDNs, namely, equal access to the DNS by all languages and scripts.

Other examples can be provided on request. These relate to reasons why the IDNA protocol is under revision and are further documented in RFC4690. In summary the above demonstrates why compliance with the IDN technical standards are of outmost importance, and why we need to find a way of ensuring that such compliance is in place and kept in place for TLD operators with IDNs implemented, regardless of whether it is a second level or top level.
Reply With Quote
  #2 (permalink)  
Old 1st December 2008, 04:33 AM
Rubber Duck's Avatar
Join Date: Sep 2005
Location: Czech Republic (For those of you from USA = Chechnya)
Posts: 15,929
iTrader: (59)
Rep Power: 4496
Rubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura aboutRubber Duck has a spectacular aura about
Re: Tina Dam: Compliance with IDN Technical Requirements

Frankly this is just a lot of limp excuses.

None of the characters that is likely to be implemented under the fast track or indeed any of those going to be fought over by existing registries is likely to be contentious.

The delays make bugger all impact on phishing as most phishing attacks are not IDN related anyway. I would guess those that are less than 1 percent. Of the IDN traffic that is likely to be out there, it mostly going to be dot com or dot CN where nothing she says or does is making any difference in the here and now.

What she should be getting off her fanny and sorting out is way that both IE and FF are manipulating traffic. Mozilla in particular should be publicly humiliated for their assumption that it is their responsibility to decide which traffic goes where.
All offers to sell are void.
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

All times are GMT. The time now is 01:56 AM.

Site Sponsors
Your ad here
buy idns
domain name lawyer
buy t-shirt
מחיר הזהב

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.3.0
Copyright 2005

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54