Subject: [idn] Internet Driver Open Letter on Internationalized Domain Names

From: "Shewmake, Brad" <[email-masked]>
Date: Wed, 14 Nov 2001 09:36:24 -0800

MARINA DEL REY, Calif. (November 14, 2001) - The following letter was
issued
by Internet Driver, Inc. this morning at the Third Annual ICANN
Conference.
Press inquiries can be directed to Brad Shewmake at 415-348-2620.

Open Letter on Internationalized Domain Names

To ICANN, the IETF, and the Internet Community,

ICANN and the IETF are moving quickly toward adopting a standard for
non-Latin letter domain names. We are concerned that ICANN's singular
focus
on Unicode-based conversion (UBC) solutions for internationalized domain
names (IDNs) overlooks the inherent functional limitations of that
general
approach. We ask that ICANN, through its IDN Steering Committee, and the
IETF consider all available solutions and do not simply resign
themselves to
supporting the adoption of UBC.

UBC converts non-Latin based domain names into meaningless Latinate
strings
(e.g., the Japanese character for "dog" becomes "ier943kbo2k3"). This
approach creates a fractured Internet by establishing a separate Web for
each character script. Although all of these "character Webs" will
ultimately reside as alphanumeric domain names on the existing DNS
infrastructure, a user of one character script will have no way of
typing a
website or e-mail address registered in a different character script.

None of the UBC systems test-bedding today can access any existing
domain
name until that name is re-registered in a particular script. Hundreds
of
millions of Web pages published in non-Latin script already exist, yet
under
a UBC system these pages will not be accessible using non-Latin URLs
unless
they are re-registered.

Another seldom considered issue is a standard for e-mail addresses. An
e-mail address is resolved at the e-mail server level and not on the
DNS,
therefore, the IDN standard must work in conjunction with an additional
e-mail standard. If not, each character Web will have several
incompatible
e-mail systems. A similar challenge arises in creating and accessing
non-Latin script sub-site addresses. To date, both ICANN and champions
of
UBC solutions have devoted little consideration to these unresolved
issues.

Before any decision regarding IDNs is made, ICANN and the IETF must ask
the
following important questions: Can a UBC solution be adopted given its
inherent limitations? Do a series of unintegrated non-Latin character
Webs
adhere to the IETF "fundamental requirement . . . for the DNS to
continue to
allow any system anywhere to resolve any domain name?" Furthermore, can
a
standard be adopted that does not accommodate uniform non-Latin letter
e-mail and sub-site addresses? Given that there are non-UBC solutions
available today that do not suffer from these problems, the answer to
the
above questions must be a resounding no.

We are eager to help in any way possible and hope that ICANN and the
IETF
will act in the best interest of growing, preserving and protecting a
truly
global Internet community. We look forward to your response.

Sincerely,

Steve Klein
Chief Executive Officer
Internet Driver, Inc.
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 14 Nov 2001 12:51:17 -0800

At 09:36 AM 11/14/2001 -0800, Shewmake, Brad wrote:
>approach. we ask that icann, through its idn steering committee, and the
>ietf consider all available solutions and do not simply

Brad,

Forgive me, but I seem to be unable to find the Internet draft from you 
that specifies whatever technical approach you prefer.

Please provide the I-D name. If you have not posted a specification, then 
it appears that after two years of IETF working group effort, you are 
entreating adoption of a concept, rather than a specification.

Oddly, software engineers do very poor work implementing concepts.  They 
need specifications.

So do IETF working groups.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Nov 2001 10:52:44 -0500

Brad, Steve,

I am pleased that you have sent your letter, to the IDN list,
rather than blind-copying it and its equivalent to lots of others
(as you have done before).  It at least permits a discussion of
what is happening here, rather than private explanations that, as
far as I can tell, you are largely ignoring.

In the hope of encouraging you to take a more constructive
stance, let me summarize, in this public forum, what I believe
you have been told in those private conversations and email
messages.

(i) If the IDN working group, after the last two years of
efforts, has consensus about anything, it is that the problems
with internationalized access to domains names (and the narrower
"international domain names") issues, are very complicated.
Anyone who comes along and seems to be saying "I have a solution
that eliminates all of the problems and doesn't have any
side-effects, restrictions, or tradeoffs" is immediately
suspected to be either ignorant or a charlatan.  

(ii) The IDN effort is very late in its work cycle.  Something
that comes along at this stage with a statement that amounts to
"we have a plan, we want you to consider it favorably, but we
won't really tell you what it is" is suspected of being
obstructionist or of trying to sell a new variety of snake oil.
The _only_ solution to that problem at this stage is for you to
post an Internet Draft that explains exactly what you propose to
do, how it works, how it avoids the problems that many of us have
pointed out to you

(iii) "Solve this problem by using some approach that does not
require DNS modifications or tricks" is not, despite the tone of
your letter, a new concept.  Even when the IDN WG was limited to
requirements work, its charter was carefully written in terms of
"internationalized _access_ to domain names" to permit
consideration of those options.  There have been several notes
and drafts posted to discuss those options and why the present
DNS may not be the right place to deal with the
internationalization issue
(see draft-klensin-dns-role-01.txt as one example, although, for
your purposes, there is better material in the WG list archives).
And other companies and individuals have written extensively in
that space -- about layered searching, about keywords, about
service location, about phonetic approaches, about browser
tricks, and so on.   If you want your work to be taken seriously,
you need to provide enough information that it can be compared to
those approaches or, even better, start on those comparisons
yourself, but do so in writing.

(iv) Unfortunately, while you have been playing the game of
sending notes with little technical content to undisclosed lists
of recipients, responding to requests for technical details by
pointing back to press releases, etc., the deadline for posting
new Internet Drafts that might be considered at the December IETF
passed you by.    That means no agenda time.  It also means that
several of us who would have been willing to look at a
preliminary draft in private when you started to tell various of
us and, we gather, ICANN, a month or so ago that you had a new,
breakthrough, proposal that was being worked with the IETF are no
longer willing to do so.  If you want to be taken seriously, post
an Internet Draft with details.  And please make sure you
understand the rules (see the IETF web pages) for handling new
drafts between the close of the pre-IETF posting deadline and the
close of the corresponding IETF; otherwise your draft might get
inadvertently lost.

(v) Finally, note that "above DNS" and more general
internationalization approaches are very much on the agenda for
the Salt Lake City IETF.  Following that work might at least help
you with better context for explaining your ideas when you write
that draft.

Steve, if I can give you some free advice in public: I'm willing
to give you folks the benefit of the doubt and assume that
Internet Driver might have some technology that would be of
interset to the IETF.  But the IETF does not function well with
press agents or other intermediaries between the technical
contributors and the community -- if you and your colleagues have
serious technical/ engineering ideas that are worth considering,
you need to get them on the table, not substitute a publicity
campaign for them.  Such campaigns are a waste of resources or
worse -- not only yours, but ours-- and raise the suspicion that
something unpleasant is going on.  If you have issues or
suggestions, please correspond directly with one or more of us.
But don't expect much patience until you are willing to put the
specific technical details of a proposal on the table in Internet
Draft form.

regards,
   John Klensin
   Technical Advisor to the IDN WG

--On Wednesday, 14 November, 2001 09:36 -0800 "Shewmake, Brad"
<[email-masked]> wrote:

> MARINA DEL REY, Calif. (November 14, 2001) - The following
> letter was issued
> ICANN and the IETF are moving quickly toward adopting a
> standard for non-Latin letter domain names. We are concerned
> that ICANN's singular focus
> on Unicode-based conversion (UBC) solutions for
> internationalized domain names (IDNs) overlooks the inherent
> functional limitations of that general
> approach. We ask that ICANN, through its IDN Steering
> Committee, and the IETF consider all available solutions and do
> not simply resign themselves to
> UBC converts non-Latin based domain names into meaningless
> Latinate strings
> (e.g., the Japanese character for "dog" becomes
> "ier943kbo2k3"). This approach creates a fractured Internet by
> establishing a separate Web for each character script. Although
> all of these "character Webs" will ultimately reside as
> alphanumeric domain names on the existing DNS infrastructure, a
> user of one character script will have no way of typing a
> None of the UBC systems test-bedding today can access any
> existing domain
> name until that name is re-registered in a particular script.
> Hundreds of
> millions of Web pages published in non-Latin script already
> exist, yet under
> a UBC system these pages will not be accessible using non-Latin
> URLs unless
> they are re-registered.
> 
> Another seldom considered issue is a standard for e-mail
> addresses. An e-mail address is resolved at the e-mail server
> level and not on the DNS,
> therefore, the IDN standard must work in conjunction with an
> additional e-mail standard. If not, each character Web will
> have several incompatible
> e-mail systems. A similar challenge arises in creating and
> accessing non-Latin script sub-site addresses. To date, both
> ICANN and champions of
> UBC solutions have devoted little consideration to these
> unresolved issues.
> 
> Before any decision regarding IDNs is made, ICANN and the IETF
> must ask the
> following important questions: Can a UBC solution be adopted
> given its inherent limitations? Do a series of unintegrated
> non-Latin character Webs
> allow any system anywhere to resolve any domain name?"
> Furthermore, can a
> standard be adopted that does not accommodate uniform non-Latin
> letter e-mail and sub-site addresses? Given that there are
> non-UBC solutions available today that do not suffer from these
> problems, the answer to the
> We are eager to help in any way possible and hope that ICANN
> and the IETF
> will act in the best interest of growing, preserving and
> protecting a truly

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 15 Nov 2001 08:53:09 -0800

John, please allow me to be a bit less charitable than you. I spoke 
with someone from Internet Driver a year ago at the ICANN meeting, 
and explained the IETF process to them. The fact that they have not 
published an Internet Draft in a year indicates they don't intend to 
work with the IETF rules.

Further, Internet Driver proudly proclaims that their technology has 
pending patents. Unless the company explicitly details to the IETF 
how the licensing on its pending patent would be handled, I don't 
think it worth the time to read whatever technical document they 
produce.

This is not a criticism of the technology: it might be as wonderful 
as they suggest. The same is true for many of the encumbered 
technologies that have been presented in this WG. They just don't 
seem destined to become widely-used Internet standards.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Nov 2001 08:41:08 -0800

>do, how it works, how it avoids the problems that many of us have

Given that the Driver folks apparently are new to the IETF world, please 
permit me to elaborate a bit about the document that is needed:

It is a technical protocol specification that lays out all of the 
procedures and formats to be used.  The document needs to be sufficient to 
permit an implementor to build an interoperable version of the capability.

This must be considerably more thorough than the section of a patent that 
supposedly provides implementation details to a person practised in the art 
of the patent.

d/

ps.  Given the history of postings and claims by iDriver, and the fact that 
details have not been forthcoming, I propose that their activities occupy 
this working group no further, until the necessary protocol specification 
have been posted as an Internet Draft.

----------