[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] draft-ietf-aceid
Hi.
We revised draft-ietf-idn-aceid to version 02. I enclose it.
Thanks in advance.
-- Masa
----
NaoMASA Maruyama
maruyama@nic.ad.jp
----------------------------------------------------------------
Internet Draft Naomasa Maruyama
draft-ietf-idn-aceid-02.txt Yoshiro Yoneya
Jun 19, 2000 JPNIC
Expires Dec 19, 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 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 head of at least one label of the
domain name and those which have an ACE suffix identifier candidate at
the tail of at least one label of the name. These domain names are
collectively called "relevant domain names".
This suspension should be continued until September 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 August 11, 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 or other organ of IETF or ICANN MUST summarize the
reports and list ACE identifier candidates that are not reported to be
used in registered domain names by August 18, 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 August 25, 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 September 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 September 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. Changes from the previous version
We excluded suffixes of one hyphen followed by three alpha-
numericals from the candidates. This is because we found that, as of
Nov. 29, 2000, there were 23,921 domain names registered in the .JP
space relevant to these suffixes. This was more than 10% of 227,852
total registrations in the JPNIC database at the moment, and hence we
felt these suffixes are not good candidates.
In addition to this and some minor linguistic corrections, we
changed "The IDN WG" in section 2.3 to "The IDN WG or other organ of
IETF or ICANN".
7. 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.
8. Acknowledgements
We would like to express our hearty thanks to members of JPNIC IDN
Task Force for valuable discussions about this issue. We also would
like to express our appreciation to Mr. Dave Crocker for checking and
correcting the preliminary version of this draft.
9. 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