[idn] Proposed suggestions from Asia Pacific Top Level Domain meeting

[Dongman Lee <dlee@icu.ac.kr>]

Dear IETFer,

At the recent Asia Pacific Top Level Domain (APTLD) meeting, there were
discussions on
multilingual domain names on 26th and 28th Feb. We mainly had discussion
on the IETF requirement draft document and here is a summary of
suggestions and concerns which we would like to IETF to consider.

Issue 1: "." (period) as a separator

We have a concern about using period '.' as a separator. Essentially,
there
are other period (e.g. double width period) which, if taken as a
separator,
would make life easier for the users. On the other hand, there are also
concern about introducing additional separator as it introduce confusion
for
domain name.

"Since '.' is only represented on the client and not seen in the wired
format,
therefore, we can consider the '.' client representation issue. Hence,
this
should be beyond the scope of the discussion of the requirement doc."
James
Seng.

On the related issue, Bill Manning raise the issue what should be the
terminator domain name. Should it be 'period', or LF or CR?

Recommendation:

No change to the current wording.

Issue 2: Resolve any domain name anywhere.

We refer to Section 2.1, paragraph 1.

Recommendation:

We feel it is best phrased as "...to allow any system anywhere to
resolve any
Internet multilingual domain name..."

Issue 3: Caching server specification are too vague.

We refer to Section 2.1, paragraph 5.

"Yes, we should have a clearer specification. But in the long term
vision, we
should aims for a protocol which does not rely on caching server and
should
involve authoritative servers directly." Bill Manning.

The reasons for this is because we feel that caching servers introduced
inaccuracy and inconsistency.

Recommendation:

We feel that there must be a clear definition of what caching servers
should
do.

In addition, since caching data cannot provide reliable data, we feel
that the
paragraph 3 of Section 2.1 should have the "or caching servers" removed.
i.e.

"The same name resolution request must generate the same response,
regardless
of the location or localization settings in the resolver, in the master
server, and in any slave servers involved in the resolution process."

Issue 4: The requirement should concern with protocol, not
implementation.

We refer to 2.1 paragraph 1, on the phrase "DNS interoperability".

We feels that the word "interoperability" is unfairly bias that
implementation
has to "interoperability" even with broken implementation. However, we
have no
proposal on the replacement for the word but we would appreciate a
proper
rephrasing to reflect this principle.

No recommendation at this moment.

Issue 5: What is a current domain name? What is IDN?

We refer to Section 1.1, paragraph 2.

RFC1034 Section 3.5 is a poor definition of domain name. A better one is

RFC1123. However, we also noted that even RFC1123 is not sufficient to
define
a host name and domain name properly.

We need a properly definition of label, domain and host. It is funny to
note
that we are doing IDN without even able to properly define IDN.

Recommendation:

We need more data and information and give a better definition.

Issue 6: Do we want to consider non alphanumeric US-ASCII?

Related to issue 5, the current IDN definition covers non-alphanumeric
US-ASCII characters, for example '&', '_', '+', etc. (e.g., AT&T.COM?)

Recommendation:

We feel that IDN is a complicated issue by itself and we should not
consider
non-alphanumeric US-ASCII as part of our work. If this is agreeable, we
need
to a paragraph of some sort to state this principle.

Issue 7: How is the root server management structure? Tree or Forest?

There was a lot of discussion on this. The main support for forest
structure
was that it allows each country to control its own root servers and thus
need
not 'pay millions of dollars outside' the country. To the third world
country,
this is very important.

However, many technical people argued that this kind of delegation and
control
can be achieve with a single root tree structure. A single root tree
structure
is for technical simplicity of communication. For example, consider N
sub-root
tree. In order to connect them in a forest tree structure, it requires
(N-1) +
(N-2) + ... 2 links. On the other hand, to connect them in a single root

structure, only N links is needed. Delegation and control etc can be
done per
TLD according to policy.

No conclusion and thus no recommendation.

Issue 8: Other features that are coming to DNS, e.g. DNSSEC.

Recommendation:

We should also consider DNAME as it might be useful for IDN. We should
consider using it operationally if IDN problems.

Issue 9: Can we have multiple TLD for a language encoding?

It is not an issue so long we are talking about DNS design.

"Technology wise is no problem. Operational wise would be difficult"
David Conrad.

No recommendation at this moment.

Issue 10: If we have a multiple root system, who, what and how to manage
the
          fall back strategy?

Since Issue 7 has no conclusion, this is skipped.

No recommendation at this moment.

Issue 11: Canonicalisation/Normalisation standard should be determined
by
          consensus in the region/language they are used.

We have some discussion on who should determined the standard.

Recommendation:

If the charset can be normalised, then it should be normalised before
it is used in IDN.

--
Dongman Lee, Ph.D.
Associate Professor
School of Info & Computer Engineering
Information and Communications University
58-4 Hwaam-Dong, Yusung-Ku
Taejon 305-348
Korea

E-mail: dlee@icu.ac.kr
Web: http://www.icu.ac.kr
Tel: 042-866-6113
Fax: 042-866-6154