"Eric A. Hall" <ehall <at> ehsco.com> writes: > Anybody know of a web form that does IDNA conversion on-the-fly? Something > that will let me enter the domain name and get the IDNA encoded form back. > I find myself needing to do do some quicky conversions periodically. <http://josefsson.org/idn.php>
On Fri, Feb 28, 2003 at 11:51:52AM -0600, Eric A. Hall <ehall <at> ehsco.com> wrote a message of 11 lines which said: > Anybody know of a web form that does IDNA conversion on-the-fly? Something > that will let me enter the domain name and get the IDNA encoded form back. http://tac.eureg.org/idn.cgi
On 10:29 03/03/03, Stephane Bortzmeyer said: >On Fri, Feb 28, 2003 at 11:51:52AM -0600, > Eric A. Hall <ehall <at> ehsco.com> wrote > a message of 11 lines which said: > > > Anybody know of a web form that does IDNA conversion on-the-fly? Something > > that will let me enter the domain name and get the IDNA encoded form back. > >http://tac.eureg.org/idn.cgi Interesting service. Bravo! May I suggest two few things? 1. could you also report the Unicode version un U+ format? (it would be convenient for characters not supported on the resquester's terminal) 2. I understand that when an xn--ascii string cannot be transcoded the response if first at internal service error and then the copyof the ASCII request. May be an easy thing to fix? Is the code available? Thank you. jfc
Fri, 7 Mar 2003 16:58:11 -0800 (PST)
Message-Id: <200303080058.h280wBZ14683 <at> gamma.isi.edu>
To: IETF-Announce: ;
Subject: [idn] RFC 3491 on Nameprep: A Stringprep Profile for
Internationalized Domain Names (IDN)
Cc: rfc-editor <at> rfc-editor.org, idn <at> ops.ietf.org
From: rfc-editor <at> rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 07 Mar 2003 16:58:10 -0800
Sender: owner-idn <at> ops.ietf.org
Precedence: bulk
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 3491
Title: Nameprep: A Stringprep Profile for
Internationalized Domain Names (IDN)
Author(s): P. Hoffman, M. Blanchet
Status: Standards Track
Date: March 2003
Mailbox: paul.hoffman <at> imc.org, Marc.Blanchet <at> viagenie.qc.ca
Pages: 7
Characters: 10316
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-idn-nameprep-11.txt
(Continue reading)
A new Request for Comments is now available in online RFC libraries.
RFC 3490
Title: Internationalizing Domain Names in Applications
(IDNA)
Author(s): P. Faltstrom, P. Hoffman, A. Costello
Status: Standards Track
Date: March 2003
Mailbox: paf <at> cisco.com, phoffman <at> imc.org,
http://www.nicemice.net/amc/
Pages: 22
Characters: 51943
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-idn-idna-14.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3490.txt
Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire. This document defines
internationalized domain names (IDNs) and a mechanism called
Internationalizing Domain Names in Applications (IDNA) for
handling them in a standard fashion. IDNs use characters drawn from a
large repertoire (Unicode), but IDNA allows the non-ASCII characters
to be represented using only the ASCII characters already allowed in
so-called host names today. This backward-compatible representation
is required in existing protocols like DNS, so that IDNs can be
introduced with no changes to the existing infrastructure. IDNA is
(Continue reading)
A new Request for Comments is now available in online RFC libraries.
RFC 3492
Title: Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)
Author(s): A. Costello
Status: Standards Track
Date: March 2003
Mailbox: http://www.nicemice.net/amc/
Pages: 35
Characters: 67439
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-idn-punycode-03.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3492.txt
Punycode is a simple and efficient transfer encoding syntax designed
for use with Internationalized Domain Names in Applications
(IDNA). It uniquely and reversibly transforms a Unicode string into
an ASCII string. ASCII characters in the Unicode string are
represented literally, and non-ASCII characters are represented by
ASCII characters that are allowed in host name labels (letters,
digits, and hyphens). This document defines a general algorithm
called Bootstring that allows a string of basic code points to
uniquely represent any string of code points drawn from a larger set.
Punycode is an instance of Bootstring that uses particular parameter
(Continue reading)
Domain Names (IDN)
Cc: rfc-editor <at> rfc-editor.org, idn <at> ops.ietf.org
From: rfc-editor <at> rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 07 Mar 2003 16:58:10 -0800
Sender: owner-idn <at> ops.ietf.org
Precedence: bulk
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 3491
Title: Nameprep: A Stringprep Profile for
Internationalized Domain Names (IDN)
Author(s): P. Hoffman, M. Blanchet
Status: Standards Track
Date: March 2003
Mailbox: paul.hoffman <at> imc.org, Marc.Blanchet <at> viagenie.qc.ca
Pages: 7
Characters: 10316
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-idn-nameprep-11.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3491.txt
This document describes how to prepare internationalized domain name
(Continue reading)
Hello Simon,
Very nice to put up such a script.
It would be great if the default page was served as UTF-8.
That way, on any recent browser, any user can just copy/paste
or type in their idn and submit the query, without having to
worry about encoding issues.
Using various different encodings the way you do is exposing
your system internals in a way the Web was designed (and is
implemented) to abstract from.
The 'force charset to' drop-down menu is particularly dangerous,
because it does not force the browser to send the characters
that the user has pasted or input to the server in that encoding,
it just forces the server to MISinterpret the octets that the
browser sent.
At the top of the page, you write:
Report problems to bug-libidn <at> gnu.org, but first please make sure your
browser really is encoding the data you type in the charset you select.
If not, incorrect output or an error is the proper response.
This is heavily backwards. The browser will do the right thing if
you just allow it to do so, and don't allow the user to mess
around with it.
Also, some browsers tend to send named or numeric character references
when characters in a text field are outside of the encoding of the
(Continue reading)
Simon,
Let me make one additional suggestion, which is sort of
orthogonal to Martin's... It would be useful, as an alternative
to UTF-8 and the other encodings you support, to be able to put
in a string of characters as a list of items in U+nnnn form.
You show that form in your debugging option, but, if the
characters going in don't match what you produce, there is no
obvious way to provide them. I'm particularly concerned here
about characters my browser has no way to render (e.g.,
appropriate fonts not installed, etc.)
The script/web page itself is much appreciated.
thanks,
john
--On Saturday, 08 March, 2003 15:31 -0500 Martin Duerst
<duerst <at> w3.org> wrote:
> Hello Simon,
>
> Very nice to put up such a script.
>
> It would be great if the default page was served as UTF-8.
> That way, on any recent browser, any user can just copy/paste
> or type in their idn and submit the query, without having to
> worry about encoding issues.
>
> Using various different encodings the way you do is exposing
(Continue reading)Martin Duerst <duerst <at> w3.org> writes: > Hello Simon, > > Very nice to put up such a script. I believe I have fixed the problems you mention, thanks for taking the time to point them out. > It would be great if the default page was served as UTF-8. > That way, on any recent browser, any user can just copy/paste > or type in their idn and submit the query, without having to > worry about encoding issues. The page is served in the charset you select. Chose UTF-8 if you want UTF-8. Only supporting UTF-8 would restrict the page's usefulness. Standards compliant browsers handle charset conversions in copy/paste. > Using various different encodings the way you do is exposing > your system internals in a way the Web was designed (and is > implemented) to abstract from. > > The 'force charset to' drop-down menu is particularly dangerous, > because it does not force the browser to send the characters > that the user has pasted or input to the server in that encoding, > it just forces the server to MISinterpret the octets that the > browser sent. > > At the top of the page, you write: > Report problems to bug-libidn <at> gnu.org, but first please make sure your(Continue reading)
RSS Feed1 | |
|---|---|
1 | |
1 | |
1 | |
2 | |
6 | |
4 | |
88 | |
271 | |
1 | |
8 | |
23 | |
6 | |
4 | |
2 | |
1 | |
3 | |
2 | |
19 | |
1 | |
4 | |
60 | |
1 | |
4 | |
2 | |
2 | |
13 | |
27 | |
98 | |
16 | |
22 | |
31 | |
65 | |
97 | |
207 | |
24 | |
60 | |
211 | |
206 | |
51 |
