Internet Draft                                   Marc Blanchet

draft-ietf-idn-version-00.txt                         Viagenie
October 26, 2000
Expires in six
months




     Handling versions of internationalized domain names protocols


Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.


Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.


Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."



      The list of current Internet-Drafts can be accessed at

      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at

      http://www.ietf.org/shadow.html.



Abstract

This document describes some issues related to handling changes in the
codepoints and other features in the chars space of an internationalized
domain name as well as changes in the protocol that supports it (whatever
that be).  It also presents some solutions to these issues.


. Rationale

The nameprep draft [NAMEPREP] is defining prohibited chars, normalization
algorithms, etc.. The current concensus is to take the safer approach of
not accepting new chars if they are not listed, since the new characters
that can be included in the subsequent releases of the universal character
set can have an impact on the domain name (for example, a new variation of
the dot . will mostly be non-compatible and being excluded).

The Unicode and ISO-10646 versioning is designed not for the same purpose
as the idn work: for example, some chars or properties can be changed or
added to those repertoires that cannot be taken as is by the idn
protocol.  In essence, the idn nameprep versions cannot be in sync with
unicode/iso versions. idn need its own versioning of the accepted character
set, which can or cannot be synchronized with the two others. While saying
that, there is no intent at all to define new codepoints inside this work
and any attempt to do that must be rejected.

Since internationalization and specifically internationalization of the
domain names is new, we don't really know if the chosen algorithm, protocol
and codepoitns will not have any problem in the future. We need to handle
versions of the protocol and to have a specific table for idn accepted chars.

. Versioning of the protocol

Since the idn table of chars will be changed in the future, and possibly
the algorithms and the processing, then there is a need to handle these
situations in a controlled way. A version of the idn protocol should be
defined and included as part of the exchange between the parties so that
they can handle smoothly the new revisions.

2.1 Implementing the version in the protocol
Depending on which way the idn protocol will be, a different versioning
will have to be defined. We will discuss the current proposals and identify
where a versioning system can be handled.

2.1.1 Proposals based on extensions of the DNS protocol
  Proposals based on extensions of the DNS protocol should include in the
bits the version number and a way to exchange version numbers between the
parties. [IDNE] already defined a version number as part of the use of
EDNS. Similar versioning should be defined in the other proposed protocols.

2.1.2 Proposals based on ACE and application
  Since ACEs (for example [RACE]) in applications [IDNA] do not change the
DNS protocol but only encode the idn in a ascii compatible way, it looks
more difficult to include a version number in the ACE encoding, since it
will change the domain name.  The proposal is to use a different
prefix/suffix for each version, by using one of the chars used in the
prefix as a version number, beginning with the lowest possible ascii char
available and increase the ascii codepoint of the char by 1 for each
version. For example, if the prefix is "ra--", then the first version of
idn will be "ra--", the second version will be "rb--", the third "rc--".
While this would be more elegant, one can handle versioning by having
different prefixes for each version, while chosing prefixes randomly (i.e.
1st version: rq--, 2nd version: wz--, ...). IANA should block all possible
prefixes so that no pre-registration is permitted.

2.2 Major and minor version numbers

  A <major>.<minor> version number is proposed (i.e. 1.0, 1.1, 2.0). A
minor revision is defined to be as new chars or small changes in the table
to be handled without any modification of algorithm.  The idea here is to
enable easy upgrading of idn processors when only new chars will be
handled.  In this case, the binary software do not have to be changed and
only the table containing the chars has to be changed to enable a new
version.  A major revision means that the software has to be upgraded since
it implies new ways of handling idn which are not identified in the table.

2.3 Processing of the version numbers
Any idn processor MUST verify the version number before processing. When a
major version number is higher than what the processor currently handle is
detected, processing MUST be stopped and rejected. When a minor version
number is higher than what the processor currently handle, then any
intermediate processors MUST forward the idn but the end processor (i.e.
the dns server authoritative for that zone that is handling the request)
MUST stop and reject the request.  Specific handling of rejecting the
request should be defined in the protocol document.

2.4 Version numbers
  Version numbers of the idn protocol will be handled by IANA. A
IESG-reviewed document should be used as the basis for IANA to define a new
protocol version number.

. Idn table
  Since the unicode consortium and ISO will issue new versions not at the
same time as the idn protocol versioning, the IETF need to have its own
registered table of accepted idn chars. This will also enable specific data
only useful for idn. The intent is not to duplicate the unicode/iso effort,
it is to support the specific needs of the idn group.  For example, it is
possible that specific chars will have a different behavior than the normal
Unicode way: the special casing for final or non-final letters in the
Unicode SpecialCasing.txt file can be merged (ie not totally identical to
the unicode processing) to only one casing since final and non-final
letters have less meaning in a domain name. Simpler processing for idn is
also useful: for example, the Lud property is probably not useful in the
idn context and can be considered equivalent to Lu. Combining those
properties together means much simple table and simpler processing and less
errors in implementations. Added chars, codepoint, properties MUST NOT be
done in this file, but must be done within the Unicode/ISO process.

This document proposes a table contained in an ascii file handled by IANA
and available in the IANA public directory. The source of the table will be
the Unicode table, with a similar format, but a simpler, and perhaps
different, content based on the needs of the idn protocol. Proposed
filename is: idntab.txt.

This file format will also help implementors to have the same input
description and exhaustive list of which chars and processing to handle
idn. This is easier for implementors to have a complete list of accepted
chars instead a list of non-accepted chars.  The hope is also to help
decrease the different behaviors between the different implementations.
This table can be considered as an implementation of [NAMEPREP].

3.1 File format

The file is divided in two parts. The first part contains variables. The
second part contains all the chars accepted for idn. The two parts are
separated by a empty line.

The format of the first part is:
tag=value<CR><LF>

Currently, only the version tag is defined. The "version" tag defines the
highest idn version number that can be found in this table.  The intent is
to have only one file that is kept current but where the beginning of the
file can be used by parsers to identify the latest version of the file.

The first idntab.txt file will define version=1.0:
version=1.0<CR><LF>

The format of the second part is:
  one codepoint per line
  lines separated by CR/LF
  each field in the line separated by ";"

The fields are (in order, from left to right):
  1. codepoint in hexadecimal (as in unicode table): HHHH
  2. first version of idn table that this char is supported

It is possible that new fields will be added in the future. Parsers should
ignore the fields that they don't understand.

Spaces (ascii  0x20) are ignored. Comments are identified by "#". All text
following the comment char up to the end of line is ignored. Any codepoint
not in the table is considered prohibited. Codepoints that are prohibited
may be included in the table inside commented lines in order to help a
reader to see explicitly which ones are prohibited.

Example of the file idntab10.txt:
version=1.0<CR><LF>
<CR><LF>
0041;1.0;

. Security Considerations

Changing the way a software react about domain names is clearly something
that have security impacts. While the actual table doesn't present any
security threat by itself, if there is someways by a intruder to reload a
new table into a idn processor software without the knowledge of the user,
then it can completly disables name resolution or have other possible
threats.  In conclusion, care must be taken by software developers on how
to manage the insertion of a new idn table in a idn processor software.

. IANA Considerations
  This document describes versions of the idn file called idntab.txt. The
file should be kept in the IANA public directory for references purposes.
New versions of the file should be made available after IESG review of a
document.  Old revisions of the file (idntab-xy.txt) should be kept for
documentation purposes.

. Acknowledgements
  The author would like to acknowledge the comments and idea of the
following people: Fran‡ois Yergeau and Paul Hoffman.

. Author

Marc Blanchet
Viagenie
 boul. Laurier, bur. 300
Ste-Foy, Quebec, Canada
G1V 2M2
Marc.Blanchet@viagenie.qc.ca
tel: 418-656-9254

. References

[NAMEPREP] Preparation of Internationalized Host Names, Paul Hoffman, Marc
Blanchet. Work in progress.

[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, Paul Hoffman.
Work in progress.

[IDNA] Internationalizing Host Names In Applications (IDNA), Paul Hoffman,
Patrick Falstrom. Work in progress.


Marc Blanchet
Viag‰nie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.