Re: [idn] RE: An idn protocolfor consideration in making the requirements

["A. Vine" <avine@eng.sun.com>]

I am with Ned on this one.
Reality says that clients are faster to upgrade than server infrastructure.  For
DNS, the upgrade is much less likely to be upgraded than, say, an email server. 
But the reality is that once domain names change, many, many servers will have
to be upgraded to handle 8-bit.  I can only imagine what it would take to get
our IS folks to implement them.

In addition, I find it very hard to believe that an email client which can't
interpret base64 or QP could handle UTF-8, UTF-16, or UCS-2.  The likelihood is
that all would be gibberish.  So, the user will have to upgrade.  Further, the
odds that a user can even type in non-ASCII domain names in old software, and
then have that software send something comprehensible to various routing
components without upgrading the software is highly unlikely.

The 7-bit restriction is hard-coded all over the place.  Clients will have to
upgrade anyway to take advantage of the new non-ASCII domain names.  Old clients
which receive them can receive 8-bit gibberish which might cause them to crash,
or fail in some way, or 7-bit gibberish which looks bad but works.

The users who want non-ASCII domain names will upgrade.  Other users just don't
want things to break.  And I assure you, 8-bit will break things.

Andrea
-- 
Andrea Vine, avine@eng.sun.com, iPlanet i18n architect
A word is not a crystal, transparent and unchanging--it is the skin of a
living thought, and may vary greatly in color and content according to the
circumstances and time in which it is used. - Supreme Court Justice Holmes

ned.freed@innosoft.com wrote:
> 
> > I will cheerfully be open-minded to any proposal that
> > "works" *both* in Ned's sense ("no protocol mishaps"?)
> > *and* my sense:
> 
> >       User sees only (ever): human selected fallback
> >       domain names or internationalised domain names in
> >       a commonly accepted and globally viable plain text
> >       encoding (which are: UTF-8, UTF-16). Plus, of
> >       course, fulfillment of Ned's sense of "works" too.
> 
> Suppose for such a moment that we develop a proposal defining such a solution
> which is viable and deals with all the issues John Klensin raised, plus many
> others that haven't even been mentioned yet. And further suppose that
> deployment of new DNS software is a requirement of that solution, of course
> along with fallback facilities and such for various application services.
> 
> This last point means that you cannot simply upgrade your local software to the
> new crop of applications that support this stuff and start using these names
> willy-nilly. You have to wait for infrastructure upgrades to the DNS that are
> in some, and perhaps even many, cases beyond your control.
> 
> Now suppose we ask the DNS operations folks how long it will reasonably take
> for the necessary software to deploy to any significant degree, keeping in mind
> that we're dealing with a critical infrastructure component provided by folks
> who have a lot on their plate besides internationalization. I'm not a DNS
> operations person, but I would not be totally amazed if the answer that comes
> back is most conveniently expressed in units of decades.
>
...snip... 
> 
> > The no-too-positive experience with using application
> > specific encodings that are reencodings into ASCII,
> > i.e., QP and BASE64 for text, must be taken into account.
> 
> Fine, as long as the totally negative experience with "just-send-8" that
> preceeded the development of QP and base64 is also taken into account. (I have
> a very long memory.)
> 
...snip...
> 
> I also speak for end users -- users who have shown that they are able to
> tolerate an occasional glitch in decoding of noncritical elements but who won't
> accept total untraceable data loss, and who may or may not be willing to wait
> for a very long time for the perfect solution to emerge.
> 
>                                 Ned