Re: [idn] Internet Driver Open Letter onInternationalized Domain Names

[John C Klensin <klensin@jck.com>]

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"
<shewmakb@fleishman.com> wrote:

> 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.
> steve@internetdriver.com
> 
> 
> 
>