Closed Bug 157388 Opened 22 years ago Closed 21 years ago

Can't open .nu domains with the danish characters זר�Ein them (gives a "זר�Enu could not be found" error)

Categories

(Core :: Internationalization, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: stig, Assigned: nhottanscp)

References

()

Details

Attachments

(1 file, 1 obsolete file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 BuildID: 2002053012 Can't open .nu domains with the danish characters æøå in them. æøå are alloved in .nu domains and it works in Internet Explorer. Mozilla 1.0 gives the error: "æøå.nu could not be found. Please check the name and try again". Some examples: http://tjæreborg.nu/ http://føtex.nu/ http://ørestadsselskabet.nu/ Reproducible: Always Steps to Reproduce: (try to) go to http://ørestadsselskabet.nu/ Actual Results: Mozilla 1.0 gives the error: "http://ørestadsselskabet.nu/ could not be found. Please check the name and try again". Expected Results: Mozilla should display the content of http://ørestadsselskabet.nu/
WFM, Build 2002071208, Win 98
Attached image Error message (obsolete) —
Gives error message on Mozilla 1.1a+ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020711 However I do not comment, what should have result.
OS: Windows 98 → All
Hmm. Looks like that domain name is with ISO-8859-1 characters or at least it also with ISO-8859-1 characters. [hurtta@pontus hurtta]$ nslookup -q=any 'tjæreborg.nu' Server: ns.tele.fi Address: 193.210.18.18 tj\230reborg.nu internet address = 64.55.105.9 tj\230reborg.nu internet address = 212.181.91.6 Did not checked is that domain name also with some other presentation. (ISO-8859-1 sure is not charset of DNS.)
WFM Mozilla 1.1a+, build 2002071008 (almost 1.1b) on MacOS 9 I can see all 3 webpages, which are reserved by nunames.nu, but not yet assigned. It didn't work when I used my proxy-server proxy.wanadoo.be (Squid/2.4.STABLE7), but it worked when I connect directly to the domain.
Eh ... wait a minute. I check if Mac IE 5 could access the page (after disabling the proxyserver for that one too), and I got a different result http://tjæreborg.nu/ shows me a page from a travle agency. In Mozilla, I can only see a "This domain name, "nu", may still be available for registration!" page. I've seen the same behaviour with the other addresses, and with other domains that I found on nunames.nu (like http://domän.nu/). I think that nunames.nu is doing some browser-sniffing, or maybe Mozilla send the request slighly differently.
I just download'ed the latest trunk build and tried that. My previous testing was only with the Mozilla 1.0 release. It doesn't work correctly in either, but the behavoir is different. In Mozilla 1.0 i get the previous described alert ("זרו.nu could not be found. Please check the name and try again") and in the 2002071404 build i get the nunames.nu-page telling: This domain name, "nu", may still be available for registration!... I don't use proxy in either browser, and it works correctly for me in both Internet Explorer 5.5 and Opera 6.01 (same PC and OS).
Well, view selection source shows links on this bug page as <a href="http://%C3%B8restadsselskabet.nu/">http://ørestadsselskabet.nu/</a> and when viewing cursor over that link on status bar is show that link as it is ISO-8859-1. So these "This domain name ... available for registration" may be that represtation what mozilla uses is not registered. (Odd status bar I filed as bug 157392.) However this is not exactly latst trunk build (Build ID 22071104). IETF working group "idn" (Internationalized Domain Name) is not yet have finished work about subject so there is no standard yet. (See: http://www.ietf.org/html.charters/idn-charter.html )
With Build ID 2002071404, Mozilla 1.1a+ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020714 error message is little different. On that case it is show as UTF-8 text is show as it is ISO-8859-1 charset (or something like that.)
Attachment #91268 - Attachment is obsolete: true
For Url''s mozilla seems use presentation what "Internationalized Domain Names in URIs draft-ietf-idn-uri-02" http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-02.txt gives: "Characters outside the repertoire (alphanum) are encoded by first encoding the characters in UTF-8 [RFC 2279], resulting in a sequence of octets, and then escaping these octets according to the rules defined in [RFC2396]." However for DNS that is further translated "For domain names containing non-ASCII characters, the legal domain names are those for which the ToASCII operation ([IDNA], [Nameprep]; using the unescaped UTF-8 values as input) is successful." "Nameprep: A Stringprep Profile for Internationalized Domain Names" http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-11.txt mostly refers to another draft. "Internationalizing Domain Names in Applications (IDNA)" http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-10.txt says "To allow internationalized labels to be handled by existing applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible Encoding), which can be represented using only ASCII characters but is equivalent to a label containing non-ASCII characters."
Also "Transitional Reflexive ACE -- IDN Transition (IDNX)" http://www.ietf.org/internet-drafts/draft-ietf-idn-dnsii-trace-01.txt suggest: "In other words, the registry should be prepared to accept and resolve multilingual domain requests from users with existing software when they deploy and offer multilingual domain registrations to registrants. " "In general, there are three types of IDN requests that a registry server may receive: 1. Domain in the form of UTF8 encoding; 2. Domain in the form of its local encoding (GB, Big-5, JIS, KSC, ISO8859-1..13 etc.); 3. Domain is in an ACE (ASCII Compatible Encoding) format." So quering UTF8 (instead of ACE) from DNS is not that bad :-) And you can not use ACE (yet) because there is several different suggestion for ACE (ie. different algorithm are proposed.)
Summary: Can't open .nu domains with the danish characters זרו in them (gives a "זרו.nu could not be found" error) → Can't open .nu domains with the danish characters זר�Ein them (gives a "זר�Enu could not be found" error)
Another test-link: http://www.bravå.nu/ None of the other test-links included the character "å" which just might give extra problems ? (I noticed this character changed in the summary when yokoyama@netscape.com added himself to the CC-list!)
-> nhotta
Assignee: darin → nhotta
Component: Networking: HTTP → Internationalization
> 1. Domain in the form of UTF8 encoding; > 2. Domain in the form of its local encoding (GB, Big-5, JIS, KSC, ISO8859-1..13 > etc.); > 3. Domain is in an ACE (ASCII Compatible Encoding) format." Mozilla's current direction is to support #3 (bug 112979). We need to decide how to deal with other cases (but I think #2 would not be supported).
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
.nu now supports IDNA; the test URL of this report is accessible as http://xn--tjreborg-k0a.nu Therefore, I would advise against taking any other approach in Mozilla beyond #3. It is likely that all other major registrars supporting non-ASCII domain names will support IDNA in the very near future.
Maybe this bug should be marked as fixed? All my original example links opens correctly now (and has for some time). It looks a bit weird it says http://xn--tjreborg-k0a.nu in the adressbar and not just http://tjæreborg.nu, but I don't care much about that. There's much more important issues in Mozilla to use the time on :-) For me this bug is fixed.
yeah, WFM too (winxp 20030701 firebird trunk)... i agree that the status bar issue should probably be filed as a separate bug.
This bug worksforme with Windows Seamonkey builds 2004020909
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
*** Bug 162571 has been marked as a duplicate of this bug. ***
V WFM, Mozilla 1.6, Mac OS X.
Status: RESOLVED → VERIFIED
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: