255 lines
11 KiB
Plaintext
255 lines
11 KiB
Plaintext
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.
|
|
|
|
|
|
1. 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.
|
|
|
|
2. 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.
|
|
|
|
3. 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;
|
|
|
|
4. 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.
|
|
|
|
5. 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.
|
|
|
|
6. Acknowledgements
|
|
The author would like to acknowledge the comments and idea of the
|
|
following people: Fran‡ois Yergeau and Paul Hoffman.
|
|
|
|
7. Author
|
|
|
|
Marc Blanchet
|
|
Viagenie
|
|
2875 boul. Laurier, bur. 300
|
|
Ste-Foy, Quebec, Canada
|
|
G1V 2M2
|
|
Marc.Blanchet@viagenie.qc.ca
|
|
tel: 418-656-9254
|
|
|
|
8. 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.
|
|
|