[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)
At 09:59 AM 6/11/2002 -0400, John C Klensin wrote:
Is IDNA properly and adequately specified for the uses to
which it will be put and is it designed appropriately
for that range of uses?
I think the answer is probably that more specification, tightly
bound to IDNA, is needed. In terms of the sequencing of things,
I believe that the beginning of serious work on those
specifications will expose specification problems with the
current IDNA spec.
It is certainly true that further work will develop further
understanding. In this business, that's a truism.
The pattern of IETF experience suggest a number of interesting guidelines,
some of which are impressively counter-intuitive.
And intuitively obvious rule is that a complex problem needs to be studied
carefully and thoroughly and the solution needs to be complete, before it
is release.
The rule is wrong.
IETF experience shows that consistently, yet it is being cited here.
The rule that works -- especially for a new effort -- it to find a way to
release the smallest, useful piece of work as quickly as possible, so that
the learning and improving can be based on experience, rather than on
academic introspection.
It is essential to note both words -- smallest and useful. The former
permits releasing something quickly, though one is hardpressed to find a
way to apply the word quickly to IDN. The latter ensures market pull to
deply and use the new facility.
Infinite delay of the IDN work will have one major benefit: The current
proprietary solutions will gain permanent position in the market. The
derivative likelihood is that the IETF work will cease to matter.
We have an excellent example of this possibility with instant
messaging. Let's not repeat it for IDN.
(i) The specification now appears to say that applications can
decide to use IDNA or not.
Yes, it is a meaningless statement and should be removed. IETF standards
are always optional.
In other words, the problem is with the presence of the statement. The
statement itself does not cite a meaningful problem.
(ii) The specification seems inconsistent about what it about
and who needs to understand it.
So the applicability text needs clarifying. Not the normative text. That
is hardly a major issue.
It implies in several places
that it is not about the DNS and has no impact on the DNS.
Yes, the text could be more clear. That is often true of new
text. However this example of needing greater clarity again does not
pertain to normative specification.
My own effort to work through the text suggests that the specification
really covers 3 issues:
1. Enhancement of the DNS label namespace, to expand to include Unicode --
IDN. This is clearly a change to the formal DNS model.
2. Provision of a general mechanism for encoding Unicode (non-Ascii) into
a portion of the ASCII namespace -- ACE. This requires reserving a piece
of the existing name space. It also requires changes to participating
resolvers (or the software that calls resolvers) and to DNS server
administrative tools. However it requires no changes to the DNS protocol,
nor to non-participating DNS entities. Obviously it also requires changes
to participating applications, but that is a matter concerning support for
Unicode, rather than anything about the DNS, itself.
3. Rules for creating internationalized host names (ie, domain names
intended for use in URLs and email addresses) by using IDNA but still
working under both STD13 and STD3. For convenience, I am starting to call
this IDNA-Host.
(iii) Despite the "applications can choose to do this, or not do
it" language, section 6.4 effectively implies a requirement that
any application that uses the DNS be upgraded.
If a DNS entity is going to participate in IDNA, it must be upgraded. That
is a truism. Here again, the real problem is that the attempt to help
clarify things has been counter-productive. The right solution is simply
to remove that bit of text. It is not normative;.
(iv) Section 7 imposes several normative requirements on name
servers and zone populations. ...
(v) In particular, several of the statements in the draft go
beyond almost anything we have about the DNS in trying to
narrowly constrain the behavior of RR labels and data that are
not yet defined,
Interestingly, I believe the real problem here is with trying to do exactly
what you are proposing, namely to work on a whole problem, rather than
first solving the smallest, immediately useful part that can be done. So,
here again, the right answer is to factor out the larger work for a later
time. (My reading of your note suggests you might even agree on this point.)
That immediately useful work needs to be about domain names -- and more
specifically about the strings that are used in URLS and email
addresses. Other domain labels that occur within DNS RRs can be considered
in separate work.
(vi) I suggest that it is a useful general principle to design
service ("micro layer" to use Dave's term) protocols to be as
The IDNA document's term is "shim". I find myself preferring the
contextual implications of that word. Micro-layer works as a formalism,
but shim is a term that carries more information.
general as feasible without making them overly complex.
What generality is lacking from the current IDNA spec?
It should be revised and some of that material should be pulled
out and into separate documents. As an alternative, that
material should be highlighted: the abstract and introductory
material should indicate that these normative DNS requirements
are present, that 2181 is explicitly updated, and so on.
Finally, the apparent reach of the protocol should be narrowed
and specified, either in this document or elsewhere.
This is amusing.
You are suggesting a bit of work that I believe is straightforward document
cleanup, rather than substantial delay.
I agree with you.
d/
----------
Dave Crocker <mailto:dave@tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850