Mention TLD.

[libidn.git] / doc / libidn.texi

\input texinfo   @c -*- mode: texinfo; coding: us-ascii; -*-
@c This file is part of GNU Libidn.
@c See below for copyright and license.

@setfilename libidn.info
@include version.texi
@settitle GNU Libidn
@finalout

@syncodeindex pg cp

@copying
This manual is last updated @value{UPDATED} for version
@value{VERSION} of GNU Libidn.

Copyright @copyright{} 2002, 2003, 2004 Simon Josefsson.

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Commercial Support", no Front-Cover Texts,
and no Back-Cover Texts.  A copy of the license is included in the
section entitled "GNU Free Documentation License".
@end quotation
@end copying

@dircategory GNU Libraries
@direntry
* libidn: (libidn).     Internationalized string processing library.
@end direntry

@dircategory GNU utilities
@direntry
* idn: (libidn)Invoking idn.            Command line interface to GNU Libidn.
@end direntry

@dircategory Emacs
@direntry
* IDN Library: (libidn)Emacs API.       Emacs API for IDN functions.
@end direntry

@titlepage
@title GNU Libidn
@subtitle Internationalized string processing for the GNU system
@subtitle for version @value{VERSION}, @value{UPDATED}
@author Simon Josefsson
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@contents

@ifnottex
@node Top
@top GNU Libidn

@insertcopying
@end ifnottex

@menu
* Introduction::                How to use this manual.
* Preparation::                 What you should do before using the library.
* Utility Functions::           Unicode transformation utility functions.
* Stringprep Functions::        Stringprep functions.
* Punycode Functions::          Punycode functions.
* IDNA Functions::              IDNA functions.
* TLD Functions::               TLD functions.
* Examples::                    Demonstrate how to use the library.
* Invoking idn::                Command line interface to the library.
* Emacs API::                   Emacs Lisp API for Libidn.
* Acknowledgements::            Whom to blame.

Indices

* Concept Index::
* Function and Variable Index::

Appendices

* Library Copying::             How you can copy and share GNU Libidn.
* Copying This Manual::         How you can copy and share this manual.

@end menu


@node Introduction
@chapter Introduction

GNU Libidn is an implementation of the Stringprep, Punycode and IDNA
specifications defined by the IETF Internationalized Domain Names
(IDN) working group, used for internationalized domain names.  The
package is available under the GNU Lesser General Public License.

The library contains a generic Stringprep implementation that does
Unicode 3.2 NFKC normalization, mapping and prohibitation of
characters, and bidirectional character handling.  Profiles for
Nameprep, iSCSI, SASL and XMPP are included.  Punycode and ASCII
Compatible Encoding (ACE) via IDNA are supported.  A mechanism to
define Top-Level Domain (TLD) specific validation tables, and to
compare strings against those tables, is included.  Default tables for
some TLDs are also included.

The Stringprep API consists of two main functions, one for converting
data from the system's native representation into UTF-8, and one
function to perform the Stringprep processing.  Adding a new
Stringprep profile for your application within the API is
straightforward.  The Punycode API consists of one encoding function
and one decoding function.  The IDNA API consists of the ToASCII and
ToUnicode functions, as well as an high-level interface for converting
entire domain names to and from the ACE encoded form.  The TLD API
consists of one set of functions to extract the TLD name from a domain
string, one set of functions to locate the proper TLD table to use
based on the TLD name, and core functions to validate a string against
a TLD table, and some utility wrappers to perform all the steps in one
call.

The library is used by, e.g., GNU SASL and Shishi to process user
names and passwords.  Libidn can be built into GNU Libc to enable a
new system-wide getaddrinfo flag for IDN processing.

Libidn is developed for the GNU/Linux system, but runs on over 20 Unix
platforms (including Solaris, IRIX, AIX, and Tru64) and Windows.
Libidn is written in C and (parts of) the API is accessible from C,
C++, Emacs Lisp, Python and Java.

@menu
* Getting Started::
* Features::
* Library Overview::
* Supported Platforms::
* Commercial Support::
* Downloading and Installing::
* Bug Reports::
* Contributing::
@end menu

@node Getting Started
@section Getting Started

This manual documents the library programming interface.  All
functions and data types provided by the library are explained.
Included are also examples, and documentation for the command line
tool @file{idn} that provide a quick interface to the library.  The
Emacs Lisp bindings for the library is also discussed.

The reader is assumed to possess basic familiarity with
internationalization concepts and network programming in C or C++.

This manual can be used in several ways.  If read from the beginning
to the end, it gives a good introduction into the library and how it
can be used in an application.  Forward references are included where
necessary.  Later on, the manual can be used as a reference manual to
get just the information needed about any particular interface of the
library.  Experienced programmers might want to start looking at the
examples at the end of the manual (@pxref{Examples}), and then only
read up those parts of the interface which are unclear.

@node Features
@section Features

This library might have a couple of advantages over other libraries
doing a similar job.

@table @asis
@item It's Free Software
Anybody can use, modify, and redistribute it under the terms of the
GNU Lesser General Public License.

@item It's thread-safe
No global state is kept in the library.  All functions are reentrant.

@item It's portable
The code is intended to be written in pure ANSI C89.  It has been
tested on many Unix like operating systems, and Windows.

@item It's modularized
The library is composed of several modules, and the only interaction
between modules is through each modules' public API.  If you only need
one piece of functionality, it is possible to take the files you need
and incorporate them into your own project.

@item It's not bloated
The design of the library is based on the smallest API necessary to
implement the basic functionality.  It has been carefully extended
with a small number of high-level wrappers to make it comfortable to
use the library.  However, it does not implement additional
functionality just for the sake of completeness.

@item It's documented
Sadly, not all software comes with documentation these days.  This one
does.

@end table

@node Library Overview
@section Library Overview

The following illustration show the components that make up Libidn,
and how your application relates to the library.  In the illustration,
various components are shown as boxes.  You see the generic StringPrep
component, the various StringPrep profiles including Nameprep, the
Punycode component, the IDNA component, and the TLD component.  The
arrows indicate aggregation, e.g., IDNA uses Punycode and Nameprep,
and in turn Nameprep uses the generic StringPrep interface.  The
interfaces to all components are available for applications, no
component within the library is hidden from the application.

@image{components}

@node Supported Platforms
@section Supported Platforms

Libidn has at some point in time been tested on the following
platforms.

@enumerate

@item Debian GNU/Linux 3.0 (Woody)
@cindex Debian

GCC 2.95.4 and GNU Make. This is the main development platform.
@code{alphaev67-unknown-linux-gnu}, @code{alphaev6-unknown-linux-gnu},
@code{arm-unknown-linux-gnu}, @code{armv4l-unknown-linux-gnu},
@code{hppa-unknown-linux-gnu}, @code{hppa64-unknown-linux-gnu},
@code{i686-pc-linux-gnu}, @code{ia64-unknown-linux-gnu},
@code{m68k-unknown-linux-gnu}, @code{mips-unknown-linux-gnu},
@code{mipsel-unknown-linux-gnu}, @code{powerpc-unknown-linux-gnu},
@code{s390-ibm-linux-gnu}, @code{sparc-unknown-linux-gnu},
@code{sparc64-unknown-linux-gnu}.

@item Debian GNU/Linux 2.1
@cindex Debian

GCC 2.95.1 and GNU Make. @code{armv4l-unknown-linux-gnu}.

@item Tru64 UNIX
@cindex Tru64

Tru64 UNIX C compiler and Tru64 Make. @code{alphaev67-dec-osf5.1},
@code{alphaev68-dec-osf5.1}.

@item SuSE Linux 7.1
@cindex SuSE

GCC 2.96 and GNU Make. @code{alphaev6-unknown-linux-gnu},
@code{alphaev67-unknown-linux-gnu}.

@item SuSE Linux 7.2a
@cindex SuSE Linux

GCC 3.0 and GNU Make. @code{ia64-unknown-linux-gnu}.

@item SuSE Linux
@cindex SuSE Linux

GCC 3.2.2 and GNU Make.  @code{x86_64-unknown-linux-gnu} (AMD64
Opteron ``Melody'').

@item RedHat Linux 7.2
@cindex RedHat

GCC 2.96 and GNU Make. @code{alphaev6-unknown-linux-gnu},
@code{alphaev67-unknown-linux-gnu}, @code{ia64-unknown-linux-gnu}.

@item RedHat Linux 8.0
@cindex RedHat

GCC 3.2 and GNU Make. @code{i686-pc-linux-gnu}.

@item RedHat Advanced Server 2.1
@cindex RedHat Advanced Server

GCC 2.96 and GNU Make. @code{i686-pc-linux-gnu}.

@item Slackware Linux 8.0.01
@cindex RedHat

GCC 2.95.3 and GNU Make. @code{i686-pc-linux-gnu}.

@item Mandrake Linux 9.0
@cindex Mandrake

GCC 3.2 and GNU Make. @code{i686-pc-linux-gnu}.

@item IRIX 6.5
@cindex IRIX

MIPS C compiler, IRIX Make. @code{mips-sgi-irix6.5}.

@item AIX 4.3.2
@cindex AIX

IBM C for AIX compiler, AIX Make.  @code{rs6000-ibm-aix4.3.2.0}.

@item Microsoft Windows 2000 (Cygwin)
@cindex Windows

GCC 3.2, GNU make. @code{i686-pc-cygwin}.

@item HP-UX 11
@cindex HP-UX

HP-UX C compiler and HP Make. @code{ia64-hp-hpux11.22},
@code{hppa2.0w-hp-hpux11.11}.

@item SUN Solaris 2.8
@cindex Solaris

Sun WorkShop Compiler C 6.0 and SUN Make. @code{sparc-sun-solaris2.8}.

@item SUN Solaris 2.9
@cindex Solaris

Sun Forte Developer 7 C compiler and GNU
Make. @code{sparc-sun-solaris2.9}.

@item NetBSD 1.6
@cindex NetBSD

GCC 2.95.3 and GNU Make. @code{alpha-unknown-netbsd1.6},
@code{i386-unknown-netbsdelf1.6}.

@item OpenBSD 3.1 and 3.2
@cindex OpenBSD

GCC 2.95.3 and GNU Make. @code{alpha-unknown-openbsd3.1},
@code{i386-unknown-openbsd3.1}.

@item FreeBSD 4.7 and 4.8
@cindex FreeBSD

GCC 2.95.4 and GNU Make. @code{alpha-unknown-freebsd4.7},
@code{alpha-unknown-freebsd4.8}, @code{i386-unknown-freebsd4.7},
@code{i386-unknown-freebsd4.8}.

@item MacOS X 10.2 Server Edition
@cindex MacOS X

GCC 3.1 and GNU Make. @code{powerpc-apple-darwin6.5}.

@end enumerate

If you use Libidn on, or port Libidn to, a new platform please report
it to the author.

@node Commercial Support
@section Commercial Support

Commercial support is available for users of GNU Libidn.  The kind of
support that can be purchased may include:

@itemize

@item Implement new features.
Such as country code specific profiling to support a restricted subset
of Unicode.

@item Port Libidn to new platforms.
This could include porting Libidn to an embedded platforms that may
need memory or size optimization.

@item Integrating IDN support in your existing project.

@item System design of components related to IDN.

@end itemize

If you are interested, please write to:

@verbatim
Simon Josefsson Datakonsult
Drottningholmsv. 70
112 42 Stockholm
Sweden

E-mail: simon@josefsson.org
@end verbatim

If your company provide support related to GNU Libidn and would like
to be mentioned here, contact the author (@pxref{Bug Reports}).

@node Downloading and Installing
@section Downloading and Installing
@cindex Installation
@cindex Download

The package can be downloaded from several places, including
@url{http://josefsson.org/libidn/releases/}.  The latest version is
stored in a file, e.g., @samp{libidn-@value{VERSION}.tar.gz} where the
@samp{@value{VERSION}} indicate the highest version number.

The package is then extracted, configured and built like many other
packages that use Autoconf.  For detailed information on configuring
and building it, refer to the @file{INSTALL} file that is part of the
distribution archive.

Here is an example terminal session that download, configure, build
and install the package.  You will need a few basic tools, such as
@samp{sh}, @samp{make} and @samp{cc}.

@example
$ wget -q http://josefsson.org/libidn/releases/libidn-@value{VERSION}.tar.gz
$ tar xfz libidn-@value{VERSION}.tar.gz
$ cd libidn-@value{VERSION}/
$ ./configure
...
$ make
...
$ make install
...
@end example

After that Libidn should be properly installed and ready for use.

@node Bug Reports
@section Bug Reports
@cindex Reporting Bugs

If you think you have found a bug in Libidn, please investigate it and
report it.

@itemize @bullet

@item Please make sure that the bug is really in Libidn, and
preferably also check that it hasn't already been fixed in the latest
version.

@item You have to send us a test case that makes it possible for us to
reproduce the bug.

@item You also have to explain what is wrong; if you get a crash, or
if the results printed are not good and in that case, in what way.
Make sure that the bug report includes all information you would need
to fix this kind of bug for someone else.

@end itemize

Please make an effort to produce a self-contained report, with
something definite that can be tested or debugged.  Vague queries or
piecemeal messages are difficult to act on and don't help the
development effort.

If your bug report is good, we will do our best to help you to get a
corrected version of the software; if the bug report is poor, we won't
do anything about it (apart from asking you to send better bug
reports).

If you think something in this manual is unclear, or downright
incorrect, or if the language needs to be improved, please also send a
note.

Send your bug report to:

@center @samp{bug-libidn@@gnu.org}


@node Contributing
@section Contributing
@cindex Contributing
@cindex Hacking

If you want to submit a patch for inclusion -- from solve a typo you
discovered, up to adding support for a new feature -- you should
submit it as a bug report (@pxref{Bug Reports}).  There are some
things that you can do to increase the chances for it to be included
in the official package.

Unless your patch is very small (say, under 10 lines) we require that
you assign the copyright of your work to the Free Software Foundation.
This is to protect the freedom of the project.  If you have not
already signed papers, we will send you the necessary information when
you submit your contribution.

For contributions that doesn't consist of actual programming code, the
only guidelines are common sense.  Use it.

For code contributions, a number of style guides will help you:

@itemize @bullet

@item Coding Style.
Follow the GNU Standards document (@pxref{top, GNU Coding Standards,,
standards}).

If you normally code using another coding standard, there is no
problem, but you should use @samp{indent} to reformat the code
(@pxref{top, GNU Indent,, indent}) before submitting your work.

@item Use the unified diff format @samp{diff -u}.

@item Return errors.
No reason whatsoever should abort the execution of the library.  Even
memory allocation errors, e.g. when malloc return NULL, should work
although result in an error code.

@item Design with thread safety in mind.
Don't use global variables and the like.

@item Avoid using the C math library.
It causes problems for embedded implementations, and in most
situations it is very easy to avoid using it.

@item Document your functions.
Use comments before each function headers, that, if properly
formatted, are extracted into GTK-DOC web pages.  Don't forget to
update the Texinfo manual as well.

@item Supply a ChangeLog and NEWS entries, where appropriate.

@end itemize

@c **********************************************************
@c *******************  Preparation  ************************
@c **********************************************************
@node Preparation
@chapter Preparation

To use `Libidn', you have to perform some changes to your sources and
the build system.  The necessary changes are small and explained in
the following sections.  At the end of this chapter, it is described
how the library is initialized, and how the requirements of the
library are verified.

A faster way to find out how to adapt your application for use with
`Libidn' may be to look at the examples at the end of this manual
(@pxref{Examples}).

@menu
* Header::
* Initialization::
* Version Check::
* Building the source::
* Autoconf tests::
@end menu

@node Header
@section Header

The library contains a few independent parts, and each part export the
interfaces (data types and functions) in a header file.  You must
include the appropriate header files in all programs using the
library, either directly or through some other header file, like this:

@example
#include <stringprep.h>
@end example

The header files and the functions they define are categorized as
follows:

@table @asis
@item stringprep.h

The low-level stringprep API entry point.  For IDN applications, this
is usually invoked via IDNA. Some applications, specifically non-IDN
ones, may want to prepare strings directly though, and should include
this header file.

The name space of the stringprep part of Libidn is @code{stringprep*}
for function names, @code{Stringprep*} for data types and
@code{STRINGPREP_*} for other symbols.  In addition the same name
prefixes with one prepended underscore are reserved for internal use
and should never be used by an application.

@item punycode.h

The entry point to Punycode encoding and decoding functions.  Normally
punycode is used via the idna.h interface, but some application may
want to perform raw punycode operations.

The name space of the punycode part of Libidn is @code{punycode_*} for
function names, @code{Punycode*} for data types and @code{PUNYCODE_*}
for other symbols.  In addition the same name prefixes with one
prepended underscore are reserved for internal use and should never be
used by an application.

@item idna.h

The entry point to the IDNA functions.  This is the normal entry point
for applications that need IDN functionality.

The name space of the IDNA part of Libidn is @code{idna_*} for
function names, @code{Idna*} for data types and @code{IDNA_*} for
other symbols.  In addition the same name prefixes with one prepended
underscore are reserved for internal use and should never be used by
an application.

@item tld.h

The entry point to the TLD functions.  Normal applications are not
expected to need this functionality, but it is present for
applications that are used by TLDs to validate customer input.

The name space of the TLD part of Libidn is @code{tld_*} for function
names, @code{Tld_*} for data types and @code{TLD_*} for other symbols.
In addition the same name prefixes with one prepended underscore are
reserved for internal use and should never be used by an application.

@end table

@node Initialization
@section Initialization

Libidn is stateless and does not need any initialization.

@node Version Check
@section Version Check

It is often desirable to check that the version of `Libidn' used is
indeed one which fits all requirements.  Even with binary
compatibility new features may have been introduced but due to problem
with the dynamic linker an old version is actually used.  So you may
want to check that the version is okay right after program startup.

@include texi/stringprep_check_version.texi

The normal way to use the function is to put something similar to the
following first in your @code{main}:

@example
  if (!stringprep_check_version (STRINGPREP_VERSION))
    @{
      printf ("stringprep_check_version() failed:\n"
              "Header file incompatible with shared library.\n");
      exit(1);
    @}
@end example

@node Building the source
@section Building the source
@cindex Compiling your application

If you want to compile a source file including e.g. the `idna.h' header
file, you must make sure that the compiler can find it in the
directory hierarchy.  This is accomplished by adding the path to the
directory in which the header file is located to the compilers include
file search path (via the @option{-I} option).

However, the path to the include file is determined at the time the
source is configured.  To solve this problem, `Libidn' uses the
external package @command{pkg-config} that knows the path to the
include file and other configuration options.  The options that need
to be added to the compiler invocation at compile time are output by
the @option{--cflags} option to @command{pkg-config libidn}.  The
following example shows how it can be used at the command line:

@example
gcc -c foo.c `pkg-config libidn --cflags`
@end example

Adding the output of @samp{pkg-config libidn --cflags} to the
compilers command line will ensure that the compiler can find e.g. the
idna.h header file.

A similar problem occurs when linking the program with the library.
Again, the compiler has to find the library files.  For this to work,
the path to the library files has to be added to the library search
path (via the @option{-L} option).  For this, the option
@option{--libs} to @command{pkg-config libidn} can be used.  For
convenience, this option also outputs all other options that are
required to link the program with the `libidn' libarary.  The example
shows how to link @file{foo.o} with the `libidn' library to a program
@command{foo}.

@example
gcc -o foo foo.o `pkg-config libidn --libs`
@end example

Of course you can also combine both examples to a single command by
specifying both options to @command{pkg-config}:

@example
gcc -o foo foo.c `pkg-config libidn --cflags --libs`
@end example

@node Autoconf tests
@section Autoconf tests
@cindex Autoconf tests
@cindex Configure tests

If your project uses Autoconf (@pxref{top, GNU Autoconf,, autoconf})
to check for installed libraries, you might find the following snippet
illustrative.  It add a new @file{configure} parameter
@code{--with-libidn}, and check for @file{idna.h} and @samp{-lidn}
(possibly below the directory specified as the optional argument to
@code{--with-libidn}), and define the @acronym{CPP} symbol
@code{LIBIDN} if the library is found.  The default behaviour is to
search for the library and enable the functionality (that is, define
the symbol) when the library is found, but if you wish to make the
default behaviour of your package be that Libidn is not used (even if
it is installed on the system), change @samp{libidn=yes} to
@samp{libidn=no} on the third line.

@example
AC_ARG_WITH(libidn, AC_HELP_STRING([--with-libidn=[DIR]],
                                [Support IDN (needs GNU Libidn)]),
  libidn=$withval, libidn=yes)
if test "$libidn" != "no"; then
  if test "$libidn" != "yes"; then
    LDFLAGS="$@{LDFLAGS@} -L$libidn/lib"
    CPPFLAGS="$@{CPPFLAGS@} -I$libidn/include"
  fi
  AC_CHECK_HEADER(idna.h,
    AC_CHECK_LIB(idn, stringprep_check_version,
      [libidn=yes LIBS="$@{LIBS@} -lidn"], libidn=no),
    libidn=no)
fi
if test "$libidn" != "no" ; then
  AC_DEFINE(LIBIDN, 1, [Define to 1 if you want IDN support.])
else
  AC_MSG_WARN([Libidn not found])
fi
AC_MSG_CHECKING([if Libidn should be used])
AC_MSG_RESULT($libidn)
@end example

If you require that your users have installed @code{pkg-config} (which
I cannot recommend generally), the above can be done more easily as
follows.

@example
AC_ARG_WITH(libidn, AC_HELP_STRING([--with-libidn=[DIR]],
                                [Support IDN (needs GNU Libidn)]),
  libidn=$withval, libidn=yes)
if test "$libidn" != "no" ; then
  PKG_CHECK_MODULES(LIBIDN, libidn >= 0.0.0, [libidn=yes], [libidn=no])
  if test "$libidn" != "yes" ; then
    libidn=no
    AC_MSG_WARN([Libidn not found])
  else
    libidn=yes
    AC_DEFINE(LIBIDN, 1, [Define to 1 if you want Libidn.])
  fi
fi
AC_MSG_CHECKING([if Libidn should be used])
AC_MSG_RESULT($libidn)
@end example

@c **********************************************************
@c ********************  Utility Functions ******************
@c **********************************************************
@node Utility Functions
@chapter Utility Functions
@cindex Utility Functions

The rest of this library makes extensive use of Unicode characters.
In order to interface this library with the outside world, your
application may need to make various Unicode transformations.

@section Header file @code{stringprep.h}

To use the functions explained in this chapter, you need to include
the file @file{stringprep.h} using:

@example
#include <stringprep.h>
@end example

@section Unicode Encoding Transformation

@include texi/stringprep_unichar_to_utf8.texi
@include texi/stringprep_utf8_to_unichar.texi
@include texi/stringprep_ucs4_to_utf8.texi
@include texi/stringprep_utf8_to_ucs4.texi

@section Unicode Normalization

@include texi/stringprep_ucs4_nfkc_normalize.texi
@include texi/stringprep_utf8_nfkc_normalize.texi

@section Character Set Conversion

@include texi/stringprep_locale_charset.texi
@include texi/stringprep_convert.texi
@include texi/stringprep_locale_to_utf8.texi
@include texi/stringprep_utf8_to_locale.texi


@c **********************************************************
@c ******************  Stringprep Functions *****************
@c **********************************************************
@node Stringprep Functions
@chapter Stringprep Functions
@cindex Stringprep Functions

Stringprep describes a framework for preparing Unicode text strings in
order to increase the likelihood that string input and string
comparison work in ways that make sense for typical users throughout
the world. The stringprep protocol is useful for protocol identifier
values, company and personal names, internationalized domain names,
and other text strings.

@section Header file @code{stringprep.h}

To use the functions explained in this chapter, you need to include
the file @file{stringprep.h} using:

@example
#include <stringprep.h>
@end example

@section Defining A Stringprep Profile

Further types and structures are defined for applications that want to
specify their own stringprep profile.  As these are fairly obscure,
and by necessity tied to the implementation, we do not document them
here.  Look into the @file{stringprep.h} header file, and the
@file{profiles.c} source code for the details.

@section Return Codes

All functions return a code of the @code{Stringprep_rc}
enumerated type:

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_OK = 0}
Successful operation.  This value is guaranteed to always be zero, the
remaining ones are only guaranteed to hold non-zero values, for
logical comparison purposes.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_CONTAINS_UNASSIGNED}
String contain unassigned Unicode code points, which is forbidden by
the profile.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_CONTAINS_PROHIBITED}
String contain code points prohibited by the profile.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_BIDI_BOTH_L_AND_RAL}
String contain code points with conflicting bidirection category.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_BIDI_LEADTRAIL_NOT_RAL}
Leading and trailing character in string not of proper bidirectional
category.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_BIDI_CONTAINS_PROHIBITED}
Contains prohibited code points detected by bidirectional code.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_TOO_SMALL_BUFFER}
Buffer handed to function was too small.  This usually indicate a
problem in the calling application.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_PROFILE_ERROR}
The stringprep profile was inconsistent.  This usually indicate an
internal error in the library.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_FLAG_ERROR}
The supplied flag conflicted with profile.  This usually indicate a
problem in the calling application.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_UNKNOWN_PROFILE}
The supplied profile name was not known to the library.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_NFKC_FAILED}
The Unicode NFKC operation failed.  This usually indicate an internal
error in the library.
@end deftypevr

@deftypevr {Return code} {Stringprep_rc} {STRINGPREP_MALLOC_ERROR}
The @code{malloc} was out of memory.  This is usually a fatal error.
@end deftypevr

@section Control Flags

@deftypevr {Stringprep flags} {Stringprep_profile_flags} {STRINGPREP_NO_NFKC}
Disable the NFKC normalization, as well as selecting the non-NFKC case
folding tables.  Usually the profile specifies BIDI and NFKC settings,
and applications should not override it unless in special situations.
@end deftypevr

@deftypevr {Stringprep flags} {Stringprep_profile_flags} {STRINGPREP_NO_BIDI}
Disable the BIDI step.  Usually the profile specifies BIDI and NFKC
settings, and applications should not override it unless in special
situations.
@end deftypevr

@deftypevr {Stringprep flags} {Stringprep_profile_flags} {STRINGPREP_NO_UNASSIGNED}
Make the library return with an error if string contains unassigned
characters according to profile.
@end deftypevr

@section Core Functions

@include texi/stringprep_4i.texi
@include texi/stringprep_4zi.texi
@include texi/stringprep.texi
@include texi/stringprep_profile.texi

@section Stringprep Profile Macros

@deftypefun {int} stringprep_nameprep_no_unassigned (char * @var{in}, int @var{maxlen})

@var{in}: input/ouput array with string to prepare.

@var{maxlen}: maximum length of input/output array.

Prepare the input UTF-8 string according to the nameprep profile.  The
AllowUnassigned flag is false, use @code{stringprep_nameprep} for
true AllowUnassigned.  Returns 0 iff successful, or an error code.
@end deftypefun

@deftypefun {int} stringprep_iscsi (char * @var{in}, int @var{maxlen})

@var{in}: input/ouput array with string to prepare.

@var{maxlen}: maximum length of input/output array.

Prepare the input UTF-8 string according to the draft iSCSI stringprep
profile.  Returns 0 iff successful, or an error code.
@end deftypefun

@deftypefun {int} stringprep_plain (char * @var{in}, int @var{maxlen})

@var{in}: input/ouput array with string to prepare.

@var{maxlen}: maximum length of input/output array.

Prepare the input UTF-8 string according to the draft SASL ANONYMOUS
profile.  Returns 0 iff successful, or an error code.
@end deftypefun

@deftypefun {int} stringprep_xmpp_nodeprep (char * @var{in}, int @var{maxlen})

@var{in}: input/ouput array with string to prepare.

@var{maxlen}: maximum length of input/output array.

Prepare the input UTF-8 string according to the draft XMPP node
identifier profile.  Returns 0 iff successful, or an error code.
@end deftypefun

@deftypefun {int} stringprep_xmpp_resourceprep (char * @var{in}, int @var{maxlen})

@var{in}: input/ouput array with string to prepare.

@var{maxlen}: maximum length of input/output array.

Prepare the input UTF-8 string according to the draft XMPP resource
identifier profile.  Returns 0 iff successful, or an error code.
@end deftypefun

@c **********************************************************
@c *******************  Punycode Functions ******************
@c **********************************************************
@node Punycode Functions
@chapter Punycode Functions
@cindex Punycode Functions

Punycode is a simple and efficient transfer encoding syntax designed
for use with Internationalized Domain Names in Applications. 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). A general algorithm called Bootstring 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 values, appropriate for IDNA.

@section Header file @code{punycode.h}

To use the functions explained in this chapter, you need to include
the file @file{punycode.h} using:

@example
#include <punycode.h>
@end example

@section Return Codes

All functions return a code of the @code{Punycode_status} enumerated
type:

@deftypevr {Return code} {Punycode_status} {PUNYCODE_SUCCESS = 0}
Successful operation.  This value is guaranteed to always be zero, the
remaining ones are only guaranteed to hold non-zero values, for
logical comparison purposes.
@end deftypevr

@deftypevr {Return code} {Punycode_status} {PUNYCODE_BAD_INPUT}
Input is invalid.
@end deftypevr

@deftypevr {Return code} {Punycode_status} {PUNYCODE_BIG_OUTPUT}
Output would exceed the space provided.
@end deftypevr

@deftypevr {Return code} {Punycode_status} {PUNYCODE_OVERFLOW}
Input needs wider integers to process.
@end deftypevr

@section Unicode Code Point Data Type

The punycode function uses a special type to denote Unicode code
points.  It is guaranteed to always be a 32 bit unsigned integer.

@deftypevr {Punycode Unicode code point} uint32_t punycode_uint
A unsigned integer that hold Unicode code points.
@end deftypevr

@section Core Functions

Note that the current implementation will fail if the
@code{input_length} exceed 4294967295 (the size of
@code{punycode_uint}).  This restriction may be removed in the future.
Meanwhile applications are encouraged to not depend on this problem,
and use @code{sizeof} to initialize @code{input_length} and
@code{output_length}.

The functions provided are the following two entry points:

@include texi/punycode_encode.texi
@include texi/punycode_decode.texi

@c **********************************************************
@c ********************* IDNA Functions *********************
@c **********************************************************
@node IDNA Functions
@chapter IDNA Functions
@cindex IDNA Functions

Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire. The IDNA document defines
internationalized domain names (IDNs) and a mechanism called 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
only meant for processing domain names, not free text.

@section Header file @code{idna.h}

To use the functions explained in this chapter, you need to include
the file @file{idna.h} using:

@example
#include <idna.h>
@end example

@section Return Codes

All functions return a exit code:

@deftypevr {Return code} {Idna_rc} {IDNA_SUCCESS = 0}
Successful operation.  This value is guaranteed to always be zero, the
remaining ones are only guaranteed to hold non-zero values, for
logical comparison purposes.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_STRINGPREP_ERROR
Error during string preparation.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_PUNYCODE_ERROR
Error during punycode operation.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_CONTAINS_NON_LDH
For IDNA_USE_STD3_ASCII_RULES, indicate that the string contains
non-LDH ASCII characters.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_CONTAINS_MINUS
For IDNA_USE_STD3_ASCII_RULES, indicate that the string contains a
leading or trailing hyphen-minus (U+002D).
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_INVALID_LENGTH
The final output string is not within the (inclusive) range 1 to 63
characters.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_NO_ACE_PREFIX
The string does not contain the ACE prefix (for ToUnicode).
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_ROUNDTRIP_VERIFY_ERROR
The ToASCII operation on output string does not equal the input.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_CONTAINS_ACE_PREFIX
The input contains the ACE prefix (for ToASCII).
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_ICONV_ERROR
Could not convert string in locale encoding.
@end deftypevr

@deftypevr {Return code} {Idna_rc} IDNA_MALLOC_ERROR
Could not allocate buffer (this is typically a fatal error).
@end deftypevr

@section Control Flags

The IDNA @code{flags} parameter can take on the following values, or a
bit-wise inclusive or of any subset of the parameters:

@deftypevr {Return code} {Idna_flags} IDNA_ALLOW_UNASSIGNED
Allow unassigned Unicode code points.
@end deftypevr

@deftypevr {Return code} {Idna_flags} IDNA_USE_STD3_ASCII_RULES
Check output to make sure it is a STD3 conforming host name.
@end deftypevr

@section Prefix String

@deftypevr {Macro} {#define} IDNA_ACE_PREFIX
String with the official IDNA prefix, @code{xn--}.
@end deftypevr

@section Core Functions

The idea behind the IDNA function names are as follows: the
@code{idna_to_ascii_4i} and @code{idna_to_unicode_44i} functions are
the core IDNA primitives.  The @code{4} indicate that the function
takes UCS-4 strings (i.e., Unicode code points encoded in a 32-bit
unsigned integer type) of the specified length.  The @code{i} indicate
that the data is written ``inline'' into the buffer.  This means the
caller is responsible for allocating (and deallocating) the string,
and providing the library with the allocated length of the string.
The output length is written in the output length variable.  The
remaining functions all contain the @code{z} indicator, which means
the strings are zero terminated.  All output strings are allocated by
the library, and must be deallocated by the caller.  The @code{4}
indicator again means that the string is UCS-4, the @code{8} means the
strings are UTF-8 and the @code{l} indicator means the strings are
encoded in the encoding used by the current locale.

The functions provided are the following entry points:

@include texi/idna_to_ascii_4i.texi
@include texi/idna_to_unicode_44i.texi

@section Simplified ToASCII Interface

@include texi/idna_to_ascii_4z.texi
@include texi/idna_to_ascii_8z.texi
@include texi/idna_to_ascii_lz.texi

@section Simplified ToUnicode Interface

@include texi/idna_to_unicode_4z4z.texi
@include texi/idna_to_unicode_8z4z.texi
@include texi/idna_to_unicode_8z8z.texi
@include texi/idna_to_unicode_8zlz.texi
@include texi/idna_to_unicode_lzlz.texi


@c **********************************************************
@c ********************** TLD Functions *********************
@c **********************************************************
@node TLD Functions
@chapter TLD Functions
@cindex TLD Functions

Organizations that manage some Top Level Domains (@acronym{TLD}s) have
published tables with characters they accept within the domain.  The
reason may be to reduce complexity that come from using the full
Unicode range, and to protect themselves from future (backwards
incompatible) changes in the IDN or Unicode specifications.  Libidn
implement an infrastructure for defining and checking strings against
such tables.  Libidn also ship some tables from @acronym{TLD}s that we
have managed to get permission to use them from.  Because these tables
are even less static than Unicode or StringPrep tables, it is likely
that they will be updated from time to time (even in backwards
incompatibe ways).  The Libidn interface provide a ``version'' field
for each @acronym{TLD} table, which can be compared for equality to
guarantee the same operation over time.

From a design point of view, you can regard the @acronym{TLD} tables
for IDN as the ``localization'' step that come after the
``internationalization'' step provided by the IETF standards.

@section Header file @code{tld.h}

To use the functions explained in this chapter, you need to include
the file @file{tld.h} using:

@example
#include <tld.h>
@end example

@section Return Codes

Most functions return a exit code:

@deftypevr {Return code} {Tld_rc} {TLD_SUCCESS = 0}
Successful operation.  This value is guaranteed to always be zero, the
remaining ones are only guaranteed to hold non-zero values, for
logical comparison purposes.
@end deftypevr

@deftypevr {Return code} {Tld_rc} TLD_INVALID
Invalid character found.
@end deftypevr

@deftypevr {Return code} {Tld_rc} TLD_NODATA
No input data was provided.
@end deftypevr

@deftypevr {Return code} {Tld_rc} TLD_MALLOC_ERROR
Error during memory allocation.
@end deftypevr

@deftypevr {Return code} {Tld_rc} TLD_ICONV_ERROR
Error during iconv string conversion.
@end deftypevr

@deftypevr {Return code} {Tld_rc} TLD_NOTLD
No top-level domain found in domain string.
@end deftypevr

@c @section Data Types
@c
@c @deftp {Data type} {Tld_table_element} @var{start} @var{end}
@c @example
@c /* Interval of valid code points in the TLD. */
@c struct Tld_table_element
@c @{
@c   uint32_t start;            /* Start of range. */
@c   uint32_t end;              /* End of range, end == start if single. */
@c @};
@c typedef struct Tld_table_element Tld_table_element;
@c @end example
@c This @code{struct} contain the @var{start} and @var{end} positions
@c (inclusive) of a range.  If the range is a single (i.e., starts and
@c ends in the same character), then set @var{end} to the same as
@c @var{start}.  This structure is normally used as an array.
@c @end deftp
@c 
@c @deftp {Data type} {Tld_table} @var{name} @var{version} @var{nvalid} @var{valid}
@c @example
@c /* List valid code points in a TLD. */
@c struct Tld_table
@c @{
@c   char *name;                        /* TLD name, e.g., "no". */
@c   char *version;             /* Version string from TLD file. */
@c   size_t nvalid;             /* Number of entries in data. */
@c   Tld_table_element *valid[];        /* Sorted array of valid code points. */
@c @};
@c typedef struct Tld_table Tld_table;
@c @end example
@c In this @code{struct}, the @var{name} field is a string (@samp{char*})
@c indicating the TLD name (e.g., ``no'').  The @var{version} field is a
@c string (@samp{char*}) containing a free form humanly readable string
@c that can be used for equality comparison to compare different versions
@c of the table.  The @var{nvalid} field indicate how many entries there
@c are in @var{valid}, which brings us finally to @var{valid} that
@c contain the actual code points that are valid for this TLD (see
@c @code{Tld_table_element} above).
@c @end deftp

@section Core Functions

@include texi/tld_check_4t.texi
@include texi/tld_check_4tz.texi

@section Utility Functions

@include texi/tld_get_4.texi
@include texi/tld_get_4z.texi
@include texi/tld_get_z.texi
@include texi/tld_get_table.texi
@include texi/tld_default_table.texi

@section High-Level Wrapper Functions

@include texi/tld_check_4.texi
@include texi/tld_check_4z.texi
@include texi/tld_check_8z.texi
@include texi/tld_check_lz.texi

@c **********************************************************
@c ***********************  Examples  ***********************
@c **********************************************************
@node Examples
@chapter Examples
@cindex Examples

This chapter contains example code which illustrate how `Libidn' can
be used when writing your own application.

@menu
* Example 1::           Example using stringprep.
* Example 2::           Example using punycode.
* Example 3::           Example using IDNA ToASCII.
* Example 4::           Example using IDNA ToUnicode.
* Example 5::           Example using TLD checking.
@end menu

@node Example 1
@section Example 1

This example demonstrates how the stringprep functions are used.

@verbatiminclude ../examples/example.c

@node Example 2
@section Example 2

This example demonstrates how the punycode functions are used.

@verbatiminclude ../examples/example2.c

@node Example 3
@section Example 3

This example demonstrates how the library is used to convert
internationalized domain names into ASCII compatible names.

@verbatiminclude ../examples/example3.c

@node Example 4
@section Example 4

This example demonstrates how the library is used to convert ASCII
compatible names to internationalized domain names.

@verbatiminclude ../examples/example4.c

@node Example 5
@section Example 5

This example demonstrates how the library is used to check a string
for invalid characters within a specific TLD.

@verbatiminclude ../examples/example5.c

@c **********************************************************
@c *********************  Invoking idn  *********************
@c **********************************************************
@node Invoking idn
@chapter Invoking idn

@pindex idn
@cindex invoking @command{idn}
@cindex command line

@section Name

GNU Libidn (idn) -- Internationalized Domain Names command line tool

@section Description
@code{idn} allows internationalized string preparation
(@samp{stringprep}), encoding and decoding of punycode data, and IDNA
ToASCII/ToUnicode operations to be performed on the command line.

If strings are specified on the command line, they are used as input
and the computed output is printed to standard output @code{stdout}.
If no strings are specified on the command line, the program read
data, line by line, from the standard input @code{stdin}, and print
the computed output to standard output.  What processing is performed
(e.g., ToASCII, or Punycode encode) is indicated by options.  If any
errors are encountered, the execution of the applications is aborted.

To process a string that starts with @code{-}, for example
@code{-foo}, use @code{--} to signal the end of parameters, as in
@code{idn --quiet -a -- -foo}.

@section Options
@code{idn} recognizes these commands:

@verbatim
  -h, --help               Print help and exit

  -V, --version            Print version and exit

  -s, --stringprep         Prepare string according to nameprep profile

  -d, --punycode-decode    Decode Punycode

  -e, --punycode-encode    Encode Punycode

  -a, --idna-to-ascii      Convert to ACE according to IDNA (default)

  -u, --idna-to-unicode    Convert from ACE according to IDNA

      --allow-unassigned   Toggle IDNA AllowUnassigned flag  (default=off)

      --usestd3asciirules  Toggle IDNA UseSTD3ASCIIRules flag  (default=off)

  -t, --tld                Check string for TLD specific rules
                             Only for --idna-to-ascii and --idna-to-unicode
                             (default=on)

  -p, --profile=STRING     Use specified stringprep profile instead
                             Valid stringprep profiles are `Nameprep',
                             `iSCSI', `Nodeprep', `Resourceprep', `trace', and
                             `SASLprep'.

      --debug              Print debugging information  (default=off)

      --quiet              Silent operation  (default=off)
@end verbatim

@section Environment Variables

The @var{CHARSET} environment variable can be used to override what
character set to be used for decoding incoming data (i.e., on the
command line or on the standard input stream), and to encode data to
the standard output.  If your system is set up correctly, however, the
application will guess which character set is used automatically.
Example usage:

@example
$ CHARSET=ISO-8859-1 idn --punycode-encode
...
@end example

@section Examples

Standard usage, reading input from standard input:

@example
jas@@latte:~$ idn
libidn 0.3.5
Copyright 2002, 2003 Simon Josefsson.
GNU Libidn comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Libidn under the terms of
the GNU Lesser General Public License.  For more information
about these matters, see the file named COPYING.LIB.
Type each input string on a line by itself, terminated by a newline character.
r@"aksm@"org@aa{}s.se
xn--rksmrgs-5wao1o.se
jas@@latte:~$
@end example

Reading input from command line, and disabling copyright and license
information:

@example
jas@@latte:~$ idn --quiet r@"aksm@"org@aa{}s.se bl@aa{}b@ae{}rgr@o{}d.no
xn--rksmrgs-5wao1o.se
xn--blbrgrd-fxak7p.no
jas@@latte:~$
@end example

Accessing a specific StringPrep profile directly:

@example
jas@@latte:~$ idn --quiet --profile=SASLprep --stringprep te@ss{}t@ordf{}
te@ss{}ta
jas@@latte:~$
@end example

@section Troubleshooting

Getting character data encoded right, and making sure Libidn use the
same encoding, can be difficult.  The reason for this is that most
systems encode character data in more than one character encoding,
i.e., using @code{UTF-8} together with @code{ISO-8859-1} or
@code{ISO-2022-JP}.  This problem is likely to continue to exist until
only one character encoding come out as the evolutionary winner, or
(more likely, at least to some extents) forever.

The first step to troubleshooting character encoding problems with
Libidn is to use the @samp{--debug} parameter to find out which
character set encoding @samp{idn} believe your locale uses.

@example
jas@@latte:~$ idn --debug --quiet ""
system locale uses charset `UTF-8'.

jas@@latte:~$
@end example

If it prints @code{ANSI_X3.4-1968} (i.e., @code{US-ASCII}), this
indicate you have not configured your locale properly.  To configure
the locale, you can, for example, use @samp{LANG=sv_SE.UTF-8; export
LANG} at a @code{/bin/sh} prompt, to set up your locale for a Swedish
environment using @code{UTF-8} as the encoding.

Sometimes @samp{idn} appear to be unable to translate from your system
locale into @code{UTF-8} (which is used internally), and you get an
error like the following:

@example
jas@@latte:~$ idn --quiet foo
idn: could not convert from ISO-8859-1 to UTF-8.
jas@@latte:~$
@end example

The simplest explanation is that you haven't installed the
@samp{iconv} conversion tools.  You can find it as a standalone
library in @acronym{GNU} Libiconv
(@uref{http://www.gnu.org/software/libiconv/}).  On many
@acronym{GNU}/Linux systems, this library is part of the system, but
you may have to install additional packages (e.g., @samp{glibc-locale}
for Debian) to be able to use it.

Another explanation is that the error is correct and you are feeding
@samp{idn} invalid data.  This can happen inadvertently if you are not
careful with the character set encodings you use.  For example, if
your shell run in a @code{ISO-8859-1} environment, and you invoke
@samp{idn} with the @samp{CHARSET} environment variable as follows,
you will feed it @code{ISO-8859-1} characters but force it to believe
they are @code{UTF-8}.  Naturally this will lead to an error, unless
the byte sequences happen to be parsable as @code{UTF-8}.  Note that
even if you don't get an error, the output may be incorrect in this
situation, because @code{ISO-8859-1} and @code{UTF-8} does not in
general encode the same characters as the same byte sequences.

@example
jas@@latte:~$ idn --quiet --debug ""
system locale uses charset `ISO-8859-1'.
 
jas@@latte:~$ CHARSET=UTF-8 idn --quiet --debug r@"aksm@"org@aa{}s
system locale uses charset `UTF-8'.
input[0] = U+0072
input[1] = U+4af3
input[2] = U+006d
input[3] = U+1b29e5
input[4] = U+0073
output[0] = U+0078
output[1] = U+006e
output[2] = U+002d
output[3] = U+002d
output[4] = U+0072
output[5] = U+006d
output[6] = U+0073
output[7] = U+002d
output[8] = U+0068
output[9] = U+0069
output[10] = U+0036
output[11] = U+0064
output[12] = U+0035
output[13] = U+0039
output[14] = U+0037
output[15] = U+0035
output[16] = U+0035
output[17] = U+0032
output[18] = U+0061
xn--rms-hi6d597552a
jas@@latte:~$
@end example

The sense moral here is to forget about @samp{CHARSET} (configure your
locales properly instead) unless you know what you are doing, and if
you want to use it, do it carefully, after verifying with
@samp{--debug} that you get the desired results.

@node Emacs API
@chapter Emacs API

Included in Libidn are @file{punycode.el} and @file{idna.el} that
provides an Emacs Lisp API to (a limited set of) the Libidn API.  This
section describes the API.  Currently the IDNA API always set the
@code{UseSTD3ASCIIRules} flag and clear the @code{AllowUnassigned}
flag, in the future there may be functionality to specify these flags
via the API.

@section Punycode Emacs API

@defvar punycode-program
Name of the GNU Libidn @file{idn} application.  The default is
@samp{idn}.  This variable can be customized.
@end defvar

@defvar punycode-environment
List of environment variable definitions prepended to
@samp{process-environment}.  The default is @samp{("CHARSET=UTF-8")}.
This variable can be customized.
@end defvar

@defvar punycode-encode-parameters
List of parameters passed to @var{punycode-program} to invoke punycode
encoding mode.  The default is @samp{("--quiet" "--punycode-encode")}.
This variable can be customized.
@end defvar

@defvar punycode-decode-parameters
Parameters passed to @var{punycode-program} to invoke punycode
decoding mode.  The default is @samp{("--quiet" "--punycode-decode")}.
This variable can be customized.
@end defvar

@defun punycode-encode string
Returns a Punycode encoding of the @var{string}, after converting the
input into UTF-8.
@end defun

@defun punycode-decode string
Returns a possibly multibyte string which is the decoding of the
@var{string} which is a punycode encoded string.
@end defun

@section IDNA Emacs API

@defvar idna-program
Name of the GNU Libidn @file{idn} application.  The default is
@samp{idn}.  This variable can be customized.
@end defvar

@defvar idna-environment
List of environment variable definitions prepended to
@samp{process-environment}.  The default is @samp{("CHARSET=UTF-8")}.
This variable can be customized.
@end defvar

@defvar idna-to-ascii-parameters
List of parameters passed to @var{idna-program} to invoke IDNA ToASCII
mode.  The default is @samp{("--quiet" "--idna-to-ascii"
"--usestd3asciirules")}.  This variable can be customized.
@end defvar

@defvar idna-to-unicode-parameters
Parameters passed @var{idna-program} to invoke IDNA ToUnicode mode.
The default is @samp{("--quiet" "--idna-to-unicode"
"--usestd3asciirules")}.  This variable can be customized.
@end defvar

@defun idna-to-ascii string
Returns an ASCII Compatible Encoding (ACE) of the string computed by
the IDNA ToASCII operation on the input @var{string}, after converting
the input to UTF-8.
@end defun

@defun idna-to-unicode string
Returns a possibly multibyte string which is the output of the IDNA
ToUnicode operation computed on the input @var{string}.
@end defun

@c **********************************************************
@c *******************  Acknowledgements  *******************
@c **********************************************************
@node Acknowledgements
@chapter Acknowledgements

The punycode code was taken from the IETF IDN Punycode specification,
by Adam M. Costello.  The TLD code was contributed by Thomas Jacob.
Some functions for dealing with Unicode (see nfkc.c and toutf8.c) has
been borrowed from GLib downloaded from www.gtk.org.

Several people reported bugs, sent patches or suggested improvements,
see the file THANKS in the top-level directory of the source code.

@node Concept Index
@unnumbered Concept Index

@printindex cp

@node Function and Variable Index
@unnumbered Function and Variable Index

@printindex fn

@include lgpl.texi

@node Copying This Manual
@appendix Copying This Manual

@menu
* GNU Free Documentation License::  License for copying this manual.
@end menu

@include fdl.texi

@bye