Subject: Re: Charset stuff (Re: DNS SRV for Kerberos)

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 01 Dec 1999 04:11:59 +0900

At 09:22 1999/11/29 JST, Masataka Ohta wrote:

> So, why can't you simply accept the reality that Unicode is NOT used
> at all, dispite all the efforts of unexperts?

Just for the information of people not familliar with the situation:

Both Microsoft Office (for most of its parts in Office 97, for all
of them in Office 2000) and the product suite from Justsystems
(Ichitaro,..., the once marked leader and now runner-up to
MS Office) use Unicode throughout. Users may have as many complaints
with these products as they have with any others, but they definitely
have no problems with Unicode. And I'll leave it to the reader to
guess how much these products are used :-).

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 1 Dec 99 22:13:04 JST

Martin;

Thank you for your silly ass information.

> MS Office) use Unicode throughout.

They do not.

They use Shift JIS for text files throughtout.

Users do not accept anything else.

> Users may have as many complaints
> have no problems with Unicode.

Users do not accept Unicode and they definitely have no problems with
Unicode, of course.

> And I'll leave it to the reader to

:-)

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 2 Dec 99 11:06:50 JST

James;

> For someone who claim to be an expert in encodings and I18N, your

Simply copying website do not make you an expert.

> information or lack of it seem to be dubious. Any smart person can
> easily fire up a browser, and check up Microsoft website on the
> information they provide about Office2000 before they give their 
> 'silly ass information' (to use the donkey's words). But I suppose
> you do not belong to that category. 

My laptop I have been and am now using is installed with Office2000
that I don't have to check Microsoft website to know they do use
Shift JIS text, not Unicode.

> Coming back to topic, I have been following this thread about Charset
> especially it is related to I18N Domain Names. I think there are two

ASCII domain names are the I18N domain names.

There is no Charset stuff to worry about.

							Masataka Ohta

---

From: James Seng <[email-masked]>
Date: Thu, 02 Dec 1999 09:46:55 +0800

Dear Ohta,

Anyhow, I do admire your zealotous quest against Unicode and your
capability to piss off everyone else along the way.

Coming back to topic, I have been following this thread about Charset
especially it is related to I18N Domain Names. I think there are two
school of thoughts on how it can be done: 1. Unified everything into 
Unicode (or something) 2. Use localized encodings and tag them.

Each has its advantages and disadvantages and it is hard to say which
is better. But if strict matching is not a concern, then generally, 
using localized encodings with tag is better idea. MIME is a good place
to start. Rob Austein also have a proposal on how to do tagging.

-James Seng

Masataka Ohta wrote:7

---

From: Terry Lambert <[email-masked]>
Date: Thu, 02 Dec 1999 11:33:29 -0800

James Seng wrote:
> Coming back to topic, I have been following this thread
> about Charset especially it is related to I18N Domain
> Names. I think there are two school of thoughts on how
> it can be done: 1. Unified everything into Unicode (or
> something) 2. Use localized encodings and tag them.
> 
> Each has its advantages and disadvantages and it is hard
> to say which is better. But if strict matching is not a
> concern, then generally, using localized encodings with
> tag is better idea. MIME is a good place to start. Rob
> Austein also have a proposal on how to do tagging.

The problem I have with tagging is that the tagging
must be done via a covert channel of some kind, and
this leads to a lot of problems with caching and
secondaries, unless the tagging is done in-band in
the data, since you have to attribute the DNS server
by character set and encoding, or provide "name, attr,
value" instead of "name, value" in responses.

To do this in-band in the data effectively means that
you either choose to balkanize the internet into zones
that are treated by locale (each DNS server operates
in one locale, and doesn't communicate with others not
in the same locale, and the covert channel is the locale
setting on your local DNS server or resolver), or you
perform a namespace incursion.

For the namespace incursion soloution, you have to be
able to look up a name that refers to a Japanese locale
DNS name in order to access a server named in that
locale, and get the data back, since the contents of
that server may be the English pages of a Japanese
company (before some idiot suggests it, naming a server
in every possible character set is not a viable option).

It appears that this would work, but it means that the
top level domain needs to be the character set tag,
and that the current top level domains would go under
the top level domain "DNS-ASCII" (or whatever), or you
could not make this work.

This seems to have the undesirable tendency to take the
DNS and break it up by character set, with the obvious
inevitability that ".com.DNS-ASCII" will be the default
in all browsers, just as ".com" is the defailt in all
browsers today.

A somewhat less obvious, and at the same time more
alarming, possibility is that the default locale of
the user would be used.  This would have the effect
of regionalizing the DNS, as effectively as if you
has put "=?ISO-2022-JP?Q?" in front of and "?=" at
the end of all DNS components in Japanese DNS servers.

Perhaps this is the intentional hiddden agenda of
the character set tagging advocates: shore up the
dissolution of tight political control on information
flows agross their geopolitical boundaries.

A variation on this, which is obvious in light of
the previous variation, is to use the "accept languages"
settings to do lookups in all of the possible locales
usable by the user.  This is even more alarming: it
has the same geopolitical balkanization effects, and
at the same time increases the overall DNS load
significantly.

Most alarming would be to do the lookups in all
possible character sets for every lookup; the DNS
load for doing this could be so significant as to
render it intolerable: with the result that we fall
back into a balkanizing strategy.  The recent TTL=0
discussion must teach us that, if it teaches us
nothing about our incorrect volatility assumptions.

I think that no less than a global namespace can be
used for DNS.  Right now, the alphabet for this is
"DNS-ASCII", a restricted subset of the US-ASCII
character set.

Regardless of whatever other conclusions are reached,
I think that character-set tagging, via covert channel,
promiscuous knowledge (as in assuming ".com"), or
otherwise can not be tolerated.

Ohta-san should feel free to define an "Ohtacode"
character set to compete with Unicode.  He can
start with JIS-208 + JIS-212 as a basis, if he so
chooses, to give him a head-start on supporting 21
of the worlds written languages; it doesn't matter.

The point is that no less than a global namespace, a
_single_ alphabet and encoding, can be used for DNS,
both now and in the future.  Any less, and we risk
tearing down what has been so painstakingly built up
so far, and I believe _that_ is unacceptable.  The
internet today does not work _because_ of geopolitical
divisions, it works _in spite of them_.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: James Seng <[email-masked]>
Date: Fri, 03 Dec 1999 19:43:02 +0800

> value" instead of "name, value" in responses.

Agreed. 

But notice my statement, "But if strict matching is not 
a concern...". Therefore, if you are only putting data
in DNS RR as informational data, then tagged data with
localised encoding is easiler. 

It only become a problem when you want to process the
information such as doing comparison. Doing it on the DNS
itself is always a bad idea and hence, a Unified encoding
solution is preferred for processing as you can be sured to 
obtained the same bits for the same data irregardless of 
what encoding you use originally.

In this case, does Kerberos need these in DNS SRV RR for
informational or for processing? Sorry, I am not too familiar
with Kerberos.

-James Seng

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 05 Dec 1999 12:46:53 +0100

Terry,
this is all terribly, terribly relevant.

But the right locale for this is the IDN mailing list: [email-masked], 
[email-masked] to subscribe.

We need you there!

                   Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]