Commit 9beb71d6 authored by David Lawrence's avatar David Lawrence
Browse files

current idn working group drafts

parent 517950ae
Internet Draft Naomasa Maruyama
draft-ietf-idn-aceid-00.txt Yoshiro Yoneya
November 17, 2000 JPNIC
Expires May 17, 2001
Proposal for a determining process of ACE identifier
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
In IETF IDN WG, various kinds of ASCII Compatible Encodings,
hereafter abbreviated as "ACE", are discussed as methods for realizing
multilingual domain names (hereafter referred to as "MDN"). Each ACE
uses a prefix or a suffix as an identifier in order for MDNs to fit
within the existing ASCII domain name space. In other words,
acceptance of an ACE proposal as an Internet standard means that the
existing ASCII domain name space will be partitioned, in order to
accommodate MDN space.
This document describes possible trouble in the standardization
process of ACE, and proposes a solution for it.
1. Present situation and concern
At present, some specifications relating to MDN specify their own
ACE identifiers. In these drafts, multilingual domain names encoded
into ASCII character strings, with the ACE identifiers in their heads
or tails, are merely ASCII character strings. It is possible
accidently or intentionally to register a domain name that is not an
MDN but has the designated ACE identifier string.
If this kind of registration takes place, there is no warranty
that the domain name will be consistent with MDN semantics.
Furthermore, there is no warranty that the name, interpreted as an
MDN, will comply with the registration policies of the registry, when
the ACE identifier proposal is finally accepted as an Internet
standard. This might cause problems with name disputes and/or
revocations.
Therefore, the current situation letting independent ACE proposal
authors arbitrarily select an ACE identifier, hence permitting domain
name registrants registrer such names, may hinder deployment of MDN
technology.
2. Selecting ACE identifiers
In order to maintain a smooth standardization process for ACE,
this document proposes a strategy for selecting and reserving of ACE
identifiers and a method for assigning them.
2.1 The ACE identifier candidates and tentative suspension of
registering relevant domain names
All strings starting with a combination of two alpha-numericals,
followed by two hyphens, are defined to be ACE prefix identifier
candidates. All strings starting with one hyphen followed by three
alpha-numericals, and strings starting with two hyphens followed by
two alpha-numericals are defined as ACE suffix identifier candidates.
ACE prefix identifier candidates and ACE suffix identifier candidates
are collectively called ACE identifier candidates.
All the domain name registries recognized by ICANN SHOULD
tentatively suspend registration of domain names which have an ACE
prefix identifier candidate at the heads of one of the labels of the
domain name and those which have an ACE suffix identifier candidate at
the tail of one of the labels of the name. These domain names are
collectively called "relevant domain names".
This suspension should be continued until March 1, 2001 00:00:00 UTC.
2.2 Survey of relevant domain name registration
All registries recognized by ICANN SHOULD conduct a survey about
relevant domain names registered in their zone, and report, no later
than February 10, 2001 00:00:00 UTC, all of the ACE identifier
candidates which are used by relevant domain names.
2.3 Selection of ACE identifiers and permanent blocking of
relevant domain names
The IDN WG MUST summarize the reports and list ACE identifier
candidates that are not reported to be used in registered domain names
by February 17, 2001 00:00:00 UTC, and select ten to twenty ACE prefix
identifier candidates and ten to twenty ACE suffix identifier
candidates for ACE identifiers. Among these twenty to forty ACE
identifiers, one prefix identifier and one suffix identifier will be
used for experiments. Others will be used, one by one as ACE standard
evolves.
The list of ACE identifiers will be sent to IANA, and will be
maintained by IANA from February 24, 2001 00:00:00 UTC. Domain names
relevant to these identifiers SHOULD NOT be registered in any DNS
zone, except for registration of multilingual domain names compliant
to one of future IDN standards. This new restriction about the domain
name space will be notified to all ICANN recognized registries by IANA
immediately after it receives the list.
2.4 Blocking of registration for relevant domain names
Domain names relevant to ACE identifiers selected by the procedure
described in section 2.3 SHOULD NOT be registered in any zone of ICANN
recognized registries except for registration of multilingual domain
names compliant to one of future IDN standards. All ICANN recognized
registries SHOULD implement this restriction no later than March 1,
2001 00:00:00 UTC.
Registration for domain names relevant to ACE identifier
candidates, tentatively suspended by 2.1, but not relevant to ACE
identifiers selected by section 2.3 MAY be reopened from March 1, 2001
00:00:00 UTC.
3. Use of an ACE identifier in writing an ACE proposal
When writing an ACE proposal using an ACE identifier, the author
SHOULD either describe the ACE identifier as "to be decided" and left
to discretion of the IDN WG or other organ of IETF or ICANN, or use
either of the ACE identifiers for experiment defined in section 2.3,
with a unique version number added after or before the prefix or
suffix.
If a proposal is validated and published as an Internet Draft, the
IDN WG or other organ of IETF or ICANN MUST replace the "to be
decided" part with an experimental identifier with a unique version
number added after or before the prefix or the suffix.
4. Determination of ACE identifier
When an Internet Draft relating to ACE is accepted as an Internet
standard and becomes an RFC, IDN WG or other organ of IETF or ICANN
MUST replace the experimental ACE identifier, augmented by the version
number, with one of the ACE identifiers.
5. Security considerations
None in particular.
6. References
[IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain
Names", draft-ietf-idn-requirements-03.txt, Jun 2000.
[RACE] P Hoffman, "RACE: Row-based ASCII Compatible Encoding for
IDN", draft-ietf-idn-race-02.txt, Oct 2000.
[BRACE] A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible
Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000.
[LACE] P Hoffman, "LACE: Length-based ASCII Compatible Encoding for
IDN", draft-ietf-idn-lace-00.txt, Nov 2000.
[VERSION] M Blanchet, "Handling versions of internationalized domain
names protocols", draft-ietf-idn-version-00.txt, Nov 2000.
7. Acknowledgements
JPNIC IDN-TF members,
Dave Crocker.
8. Author's Address
Naomasa Maruyama
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
maruyama@nic.ad.jp
Yoshiro Yoneya
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
yone@nic.ad.jp
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Internet Draft Yoshiro Yoneya
draft-ietf-idn-jpchar-00.txt Yasuhiro Morishita
November 17, 2000 JPNIC
Expires May 17, 2001
Japanese characters in multilingual domain name label
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 explains about Japanese characters and its canonicalization
rules in multilingual domain name labels. This document is based on
discussions and examinations in JPNIC.
Despite of IDN WG rough consensus that character set in multilingual
domain name is UCS [UCS], most popular Japanese character set used in
Japan is Japanese Industrial Standards X 0208 -- hereafter abbreviated
as "JIS" -- [JISX0208]. This means that many of PCs and most of PDAs
including handy phones in Japan can display only JIS and ASCII.
Therefore, Japanese characters used in multilingual domain name are
strongly recommended as common part of JIS, ASCII and UCS.
Furthermore, for historical reasons, JIS have many compatible code
points in Kana and Alpha-numericals. Such compatible code points are
still used widely, so that these characters SHOULD be acceptable
especially in user interface, and MUST be canonicalized before
transmission to the wire. The former half should be implemented for
localization, and the latter half must be implemented for
internationalization.
1. Japanese characters in multilingual domain name labels
In principle domain name is a symbolic name of resources on the
Internet for understanding and memorizing easily to the Internet
users. Internationalization or multilingualization of domain name
MUST obey this principle. That is, characters in multilingualized
domain name labels SHOULD be unambiguous.
JIS has a lot of characters including graphical and compatible
characters. But as for domain name, significant characters to
represent names are Kanji, Hiragana and Katakana [CJK]. Therefore,
according to the principle, Japanese characters in multilingual domain
name MUST be Kanji, Hiragana and Katakana in JIS.
The file "idntabjp10.txt" defines Japanese characters in the format of
[VERSION], with additional corresponding JIS code points as 3rd field,
that can be used in multilingual domain name labels. Some of them,
such as PROLONGED SOUND MARK (U+30FC), are categorized into graphical
character in JIS, but usage of them are part of Kanji, Hiragana or
Katakana. These characters are in canonicalized form.
2. Canonicalization rules of Japanese characters in multilingual
domain name labels
In this section, this document describes two parts of canonicalization
rules. One explains "localization", and the other comments on
"internationalization". In other words, one is for Input/Display
level, and another is for API level [IDNA].
2.1 Localization: Characters to be canonicalized before NAMEPREP
As mentioned above, JIS has a lot of compatible characters that are
regarded alpha-numeric or Katakana. The former is so called
FULL-WIDTH Alpha-numeric, and the latter is so called HALF-WIDTH kana.
These characters are prohibited in [NAMEPREP], but still widely used
in many PCs and most PDAs in Japan. Hence, application softwares that
treat Japanese characters in multilingual domain name label SHOULD
accept these compatible characters as input and canonicalize them
before [NAMEPREP].
The file "idntabjpcanon10.txt" defines compatible characters, with
additional canonicalized character code as 3rd field; that is, mapping
table of FULL-WIDTH Alpha-numeric to ASCII, and HALF-WIDTH kana to
Katakana.
The file "idntabjpcomp10.txt" defines compatible character sequences
as composed, with additional canonicalized characters code as 3rd
field; that is, composition table of Kana and voiced sound mark.
Recommended order of applying canonicalization rules is as follows:
(1) "idntabjpcanon10"
(2) "idntabjpcom10"
This part is a local part of canonicalization.
2.2 Internationalization: Characters to be canonicalized in NAMEPREP
Japanese characters in multilingual domain name labels MUST be
characters defined in "idntabjp10". Another characters except for
"idntabjp10" SHOULD be canonicalized at [NAMEPREP].
[NAMEPREP] is common and recommended rule for IDN.
This part is an international part of canonicalization.
3. Security considerations
None in particular.
4. References
[UCS] "Universal Multiple-Octet Coded Character Set",
ISO/IEC 10646-1:1993, ISBN 0-201-61633-5
[JISX0208] "Japanese Industrial Standards",
Information Technology (Terms/Code/Date elements)-99,
ISBN4-542-12976-4
[IDNREQ] "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirements-03.txt, Jun 2000, Z Wenzel, J Seng
[NAMEPREP] "Preparation of Internationalized Host Names",
draft-ietf-idn-nameprep-00.txt, Jul 2000, P Hoffman, M Blanchet
[CJK] "Han Ideograph (CJK) for Internationalized Domain Names",
draft-ietf-idn-cjk-00.txt, Sep 2000, J Seng, Y Yoneya,
K Huang, K Kyongsok
[VERSION] "Handling versions of internationalized domain names protocols",
draft-ietf-idn-version-00.txt, Nov 2000, M Blanchet
5. Acknowledgements
JPNIC IDN-TF members.
6. Author's Address
Yoshiro Yoneya
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
yone@nic.ad.jp
Yasuhiro Morishita
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
yasuhiro@nic.ad.jp
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment