Here are the page about registration of IDNs under .ir (dot-ir) and .ایران.ir (dot-iran): https://www.nic.ir/Internationalized_Domain_Names (also https://www.nic.ir/IDN works).
The Certificate ID of host 'www.nic.ir' is "55 b6 11 a9 65 c2 02 f8 c2 7f 7a 57 1f e6 49 b9 18 ae 72 17", as it's NOT signed by a trusted authority yet.
Is it possible to get it on the branch too?
Behnam: you are going to have to get someone from nic.ir to either file a bug requesting this, or endorse this bug. For various reasons, we only accept applications from the NICs themselves.
I should add: if you yourself work for nic.ir, you need to find some way of showing me that's true (e.g. a web page on www.nic.ir that says so, or creating a Bugzilla account using a nic.ir email address).
Hereby, I, Behnam Esfahbod, as a member of technical team of IRNIC, TLD Registry of Iran, ask for adding ".ir", the TLD we are responsible for, to the IDN whitelist of Mozilla's network engine, also known as Necko, for use in Firefox, Thunderbird, SeaMonkey, Camino, and any other product from Mozilla Foundation/Corporation, and any other project uses the engine.
Is there anything I should/can do?
Behnam: reading that page, it says that "IDNs are not allowed under dot-ir (.ir) TLD." So why are you asking for it to be added to the list? Is there a plan to change this policy?
I note that you say "Persian domain names (IDNs) are allowed under dot-iran". However, we are not enabling any IDN TLDs until they are in the official ICANN root.
(In reply to comment #5)
That's because we have IDNs under .IRAN.ir, which is what the second section describes. As .IRAN is not a TLD yet, we don't request to add it now. We need .ir in the whitelist to get IDNs under .IRAN.ir work.
You can find out about this rule on section Using Persian Domains.
Ah, OK :-)
You say: "In order to help users with non-standard keyboard, protect against abuse, and bolster security, up to five additional domains that can be confusingly similar (homographs) to the requested domains are also automatically assigned to the applicant. These together with the standard domain constitute the ‘bundle’ of up to six variants."
That's great, but why only six? What if there are more? How are the up to six variants calculated?
What's your policy on ZWJ and ZWNJ? Do these characters end up in the actual domain name, or do people type them but then the browser strips them out before making the DNS request?
(In reply to comment #7)
> You say: "In order to help users with non-standard keyboard, protect against
> abuse, and bolster security, up to five additional domains that can be
> confusingly similar (homographs) to the requested domains are also
> automatically assigned to the applicant. These together with the standard
> domain constitute the ‘bundle’ of up to six variants."
> That's great, but why only six? What if there are more? How are the up to six
> variants calculated?
The variants applies to three set of numbers (Persian 0x06Fx, European ASCII, and Arabic 0x066x), and two set of YEH and KEY (Persian and Arabic). This is not to prevent the homographs attach. This is to help people with non-standard keyboards.
As I said in my last email, we don't have an automated method to prevent homograph attacks, but every registration passes a human check. That's mostly because there's no specific rule to do this. For example, replacing BEH with PEH (which has three dots, two more than BEH) in a word can be a forgery, or can make it a real word. Using a dictionary is helpful, but doesn't work on acronyms.
> What's your policy on ZWJ and ZWNJ? Do these characters end up in the actual
> domain name, or do people type them but then the browser strips them out before
> making the DNS request?
We have two terms to refer to a domain, Normalized and Canonized. In Normalized we replace numbers and KEH and YEH, and don't remove ZWJ/NJ. In Canonized, we remove ZWJ/NJ too. And we display both of these to the user, for each domain name. This is because removing space characters doesn't work in Arabic script, as it does in Latin script. So we allow people to put ZWJ/NJ in the character name, to separate words or make acronyms, and show them the Normalized version in most of the interface. But canonized version is what we make the bundle and their punycodes. Also customers can use the Normalized form in web pages and paper docs, and as IDNA standard says, clients remove ZWJ/NJ before making the punycode. So everybody is happy.
Thank you Gerv. :)
Created attachment 298967 [details] [diff] [review]
Requesting approvals as normal.
BTW, I forgot to say: thanks for the extra info, that sounds fine. Here's a patch :-)
Comment on attachment 298967 [details] [diff] [review]
a=beltzner for 1.9
Comment on attachment 298967 [details] [diff] [review]
approved for 188.8.131.52, a=dveditz for release-drivers
Code-freeze for 184.108.40.206 is tomorrow, Jan 25, so please land ASAP
Gerv checked in on the 1.8 branch
Indeed; sorry for not adding the keyword. Thanks, Dan.
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v <-- all.js
new revision: 3.720; previous revision: 3.719
Thanks a lot Gerv, and others. :)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11pre) Gecko/20080128 BonEcho/18.104.22.168pre:
mozilla@mozilla-qa:~/Desktop/firefox/greprefs$ cat all.js | grep "whitelist.ir"
Verified fixed on the 22.214.171.124 branch; replacing fixed126.96.36.199 keyword with verified188.8.131.52
Verified on trunk with today's builds (Windows, Mac, Linux), by inspecting all.js