WG Review: Internationalized Domain Name (idn)

[Lisa Dusseault]

FYI -- comments welcome. There's a meeting scheduled in
Philadelphia, which could turn into a WG meeting if this is approved
for a WG charter; otherwise it will remain a BOF meeting.

Thanks,
Lisa

Date: February 26, 2008 9:57:35 AM PST
Subject: WG Review: Internationalized Domain Name (idn)
A new IETF working group has been proposed in the Applications
Area. The
IESG has not made any determination as yet. The following draft
charter
was submitted, and is provided for informational purposes only.
Please
March 4,
2008.
Internationalized Domain Name (idn)
=============================
Last modified: 2008-02-18
Current Status: Proposed Working Group
TBD
http://www.alvestrand.no/mailman/listinfo/idna-update
Archive: http://www.alvestrand.no/pipermail/idna-update/
The original Internationalized Domain Name (IDN) WG set the
requirements for international characters in domain names in
RFC 3454, RFC3490, RFC3491 and RFC3492 in 2002. These documents
were tied to Unicode version 3.2 and an update to the current
version (5.x) is required to accommodate additional scripts.
In addition, experience has shown a number of real or perceived
defects or inadequacies with the protocol. Some of them are
described in an IAB review (RFC4690), which also provides a good
introduction to the subject matter.
IDNA is currently tied to an obsolete version of Unicode. This WG
is chartered to untie IDNA from specific versions of Unicode using
algorithms that define validity based on Unicode properties. It is
recognized that some explicit exceptions may be necessary in any
case, but attempts would be made to minimize these exceptions.
- Separate requirements for valid IDNs at registration time,
vs. at resolution time
- Revise bi-directional algorithms to produce a deterministic
answer whether a label is allowed or not
- Determine whether bi-directional algorithm should allow
additional mnemonics labels
- Permit effective use of some scripts that were
inadvertently excluded by the original protocols.
The constraints of the original IDN WG still apply, namely to
avoid disturbing the current use and operation of the domain
name system, and for the DNS to continue to allow any system
to resolve any domain name. The basic approach of the original
IDN work will be maintained -- substantially new protocols or
mechanisms are not in scope. In particular, IDNs continue to
use the "xn--" prefix and the same ASCII-compatible encoding,
and the bidirectional algorithm follows the same basic design.
The WG will work to ensure practical stability of the validity
algorithms for IDNs (whether based on character properties or
inclusion/exclusion lists).
The work is currently organized into four deliverables, all
Standards Track. The WG will verify that it has consensus
to adopt the proposed documents as a starting point. The
Overview document with explanation and rationale is intended
for Standards Track status because it has definitions and
other normative text required by the other documents. The
protocol specification explains how to map non-ASCII
characters into ASCII DNS labels. It relies normatively on
two other documents that are separate for readability: the
bidirectional algorithm specification and the character
validity tables. The validity of characters in IDNs is
almost exclusively based on Unicode properties but is
organized as tables and categories for readability.
Mar 08: WG Last Call for Overview/Rationale document
Apr 08: Revised Overview/Rationale document
Apr 08: WG Last Call for Protocol, Bidi and Tables documents
May 08: Revised Protocol, Bidi and Tables documents
May 08: Review Overview document again if needed
Jul 08: Request for publication for all documents
http://tools.ietf.org/html/draft-klensin-idnabis-issues
http://tools.ietf.org/html/draft-klensin-idnabis-protocol
http://tools.ietf.org/html/draft-faltstrom-idnabis-tables
http://tools.ietf.org/html/draft-alvestrand-idna-bidi

[JFC Morfin]

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
2008.

Dear Friends,
A few years ago the same scenario developed when introducing the RFC
3066bis failed Draft, but without an initial consensus check.

I explained several times that the choice for some Gov/Private/Civil
Society interests was to get it corrected or aborted (then at the
risk of the whole IETF). The decision was to get it corrected in
consideration of its probable mandatory usage by IBM/MS customers. I
accepted to carry the job after the WG-IDNA's poor results where it
was that I became accustomed to the IETF. It was also due to
architecturally erroneous (IMHO) RFC 3935.

This was pure mail-combat in what Economic Intelligence calls
"knowledge war" and the DoD calls "shaping the world". This was a
nice exchange for no one, but it did preserve interoperability with
other referential systems, RFC 4646 was not adopted by the IESG
before the very day it could be accepted, and its
"internationalization" doctrine was further defeated at ISO TC46. As
a result, I was the only one to be PR-acted and the IETF was not hurt
(except by the IESG not respecting its RFC 4646 obligations, what RFC
4646bis has now to take care of)..

This time, the DNS in the Multilingual Internet is certainly just as
important as langtags are but is more visible. It also represents
much more money and is led now by Google/Yahoo!. Harald Alvestrand,
this time, has also prepared his plans better: he banned me first
from his IDN proprietary list (the best way to obtain consensus).
This has clarified things, relieving me from any moral obligation to
cooperate with the IETF. It was fortunate since the target is no
longer to maintain interoperability from inside the RFCs, because
IDNA is not operable at all. However, this is something now for the
future to show.

So, I suggest:

1. to follow Harald in transforming his proprietary mailing list into
an IETF WG, with Martin Dürst and Mark Davis as co-chairs. With
Harald, Patrick, and John, _IF_ IDNA has a chance, it will be well
supported. I will not interfere with the process before proofing the
deliverables. My projects will have several lurkers who may elect to
give their opinion if a consensus is not met, or if there is an
attempt to word any exclusive solution in violation of RFC 1958
principle of constant change. So, the only remaining confusion I see
would be to call this WG a WG-IDN when it is only allowed to be a
WG-IDNA. This might create some confusion with the actions I engage
for six months now, within the IGF framework (an emergent IDN Dynamic
Coalition which may/may not chose to support IDNA).

2. to follow John Klensin's draft-klensin-idna-alternatives-00.txt.
For those interested: I answered his call and proposed the
***@idnalt.org mailing list to that end. I agree with John that
if IDNA does not work prefectly, http://idnalt.org will be useful to
document why it was the best solution. Anyone can subscribe to this
list and contribute. I do not plan to post there except to raise some
missing point if any. I can also transfer the list control to whoever
would like it. This list should be one of the sources of the
http://wikidna.org site.

As far as I am concerned, I said that I was working on my own
Multilingual Internet solution. This solution will need to be tested
without interfering with the ccNSO's Fast Crack project, so that it
calls first for its own test-bed to be dealt with. Then, it calls for
the solution to be documented, software to be developed, and tables
to be stabilized. This involves issues that have been delayed by the
RFC 4646 saga (one of missing concern I observe in the IETF is
lingual consistency, may be because all this is handled at the
application layer with some confusion between languages and
scripts?). I certainly understand the urgency of an IETF move in
order to match the ICANN Paris announcements. Even if I would love to
present a working solution in Paris, my priority is to introduce a
good general solution that works and that is able to work with the
semantic addressing and multilingual distributed registry system
projects I explained.

I note that all the IETF IDNA propositions so far have not addressed
many issues including 3LD phishing, babel names (when the ADE is
xn--a-registered-TM), and cannot even support French language off-the-shelves.

Good luck!
jfc