I am the technical director here at Verisign responsible for the development of a plug-in to IE, Outlook and Outlook Express to provide support for IDNs ("International Domain Names") As part of our development effort we have packaged an open source C library that can be integrated into application such as FileZilla. This completely free library provides all the necessary encoding/decoding required when taking a domain name in non-ASCII characters and converting it so that DNS can understand it.
Companies such as SmartFTP (http://www.smartftp.com) and CoreFTP (http://www.coreftp.com) have taken this library and have integrated it into their products with others currently under development.
With Netscape, Mozilla, Firebird and Camino now also supporting IDNs natively at the suggestion of a collegue I am posting this request.
IDNs have been implemented in dotCom and dotNet based on the IETF standards and in addition, they are now also supported by the following ccTLDs: dotNo, dotSe, dotDk, dotDe, dotCh, dotCn, dotHk, dotJp, dotKr,
dotTw, dotVn, dotCc and dotTv. Shortly dotLt, dotInfo and dotAt will also be making IDNs available in their respective markets.
Our SDK is available for download by going directly to:
http://www.verisign.com/nds/naming/idn/IDNSDK-1.1.0.zip
Unfortunately the ZIP file includes both our Java as well as C
implementations so you'll need to sort through to pick out the pieces of the C lib.
Finally, we have set up an external FTP Server to faciliate testing and I would be pleased to provide suitable information should it be of value.
Thank you for your consideration.
Adding IDN Support
Moderator: Project members
First of all, posting this on the feature request tracker as well as the old forums and then here isn't necessary since I'm monitoring all trackers/forums.
I'll have to test the library extensivcely and will then decide if it can be used with FileZilla.
On a quick overview, I've noticed that the C example binaries all crash if called with proper parameters. Doesn't look very promising.
Also, I've not found any function which converts a domain name given in 8-bit ASCII or ANSI with special characters (such as German umlauts) into a ascii representation. DomainToAscii (sp?) does only accept a unicode string. Do I have to convert the domain name into unicode first and then convert the domain name to ascii?
I'll have to test the library extensivcely and will then decide if it can be used with FileZilla.
On a quick overview, I've noticed that the C example binaries all crash if called with proper parameters. Doesn't look very promising.
Also, I've not found any function which converts a domain name given in 8-bit ASCII or ANSI with special characters (such as German umlauts) into a ascii representation. DomainToAscii (sp?) does only accept a unicode string. Do I have to convert the domain name into unicode first and then convert the domain name to ascii?
My apologies. I did in fact post my suggestion in a number of areas in hopes that it would be acknowledged and reviewed.
I completely understand that proper due dilligence needs to be performed with our library for its suitability within your environment. My objective was merely to make you aware of the requirement and a potential solution.
We along with our partners we use the C binaries extensively and to date we have not received any reports of instability as you describe. I am sure it is an issue of what is being handed in so if you could provide an example that would be most helpful.
In terms of your last point the input of the routines into our lib has to be Unicode. The ToAscii function is expecting a Unicode string and this is what needs to be passed into us for the encode for our library handles the Unicode toASCII conversion that creates the encoded form of the domain understood by DNS.
My suggestion would be for you to review the following RFCs which I believe will shed light on the requirement beyond my initial email.
http://www.ietf.org/rfc/rfc3490.txt - overview
http://www.ietf.org/rfc/rfc3492.txt - encoding
http://www.ietf.org/rfc/rfc3454.txt - string preparation
http://www.ietf.org/rfc/rfc3491.txt - name preparation
Thanks again.
Gary.
I completely understand that proper due dilligence needs to be performed with our library for its suitability within your environment. My objective was merely to make you aware of the requirement and a potential solution.
We along with our partners we use the C binaries extensively and to date we have not received any reports of instability as you describe. I am sure it is an issue of what is being handed in so if you could provide an example that would be most helpful.
In terms of your last point the input of the routines into our lib has to be Unicode. The ToAscii function is expecting a Unicode string and this is what needs to be passed into us for the encode for our library handles the Unicode toASCII conversion that creates the encoded form of the domain understood by DNS.
My suggestion would be for you to review the following RFCs which I believe will shed light on the requirement beyond my initial email.
http://www.ietf.org/rfc/rfc3490.txt - overview
http://www.ietf.org/rfc/rfc3492.txt - encoding
http://www.ietf.org/rfc/rfc3454.txt - string preparation
http://www.ietf.org/rfc/rfc3491.txt - name preparation
Thanks again.
Gary.
To test thing I've added your library to FileZilla 3. So far it seems to work, I can resolve müller.de using the library.
Though most likely I'll switch to GNU libidn, due to the increased chance that it may already be installed on a lot of linux machines. Also, libidn seems to produce smaller code.
Though most likely I'll switch to GNU libidn, due to the increased chance that it may already be installed on a lot of linux machines. Also, libidn seems to produce smaller code.
We have set up a testing environment for other FTP client developers to test their implementation against. You may try:
등기우편.com xn--ok0b21kpvqjjm.com (Korean)
письмо.com xn--h1aigbl0e.com (Russian)
Under a separate cover I can provide you with username and password for accessing.
I am glad you were able to easily integrate and test the implementation. With that said I am not sure why having the GNULib present on a Linux machine is important for you as I am to sure why you would want this dispenency for a Windows client? Am I missing something? Is there a Linux version that is not listed on the main page?
Our library is specifically focused on C and Windows based client envrionments which is what other application developers have found useful for their implementation. With that said at the end of the day we're really just looking to make sure IDN support is available in as many applications as possible so pick the one which is best for you...but I'm just curious as to your comment in this regard.
Gary.
등기우편.com xn--ok0b21kpvqjjm.com (Korean)
письмо.com xn--h1aigbl0e.com (Russian)
Under a separate cover I can provide you with username and password for accessing.
I am glad you were able to easily integrate and test the implementation. With that said I am not sure why having the GNULib present on a Linux machine is important for you as I am to sure why you would want this dispenency for a Windows client? Am I missing something? Is there a Linux version that is not listed on the main page?
Our library is specifically focused on C and Windows based client envrionments which is what other application developers have found useful for their implementation. With that said at the end of the day we're really just looking to make sure IDN support is available in as many applications as possible so pick the one which is best for you...but I'm just curious as to your comment in this regard.
Gary.
I'm currently working on FileZilla 3 which will be cross platform and should run on Windows, Linux, MacOS etc...
A library which uses the common build utilities (GNU autotools) is another reason why I prefer libidn.
I won't be easy for most linux distributions to create packages for IDNSDK (especially for source code based distributions like Gentoo) since its makefiles are only very basic. I would have to distibute together with FileZilla then. But imo the package managers of the various linux distributions should care about the dependencies and install them and not the application itself.
A library which uses the common build utilities (GNU autotools) is another reason why I prefer libidn.
I won't be easy for most linux distributions to create packages for IDNSDK (especially for source code based distributions like Gentoo) since its makefiles are only very basic. I would have to distibute together with FileZilla then. But imo the package managers of the various linux distributions should care about the dependencies and install them and not the application itself.