Re: [idn] Some thoughts...

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

Since I have been fairly quiet on the list of late --and will
probably go back to being quiet shortly after this note-- I
wanted to respond to James's "afterthoughts".  Warning: this is
going to be fairly analytical and hence long; please average it
out over all the shorter notes I haven't written.   Two
preliminary warnings:

	* These are personal thoughts and musings, based on some
	years of experience with the Internet. But they don't, in
	any sense, represent "official" opinions ("tech advisor",
	"IAB Chair", or whatever).  And I may change my mind
	about them by Monday -- that happens sometimes.
	
	* While James's note identifies ACE (or ACE-like)
	solutions as the right ones if we want a short-term/quick
	approach, and UTF-8 ones as best for the long term, I'm
	not prepared to buy into either assumption right now, at
	least for the purposes of this note.  So, when I say
	"short term", I may or may not be talking about ACE.  And
	"long term" may or may not imply DNS-embedded UTF-8.

So, two somewhat-related thoughts...

(1) Solutions optimized for the short-term versus the long-term.

It is quite possible that we have already lost the short-term
window.  Whether presented (or disguised) as "register your
multilingual name TODAY" campaigns based in a real or bogus
ccTLD, or hidden deep in the hierarchy (possibly in
scheme-specific subdomains), or as testbeds, we've got deployment
of "solutions" today.  Of course, they don't interoperate, and
some of them provide localization rather than an approach that
will work internationally, and some will wreck applications, and
so on.   But, we may be at, or very close to, the threshold at
which deployed things win on the Internet unless they are really,
seriously, obviously, broken.  (See section 1.4 of
draft-klensin-dns-role-00.txt if you haven't heard my tirades on
Internet applications deployment and updating and have a desire
to see an overview of them).

The closing window also suggests that, commercially, it is
probably too late for a new entrant to try to sell a good/
comprehensive (whether WG-short- or WG-long-term) solution into
the marketplace while many of the users (and purchasers) are
focused on getting something quickly as long as it usually works
(for them). Independent of the ACE versus UTF-8 battles, etc., we
know that localization solutions meet the test of "usually
working" for selected homogeneous groups of users and that most
of them are *much* easier to design, implement, and deploy than
internationally-interoperable ones.

If that view is correct (I hope it is not), then there is no
point worrying about a "quick solution" in terms of deployment.
The WG had best concentrate on producing something that is really
and obviously superior and The Right Thing, and then hoping it
can be implemented and demonstrated well enough to be fully ready
when the warts and cancers of the now-deploying quick approaches
become obvious to decision-makers and in the marketplace.

That does not imply that there is any time to waste.  Wide
deployment of non-interoperable solutions that cause applications
problems would be a disaster for the Internet, but, if we have a
solution ready when things start to break seriously, we will
recover.   If end users see a problem as seriously hurtful, we
can actually deploy solutions fairly quickly.  The things that
are hard to deploy are those that fix problems users don't know
they have, or that provide functionality that is being provided
moderately well by something that exists already, or that improve
"the Internet" without having *very* obvious benefits to
individual end-users.

But, if we don't have a solution ready -- and "ready" probably
implies not merely a Proposed Standard but sufficient
implementation and interoperability testing at both the DNS and
applications level to make us quite sure -- then the first-round
quick-fixes and kludges will be replaced by a second round of
quick-fixes and kludges.  That second round will be of no better
quality than the first, but will contain patches to cover up the
most obvious and severe problems.  And we will probably never get
rid of them (anyone contemplated redesigning and replacing telnet
lately?).


(2) Deployment times

While I tend to fall on the "10-20 years", rather than the "3-5
years" end of the numeric estimates, I try to avoid giving them
at all.  It will take what it takes, and the real numbers will be
strongly influenced by what one chooses to measure.  For example,
even the meaning of "deployment to half (or 90% or some other
number) of Internet users" is questionable in the presence of
rapid (exponential?) growth in the user (or host) population.
If, for example, one assumes that the size of the network doubles
every year, and that every new machine installed after some date
contains the updated software, then 50% deployment takes one year
after that date, even if not a single older machine is
retrofitted.

The more interesting question is whether one particular approach
or technical solution can be deployed more quickly than any
other.  I suggest that, kludges that require users to do painful
things aside, the answer is "no".  Unless there is some magic
around that I haven't seen, having an application accept and
present multilingual characters requires changes to that
application.  Once appropriate APIs or library routines are in
place, none of the approaches under discussion are likely to be
big deals to implement, unless the particular application
implementation is pervasively 7bit.  And I'd expect to find
really pervasive (internal, not in interfaces) 7bit-only code to
exist only in application code migrated forward from "there just
isn't an 8th bit on that hardware" platforms.   I suspect we can
find some of those code bases, but not very many of them (and
they probably need overhauling anyway).  For the rest, the
significant, time-consuming, steps will tend to be: deciding to
open the code, getting motivated to open the code, getting around
to opening the code, and actually doing the deed -- not the
extent of the changes made in the last step.  I suspect that all
of us who have implementation and maintenance experience have
been there.

Of course, once the changes are made, the hard phase --actually
getting them into the field and getting them installed-- starts.
And that certainly doesn't depend on the technical details of the
changes.

So, to a first-order approximation, my guess is that "change app
to decode ACE and present multilingual characters", "change app
to call something besides 'gethostbyname' where the new interface
does multilingual and maybe directory things", "change app to
decode UTF-8 and present glyphs corresponding to IS 10646",
"change app to call directory interface before calling
'gethostbyname'", or mixtures of them, all have the same
time-to-deploy periods.  It is too bad, really, but I don't find
any of the "this can be deployed a lot faster than that"
arguments very persuasive.

So, let's do whatever we need to do just as quickly as we
possibly can, but let's do it very well and with an understanding
of long-term implications clearly in mind.  Every month we lose
increases the risk of a second round of kludges and adds many
users and machines who will be left behind or need to be
converted --to something-- later.  But the "get a standard out
early enough to control first deployment" window is closing
rapidly, if not already over.

     john

<James@Seng.cc> wrote:

> Afterthoughts I have from ICANN meeting in LA.
> 
> Paul have done an excellent summary on the ICANN IDN Workshop
> so anyone interested should mail him for details.
>... 
> So I am not sure now how we should approach this problem. It
> has been fun so far, as the WG progress, exploring various
> solutions, getting all sort of interesting ideas been throw
> about. But hey, the message is clear: Fun is over.
> 
> Now, there is REAL pressure to produce something which is (1)
> Right long-term approach (2) Deploy Fast. Most solutions we
> have falls either in (1) or (2) and nothing we seen 2/2 yet.
> And all of them are subjective.
> 
> Honestly, I am still not clear which direction is the right
> way. Should we look at something which is compatible with the
> existing infrastucture such as ACE solution or should we look
> longer-term UTF-8 with consequences to break down the current
> infrastucture.
>...