Subject: Re: draft-duerst-dns-i18n-02.txt

From: Robert Elz <[email-masked]>
Date: Wed, 28 Jul 1999 10:13:12 +0700

Date:        Tue, 27 Jul 1999 01:08:27 -0700
    From:        James Seng <[email-masked]>
    Message-ID:  <[email-masked]>

  | I will post it to the namedropper when it is ready.

Please, don't send the draft, but do send us a notification of its
availability.

  | Although I am already convience that iDNS can be done using UTF-8, I am
  | worried about other related protocols which depends on DNS.

I think this is an unnecessary worry.   The DNS already encodes names in
a way different from that used by any other protocol that I am aware of
(though I have been attempting to convince a part of the DHCP community that 
they ought be using a DNS format encoding of domain names where possible).
Names sent into the DNS already need to be transformed from the format they
appear in e-mail headers, etc, so attempting to keep the two the same is
(and always was) a lost cause.   Further, it would always have been a
pointless one.

kre

---

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 28 Jul 1999 13:33:05 +0900

> (and always was) a lost cause.   Further, it would always have been a

Hello Robert,

I think you don't get James' point here. A conversion is already
necessary and implemented of course, but the problem is that if
this conversion is applied to a DNS name stored in UTF-5, it will
lead to a valid (although not very readable) DNS part of an email
address. On the other hand, applying the same conversion to something
stored in UTF-8 will produce something else in UTF-8, which in
general is not suitable for an email address unless the IETF
email specs and their implementations are appropriately updated.
Same thing for many other specs and implementations that assume
the current syntactic restrictions on host names.

Regards,   Martin.

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 28 Jul 1999 13:14:49 +0700

Date:        Wed, 28 Jul 1999 13:33:05 +0900
    From:        "Martin J. Duerst" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think you don't get James' point here. A conversion is already
  | necessary and implemented of course, but the problem is that if
  | this conversion is applied to a DNS name stored in UTF-5, it will
  | lead to a valid (although not very readable) DNS part of an email
  | address.

I think that you're saying here, that if your system knows UTF-5, you
can have a UTF-5 domain name, and send me e-mail from that name, and that
my system which knows nothing of UTF-5 will be able to interpret the name
and reply to you - your address will look ugly, but it will still meet
the syntax requirements of everything that matters, and be functional.

However, and given that I haven't seen James' proposed new draft yet, and
am relying upon your old one, I believe this relies on the ".i" TLD
working, doesn't it?   I'm afraid I have never been able to give much
credence to the possibility of that, and the parallel tree that it implies,
is practical in any sense at all.   It would mean that to allow anyone to
have a UTF-5 name in .AU I would need to create an AU.i domain, and under
that COM.AU.i - and unless I were to want to immediately add a large number
of lame delegations to the DNS, I'd have to administer it separately, only
adding delegations when requested, while somehow attempting to ensure that
control of sub-domains rested with the same people who run the equivalent
COM.AU domains.   Thanks all the same, but no thanks.

I'm afraid that I assumed that the only way that ".i" could ever work in
practice, was for the resolver library routines to recognise that, and treat
it as a hint to do a different kind of lookup of the name, than the one
they would normally do.   That way could work - though I don't think a lot
of mangling the domain name space that way, but implementing it this way
would require my resolvers to be updated before I am able to reply to a
message containing your UTF-5 domain name, and if that were to be a 
requirement, then it seems to be that they can be modified at the same time
to encode the DNS lookup in UTF-8, just as well as in UTF-5.

That is, if it were considered appropriate, the e-mail specs could be
left as they are, e-mail addresses could continue to demand ascii domain
names, and utf-5 encoding, with a .i pseudo-tld could be used to mark
them.   The DNS specs could say that any domain name ending in ".i" is
one which is presented to the resolver in UTF5, and needs to be converted
to UTF-8, the ".i" removed, and then looked up in the DNS.   This allows
the DNS to have the "natural" names, avoids any kind of parallel DNS
tree from being required, and also allows a natural progression towards
extending the e-mail interface in the future if desired (doesn't tend to
lock the world into what currently seems like the only implementable
solution, forever).

In any case, I look forward to seeing James' promised draft, where I'd
hope that the rationale for all of this will be set out.

kre

---

From: James Seng <[email-masked]>
Date: Wed, 28 Jul 1999 18:29:19 -0700

Hi all and Robert,

I think there is some general misconception. 

Internationalization DNS effort is not an issue of martin draft
vs skwan draft. there are merits in both draft, and neither draft
in its current state address all the issues i have encountered 
while doing my iDNS testbed with the NICs for the last year.

What is apparent is that iDNS does not really care whether the final 
domain name is in UTF-5 or in UTF-8. Either encoding we choose, you 
still have to take care of the iDNS issues which I shall mention 
later. But let me reply your mail first.

> the syntax requirements of everything that matters, and be functional.

UTF-8 is currently the standard UTF for IETF. Most OS which supports
Unicode already expressed that UTF-8 is the encoding they will use. The
beauty of UTF-8 is obviously in the compatibility with US-ASCII thus 
making incorporation of the current existing domain name space easiler.

UTF-5 is a new proposal, which of course means no vendors is going to
support it at the moment. However, it has a elegance in that the final
Unicode strings is within a limited A-V,0-9 character set which means
it should not break any existing DNS client/server. In fact, if you go
beyond DNS, I doubt it will break any other existing client/server for
other protocols. This makes it extremely compatible UTF.

I agree with Martin that UTF-8 should be the long term solution. 
However, it should be noted that which ever encoding we used, we 
have to look beyond DNS, and think in other related protocols. In 
particular, the main concern currently is email. While it is possible 
to have a domain name in UTF-8 working perfectly, it is not possible 
to have an email address totally in UTF-8 without a overhaul in SMTP 
protocol and all the clients and servers. Of course, it can be done 
and it will take time.

On the other hand, UTF-5 works pretty well, required minimum changes 
in protocols and softwares. This makes it an ideal encoding in a 
short-run.

Ultimately, it is my believe that an DNS system should be designed 
properly based on UTF-8. But in the meantime, our effort to push for 
UTF-5 is a case of theortical vs practical issues. (Theortically UTF-8 
is better. In practice, UTF-5 works and implements immediately)

At various meetings, at APRIOCT and at INET, i have tried to get an 
agreement on this issues but I couldnt since the iDNS is so new and
I have to spend the session explain the background all over again. 
In fact, there are queries why we are using Unicode in the first place!
(Unicode v1.0 did a pretty bad job for Asian language. It is a 
historical problem on how they handle the Asians in general when they 
first started.)

Anyway, I am planning to hold an iDNS BoF at the next IETF meeting 
in Nov under Application Area so we can trash out this issue. 

> working, doesn't it?   I'm afraid I have never been able to give much

Having an new ".i" TLD has its advantage. While, France in French may end
up using .fr and Germany in German may still be .de, Taiwan in Chinese is
not likely to use .tw nor Japan in Japanese going to use .jp. Of course,
unless you define your i18n to mean only European languages.

> COM.AU domains.   Thanks all the same, but no thanks.

There is no conflict as you mention here. You are imaging things :)
If a domain name is strictly US-ASCII, then i do not see why you should 
put it under .i hierarchy. You only use the alternative hierarchy if it 
is a multilingual domain name.  In certain ways, I see the separation 
as an advantage in maintaince and also helped a little by balancing the 
current hierarchy.

> left as they are, e-mail addresses could continue to demand ascii domain

So does that means while I can have a Chinese domain name, I couldnt
use my Chinese name as my Email name? I think you have miss the point
of the issues of our current effort.

27% of the Japan population is using the Internet. It is estimated that
only 10% Japanese can read and write English and maybe 1/2 of these can 
speak it properly. So what do the rest of the 13% do? They stick to their
whole of Japanese website, and sending to each another email in Japanese.
So what you going to tell the rest of the 73% of the Japanese who is
waiting to join the NET? Too bad, learn English first?

Consider the case in China with 4million Internet user up from 1/2 million
in 1998. This only represent less than 1% of the population and estimately,
about only 2% China users can actually read/write English. China may not
be too bad since it is possible to use transliteration via Hanyu Pinyin
and get a domain name like zhaodaole.com or "findit.com". Still, looking
at the word "zhaodaole" dont really give me any clue that it is means 
"findit".

Consider the case in Taiwan, where Hanyu Pinyin wasnt even used. So 
"zhaodale" probably dont even makes sense to them.

I could go on but my point is that a half-way solution is not acceptable. 
We either have i18n of DNS or we dont. And if we do, we should at least 
make sure the other relating protocols can be i18n with the domain names.

> lock the world into what currently seems like the only implementable

These are implementation issues.
 
> hope that the rationale for all of this will be set out.

I have already submitted the draft to [email-masked]. But I
think you will be disappointed to know that the purpose of the draft is 
to define UTF-5, and not to address iDNS issue. As I mention above, iDNS 
issues are issues need to be address irregardless whether we use UTF-5 or
UTF-8. And that is the draft I still writing and I hope to get it done 
before the next IETF meeting.

So what are these iDNS issues? Hell lot and most of it wasnt even addressed
in Kwan's draft or even Martin's draft.

Lets start with something you know. Case problem. DÜRST or Dürst? 
I think this was mention in Kwan's draft and the solution is to convert
it to lower case. :)

Now, lets consider language outside European. For example, Chinese have
Traditional and Simplified character which have different code point in
Unicode, and of course different glyph but they mean the same thing. For
example, Taiwan in Chinese can be either (in Unicode) U+53F0 U+6063 or
U+81FA U+6063. Both means Taiwan and both are valid. Converting between them
are unfortunately not possible due to CJK unification. This is because
what is Simplified character of a Traditional character in Chinese may not
be so in Japanese. In fact, Japanese would prefer no such conversion.
Korean are simplier since they already stop using the chinese ideograph and
replace it with Hangul.

Speaking of Japanese, lets take "JAPAN" or NIPPON. It is normally written
in Kanji with using 2 glyph. On the other hand, Japanese childrens do not
learn Kanji before grade 6. They learn the basic Hiragana instead and to
them, the hiragana form of NIPPON are "correct".

And you can move on to a other languages and you will find other problem 
and they are very different. e.g Tamil have their "upper" and "lower" case
glyph and unfortunately in Unicode, these "upper" and "lower" case glyph can
only been obtained via kerneling (as Tamil was not given enough code space).
This means conversion from "upper" to "lower" case is not a simple of A->a.

This is only part of the issues we need to address. If you are interested,
I strongly suggest you subscribe to our APNG iDNS Working Group. Send an
email to [email-masked] with "subscribe" to join the mailing list.

-James Seng

---

From: James Seng <[email-masked]>
Date: Wed, 28 Jul 1999 18:29:19 -0700

Hi all and Robert,

 

-James Seng

---

From: James Seng <[email-masked]>
Date: Thu, 29 Jul 1999 13:41:33 -0700

Masataka Ohta wrote:
> What do you mean "unification of different languages"?

Let me correct myself. I meant "Code Unification". This is one issue
with iDNS which we strongly believe we have to handle.

Apparently, your suggestion is we shouldn't do any unification. Now,
consider somone registered a domain in Shift-JIS. This means he will
have to repeat it for EUC-JP, JIS, ISO-2022-JP, UTF-8 and so on. This
increase the complexity of maintaining the zone files, delegation etc.

Having decided we need to do code unification, we proceed to find an
appropriate unified encoding. Unicode come to mind since IETF supports
that. MULE was also suggested by JPNIC and it was also considered. 
Conclusion? No, there wasn't a conclusion actually since we never 
managed to get vote on this issue. And thus, as status quo, we proceed 
with Unicode along with Martin draft using "UTF-5".
  
> In the first place, Unicode is not used at all.

Great. If you feel so strongly against it, then please turn up in the
next BoF and we vote against it. I think the other strongest contenter
is MULE.
 
> That's why it can not go anywhere.
> Local issues must be solved locally without much international inputs.
> Don't call localized DNS iDNS.
> 
> You can take statements above of mine made as a chairman of APNG
> Internationalization/Localization WG.

I am disappointed. But it is your choice.

-James Seng

---

From: James Seng <[email-masked]>
Date: Thu, 29 Jul 1999 11:36:05 -0700

Masataka Ohta wrote:
> > Unicode is unfortunately not widely used in Asian countries.
> 
> It's you who have shown Asian examples as a supporting factor for
> your proposal.

Unicode may not be widely used as the client, in Asia or otherwise,
But it does not mean we cannot use Unicode as a backend for unification 
of different languages. But apparently, your disagreement is that we 
should not even attempt to unify these domain names, and much worst, to 
even use Unicode in the first place. And thus, I suppose we not discussing 
this on the same level.

It should be noted that the APNG iDNS WG effort is done with inputs from
many countries around Asia-Pacific. And our WG is a co-effort to pull all
these inputs into a proper working draft. But alas, if you do not agreed
with our charter nor our effort. It is unfortunate as I believe you would
be a great help to us with your native knowledge of the Japanese encodings.

> > And lets not get into Tamil with 100+ encodings,
> 
> Tamil characters can be encoded by, for example, ISCII.

Actually, ISCII is insufficient. I suggest you take a look at the 
new proposed TamilNet monolingual and bilingual character set. 
ISCII attempts to capture all the different Indian languages in 
a single code space of 255 characters and also to co-exist with 
US-ASCII is a way out-dated. Unfortunately, once again, Unicode 
presumed ISCII is sufficient.

-James Seng

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Jul 99 8:14:59 JST

James;

> unless you define your i18n to mean only European languages.

Japan local software has no problem to convert Japanese National name
represented in Kanji to "jp".

However, this is a bogus argument, because, people using local domain
names do not bother to add local country names, neither in Latin nor
in Kanji characters. Country names are just omitted.

> only 10% Japanese can read and write English and maybe 1/2 of these can=20
> speak it properly. So what do the rest of the 13% do?

FYI, more than 99% of Japanese mails use ISO-2022-JP encoding.

Rest use ShitJIS. No one use Unicode for mail nor for WWW, neither
in UTF-8 nor UTF-5.

> Consider the case in China with 4million Internet user up from 1/2 millio=
> n
> in 1998.

They are using EUC-GB encoding, which is now being upgraded to GBK
to incorporate all the China-local characters in Unicode.

> I could go on but my point is that a half-way solution is not acceptable.

You accept Unicode because it reach not even the half-way.

Quite convincing.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Jul 99 12:42:30 JST

James;

> Unicode may not be widely used as the client, in Asia or otherwise,

It is not, world wide.

> of different languages.

???

Do you mean merging, say, English and Spanish as can be seen some
area in US?

Anyway, for the treatment of different scripts, we merely need and do
actually use some differentiation mechanism such as ISO 2022
(ISO-2022-JP, ISO-2022-KR, ISO-2022-CN, ...), EUC or family
of Shift JIS (Shift JIS, Big5, GBK, ...).

> But apparently, your disagreement is that we 
> should not even attempt to unify these domain names,

Domain names are already unified. You can't bother any further.

> and much worst, to 
> even use Unicode in the first place.

> many countries around Asia-Pacific.

> It is unfortunate as I believe you would

> Actually, ISCII is insufficient.

So is Unicode.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Jul 99 14:41:48 JST

James;

> with iDNS which we strongly believe we have to handle.

We only need some encoding. "Unification", whatever its meaning is,
is no requirement.

> Apparently, your suggestion is we shouldn't do any unification.

Not necessarily.

It can be answered if you can give proper definition of "unification".

> Now,
> have to repeat it for EUC-JP, JIS, ISO-2022-JP, UTF-8 and so on.

Huh????

I keep saying its ccTLD based localization.

Encoding is a minor local issue.

Major local issue is what characters are allowed for the local
encoding.

> Having decided we need to do code unification, we proceed to find an

With your lack of definition on "unification" and wrong definition of
"internatinalization", "we" haven't decided such a thing.

> next BoF and we vote against it.

Such a BoF is a waste of precious ITEF (not mine because I would not
be there) meeting time that I really hope it never held.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Jul 99 11:35:50 JST

James;

> I understand the localization issues and internationalized issues of
> DNS.

There is no internationalization issues of already internationalized
DNS.

> Therefore, it is not possible for iDNS to do i18n if we ignore all
> these i10n issues.

Because the ASCII DNS is the iDNS, your argument does not make sense.

> On the display/input side (client), we presume the users will continue
> to use their localized encodings. However, these localized encodings
> will be converted to Unicode and then to UTF-5 before it is resolved.

Doing so is, in theory, not impossible if Unicode could be strictly
profiled in some local context, which means the profiled
result, by no means, is not international and if Unicode had
contained all the local characters.

However, the reality is that people continue to use their existing
local encoding with some extension.

Worse, many local characters, such as CNS 11643 ones, are not
contained in Unicode.

In the local context, existing encoding performs a lot better
than Unicode. In the international context, Unicode does not
work.

> I know there is a general fear of Unicode because of Unicode v1.0 has a
> problem when it comes to encoding Japanese characters but I believe most
> of these problem are already fixed in the current v2.1.

The reality is that Unicode is ignored, not feared, because it
is not useful in the international context.

> But to play it safe, I presume the users will be more used to having their
> own localized encodings as their front end, and iDNS should not force them
> to use UTF-5, UTF-8 or any specific encoding.

That's not enough.

Any encoding must strictly profile according to local context,
which means use of Unicode must be discouraged.

Even just including all the ISO-8859-1 graphic characters destroys
DNS, because of soft hyphen, non breaking space and 'y' with
diaeresis (but no 'Y' with diaeresis exists) characters in it,

So, the proper way is to recommend existing local encoding with
limited number of characters optionally with further restriction
on character repartries.

> Yes, I agree Unicode was terrible when dealing with some Asian languages. 

Thank you.

> However, Unicode is probably the only unified character set we have
> at the moment.

We don't need "unified (whatever unified means)" character set
to make DNS localized.

> But I think Maruyama-sensei from JPNIC did suggested 
> to consider MULE encoding at the APRICOT meeting. This is probably one
> of the stuff we need to work out in the BoF.

That's red herring.

MULE is for internatinalization.

> I suggest you take a look at some the previous papers we have published on
> this topic at http://www.idns.org/technical.html. These papers may be a bit
> out-dated in the implementation (no, we dont use proxy anymore) but
> concepturaly, it is the same.

Thank you.

I recommend you read my book "Ima Nihongo ga Abunai" published
by Maruyama Gakugei Tosho, instead.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Jul 99 7:58:05 JST

Kre;

You have got the most important point.

> working, doesn't it?

It unnecessarily relies on ".i", because "localization" is wrongly
called "internationalization".

> It would mean that to allow anyone to
> that COM.AU.i

In ccTLDs like AU with small number of second level domains,
UTF-5 (or something better, because Unicode has a lot of unsolvable
problems. Anyway, encoding method is a local issue) encoded domain
under AU is enough.

Your program can automatically distinguish

	or.au.

and

	alkjlfjs.au

CA, for example, may need

	L.CA

under which localized (French?) domain names can be stored.

Anyway, they are all local issues.

Localized programs take care of local issues.

> message containing your UTF-5 domain name, and if that were to be a 

You are still confusing I18N and L10N a little.

My software will display some domain names with local characters,
Kanji, which you can not read not even remotely.

You may upgrade your software display some domain names with your
local characters.

But, you can not use my software with my locale. Kanji characters
must not be displayed to you.

> lock the world into what currently seems like the only implementable

Encoding is easy.

The question is when to display local characters.

							Masataka Ohta

---

From: James Seng <[email-masked]>
Date: Thu, 29 Jul 1999 08:14:24 -0700

Hi Ohta-san,

I understand the localization issues and internationalized issues of
DNS. Unicode is unfortunately not widely used in Asian countries. For 
example, Japanese are encoded using either JIS (which convers JIS-201, 
JIS-208, JIS-212), Shift-JIS, EUC-JP or ISO-2022-JP. Chinese are encoded 
in GB or BIG5, and to some extend, ISO-2022-CN and there is a push for 
GBK currently. And lets not get into Tamil with 100+ encodings, altho
there is a current Tamil standard which is supported by the Tamil Nadu
government. 

Therefore, it is not possible for iDNS to do i18n if we ignore all
these i10n issues. (Ah yes, this is another issue with both Kwan's
and Martin's draft didnt address).

On the display/input side (client), we presume the users will continue
to use their localized encodings. However, these localized encodings
will be converted to Unicode and then to UTF-5 before it is resolved.
This is just a simple view of the whole process.

What this means is
1. The users continue to use their current software without modification.
2. Unicode & UTF-5 is only an "internal" representation of the domain.
3. Unicode are *NOT* use for character display/font rendering.

at the moment. But I think Maruyama-sensei from JPNIC did suggested 

-James Seng

---

From: James Seng <[email-masked]>
Date: Thu, 29 Jul 1999 13:23:26 -0700

Robert Elz wrote:
> No, it shouldn't (nor should UTF-8, though I can imagine that not all
> implementations have been very careful there).   UTF-5 does impose even
> worse length restrictions on names though (and if I remember correctly,
> those most affect languages like Arabic and Sanskrit worst - the latter
> might be one of the ones where a length restriction would be a bigger > problem).

Dunno about Sanskrit but Arabic is fine. But as far as UTF-5 applied on
Unicode (16bits), each character is encoded less than 4bytes. With a limit
of 63 byte per label, this means we may only be allowed with 15 glyphs
per label. On the other hand, using UTF-8 improved it slightly since
you get at most 3bytes, and thus, you get 21 glyphs. This is one of the
pros of UTF-8, ie 25% better than UTF-5.
 
> Sure, but you missed my point.   I was attempting to ask why those two
> need to be linked?    That is, assuming that UTF-5 is an adequate solution
> for e-mail for the short term anyway, why does that imply that UTF-5
> also needs to be used for the DNS?

One goes with another. I wont mind going along with UTF-8 in DNS as I
already mention so long there is sufficient reasons for me to believe
UTF-8 can be easily adapted to Email Address (Email address are used in
many other protocols with certain presumation btw). What I like to avoid
is a case whereby we realised we cannot do i18n Email without a major 
change in codes already in place which will set-back us a few years in
this effort. In a worst case, we end up with a silly way to encode the
Email name and leave the domain name in UTF-8 *horror*.

> I am not sure I believe the latter.   Attempt to send a message using a
> UTF-5 domain name as your address right now.   See how many people
> actually receive it, and how many bounce it because their e-mail systems
> consider the domain name to be invalid.   Even better work out how many
> are able to reply to you using that address.
> 
> Your "implements immediately", I believe, assumes the deployment of the ".i"
> domain, which is something I don't think is very likely to ever happen.

Think more flexibly. ".i" is an ideal case and for our testing purposes,
there is no need to have ".i". Instead, our current testbed works by
appending ".idns.org" instead.

The reason why Martin proposed ".i" is not just as a marker, but it is also
a way to make these domain names visible to the rest of the DNS name space.

> I am really not sure that you want to go there.   The country TLDs we
> have now have the VERY big advantage that we have absolutely no arguments
> about what they ought be (someone else might, but we don't).  That is,
> not who qualifies for a TLD, and not what that TLD actually will be if one
> is allocated.   As soon as you start opening the door to country TLDs which
> aren't already set in concrete there are an enormous number of issues to
> deal with, and ones which I would just as soon prefer that no-one related
> to the Internet ever have to deal with.

Alas, but this is an issues we have to deal, whether you like it or not.
As enginners, I prefer to leave this argument to someone else. Stuff like
who get .SG (in Chinese) and .SG (in Japanese). There is a separated WG
in APNG which is supposed to work these things out.

> This doesn't even mean, fortunately, that people in non ascii countries
> need necessarily to ever see the ".jp" (etc) on addresses.   If you're
> presuming that they have e-mail software that can deal with Kanji (or
> whatever is needed) and translate that to & from UTF-5 for e-mail headers
> and wherever else needed, surely that software could also recognise ".jp"
> at the end of a domain name, and display that in Kanji as well (and make
> the reverse translation on addresses that are input).

No doubt. I think it can work that way too. :)
 
> Even if ".i" were the solution that was adopted, I would very strongly
> recommend against any attempt to allow non ISO-3166 country codes to be
> implemented in it.

Then dont! I do not see ".i" as critical to the implementation of iDNS,
but just as a mean of multiligual domain marker and a way to make these
domain visable to the rest of the world. Call it another name, or use
another existing TLD or ccTLD or whatever, you prefer. In fact, dont use 
any TLD! Just leave it as it is in the root zone. The fact is this is an
non-issue from a technical point.

FYI, i am using ".idns.org".

>   | There is no conflict as you mention here. You are imaging things :)
> 
> I don't think so.

I got it *working*. You can verify it at http://www.idns.org/
And so have many others.
 
> Yes.   But what gives you the impression that we don't need
> multilingual domain names in Australia?   There are many Chinese
> living there (as well as people of just about every other culture
> you can imagine).   Is there some reason that Chinese in Australia
> should be denied a domain name that Chinese in Singapore, Taiwan,
> or China are permitted?   Assuming there isn't, surely that means
> that .AU.i, .COM.AU.i (etc) are required?

Did I say Australian dont need Multilingual Domain Names? FYI, I have 
spend my last 3 years in Australia and my family is still there so I can
say I know the situation there pretty well. Australia have one of the 
most culturely diversified society i know other than America. But this is 
out of context.

> needs to use the same scheme.   DNS names are already not in the same format
> as e-mail names (dots, for example, are almost never seen in a DNS packet).

True enough. But I wish to avoid this if possible. 

Imaging you entering an email to Martin Duerst using his multilingal email
address. the Domain part of his email should be in UTF-8 and the Duerst part 
of his email is in..erm..some other encoding. Great!

> to UTF-5 as the DNS protocol.  The DNS isn't limited to ascii, so doesn't

Yes, you are right. DNS isnt. But are you sure all resolvers out there and 
all DNS servers (erm, let me bite this since BIND runs 99% and it is fine) 
will  happily take 8bits characters now? Remember that there *is* a common
use restriction on what character can be use in domain names.

> But in any case, please don't assume that anyone is attempting to prevent
> you from doing anything that you see a need to do - that would be folly.
> The question is not what should be done, but how that should be done.

Of course! Or else I wont even be having this email with you. :)
No offence, but you have your idea on how it should be done and so
we do. Ultimately, what is important is "which one will work?".

> Really, it is the other protocols where most of the issues arise - with
> just a few problems to be ironed out, the DNS already allows international
> names.   What it seems like is as if you're planning on mangling the DNS's
> capacity to do that, in order to make it easier to convert other protocols.
> That I don't believe is the right solution.

I couldnt agreed more. Please read my previous email. I did say a long
term aim for iDNS should be UTF-8. But then again, I think Terry Lambert 
didnt think that should the case...Ah, the beauty of the "No, you cant", 
"Yes, I can" "No, you cant!" "Yes, I can!!!".
 
> I would encourage you to send in a draft as early as you possibly can.
> Even if it is full of "this section is still to be written".   Drafts are
> pretty cheap, and they're not intended to be finished documents.  You could
> update it weekly if you keep getting more written every week.   But getting
> whatever part is already written out for public comment early means that
> you get feedback earlier, and the chance to incorporate that into later
> versions of the draft, even before all of it is written.

I will do my best and finish it as soon as I can. It is a long draft tho
which address a lot of issues. I have spend the whole day here writing
email explaining to the Unicode people why the *heck* i am proposing 
yet-another-UTF.

> I have done that (just now).

Thank you. Your contribution will be appreciated :)

-James Seng

---

From: Robert Elz <[email-masked]>
Date: Thu, 29 Jul 1999 09:37:43 +0700

Date:        Wed, 28 Jul 1999 18:29:19 -0700
    From:        James Seng <[email-masked]>
    Message-ID:  <[email-masked]>

  | UTF-5 is a new proposal, which of course means no vendors is going to
  | support it at the moment. However, it has a elegance in that the final
  | Unicode strings is within a limited A-V,0-9 character set which means
  | it should not break any existing DNS client/server.

might be one of the ones where a length restriction would be a bigger problem).

  | While it is possible
  | to have a domain name in UTF-8 working perfectly, it is not possible
  | to have an email address totally in UTF-8 without a overhaul in SMTP
  | protocol and all the clients and servers.

  | Ultimately, it is my believe that an DNS system should be designed
  | properly based on UTF-8. But in the meantime, our effort to push for
  | UTF-5 is a case of theortical vs practical issues. (Theortically UTF-8
  | is better. In practice, UTF-5 works and implements immediately)

  | Having an new ".i" TLD has its advantage. While, France in French may end
  | up using .fr and Germany in German may still be .de, Taiwan in Chinese is
  | not likely to use .tw nor Japan in Japanese going to use .jp. Of course,
  | unless you define your i18n to mean only European languages.

I don't think so.

  | If a domain name is strictly US-ASCII, then i do not see why you should
  | put it under .i hierarchy.

No, I understand that.

  | You only use the alternative hierarchy if it is a multilingual domain name.

  | So does that means while I can have a Chinese domain name, I couldnt
  | use my Chinese name as my Email name? I think you have miss the point
  | of the issues of our current effort.

No, I think you missed my point.   I was suggesting that whatever method is
used for handling multi-lingual e-mail names (and for now assume that
UTF-5 is the way that is to be done), there is no reason that the DNS
needs to use the same scheme.   DNS names are already not in the same format
as e-mail names (dots, for example, are almost never seen in a DNS packet).
There is already a translation.   Now if one could assume that the .i
scheme would work, then I can see the advantage in not requiring any special
translation between e-mail addresses and DNS names (then current e-mail
software, unchanged, could probably work, with multi-lingual addresses).
But I really don't believe that is a possibility.  If there is no ".i"
(in the DNS anyway, regardless of what might appear in an e-mail header)
and some other scheme is to be used, then I'm afraid I don't see any advantage
to UTF-5 as the DNS protocol.  The DNS isn't limited to ascii, so doesn't
require that encoding.   I do see some advantages to using UTF-8 right from
the start however, it means that the length restrictions on the worst
affected languages are not quite so bad (still not good, but not as bad
as with UTF-5), and it also means that there is never any need to plan
any kind of transition from UTF-5 in the near term to UTF-8 in the longer
term, which is another thing I doubt would ever happen (ie: the logistical
problem of ever converting away from UTF-5 if it is introduced would be
so great that it would never happen).

  | We either have i18n of DNS or we dont. And if we do, we should at least
  | make sure the other relating protocols can be i18n with the domain names.

  | I have already submitted the draft to [email-masked].

Yes, I saw its announcement.   I will fetch a copy about the same time as
this mail leaves my laptop...

  | But I
  | think you will be disappointed to know that the purpose of the draft is
  | to define UTF-5, and not to address iDNS issue.

Ah, OK.

  | As I mention above, iDNS
  | issues are issues need to be address irregardless whether we use UTF-5 or
  | UTF-8. And that is the draft I still writing and I hope to get it done
  | before the next IETF meeting.

  | Lets start with something you know. Case problem. DÜRST or Dürst?
  | I think this was mention in Kwan's draft and the solution is to convert
  | it to lower case. :)

Yes, though I am not sure why the smily is there.   The way names are
represented in the DNS shouldn't normally bother anyone very much - it
need not affect the way they're presented (not even the way they're written
in things like PTR records really).

  | Now, lets consider language outside European. For example, Chinese have
  | Traditional and Simplified character which have different code point in
  | Unicode, and of course different glyph but they mean the same thing. For
  | example, Taiwan in Chinese can be either (in Unicode) U+53F0 U+6063 or
  | U+81FA U+6063. Both means Taiwan and both are valid.

I assume this is a problem for more than the DNS?   What is the solution
(if there is one) in other areas?   But, probably don't answer that here,
that's probably something better put in your draft.

For the DNS I assume the only real question here is whether or not anyone
would ever request the DNS to treat such variations as being equivalent?
If not, and that has to be handled elsewhere, then this seems like a non-issue
for the DNS.    If so, then I can see something of a difficulty there...

  | And you can move on to a other languages and you will find other problem
  | and they are very different. e.g Tamil have their "upper" and "lower" case
  | glyph and unfortunately in Unicode, these "upper" and "lower" case glyph
  | can only been obtained via kerneling (as Tamil was not given enough code
  | space).

While this one certainly sounds like a problem in general - it sounds like
a solution for the DNS.   The DNS isn't in any way concerned with presentation
of anything.   The aim here is (was) to have things which mean essentially the
same be treated the same.   Having no code point case distinction seems like
it should make that pretty easy to handle...

  | If you are interested,
  | I strongly suggest you subscribe to our APNG iDNS Working Group. Send an
  | email to [email-masked] with "subscribe" to join the mailing list.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 29 Jul 1999 09:37:43 +0700

| While it is possible

I don't think so.

No, I understand that.

  | But I

Ah, OK.

  | If you are interested,

kre

---

From: Terry Lambert <[email-masked]>
Date: Thu, 29 Jul 1999 11:35:18 -0700

I didn't realize this would be going on on both this list
and the iDNS list...

> This is just a simple view of the whole process.

This whole issue is, IMO, being blown way out of proportion.

I don't see any problem whatsoever with RFC 2047 encoding
domain name components, and teaching the resolvers on the
machines which are going to allow such delegations (e.g.
"sg" or "jp") to read them.

So you might get a machine name that is:

	=?iso-2022-jp?B?GyRCOzNDZkwvO1IbKEI=?=.co.jp

Not only that, we are guaranteed that the MUA's (at least
those getting their mail off this machine) will "do the right
thing" when displaying the components.

The only issue I see is one of case-folding.  This can be
overcome by using "Q" (quoted-printable) instead of "B"
(base 64) encoding, and forcing the encoding of uppercase
ASCII and other characters in the resolver code.  Decoding
would still result in the correct rendering for the user.

If we were to allow "=" and "?" in domain names *today*,
and reserve "=?" as an introducer, then I could register
this particular machine *today* (using quoted-printable),
and everything would "just work".

-- Terry Lambert
-- Whistle Communications, Inc.
-- [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: Robert Elz <[email-masked]>
Date: Thu, 29 Jul 1999 23:07:34 +1000

Date:        Thu, 29 Jul 1999 13:23:26 -0700
    From:        James Seng <[email-masked]>
    Message-ID:  <[email-masked]>

  | In a worst case, we end up with a silly way to encode the
  | Email name and leave the domain name in UTF-8 *horror*.

I;m afraid I can't see the horror there at all.   We already have exactly
that, right now, and always have (since the DNS appeared).

But to be sure there's no misunderstanding here, I am not talking about
the local and domain name parts of an e-mail address, what I'm talking
about is how the domain name part is encoded when it is transmitted in the
DNS packet to obtain the MX record (etc).   There's already a conversion
when the domain name from the e-mail address is extracted and sent to the
DNS - a fairly simplistic conversion, true, but certainly a conversion.
Altering that (in appropriate circumstances) to be a different conversion
doesn't seem too difficult to me.

  | Think more flexibly. ".i" is an ideal case and for our testing purposes,
  | there is no need to have ".i". Instead, our current testbed works by
  | appending ".idns.org" instead.

This is irrelevant.   It isn't the characters that compose the suffix that
is the problem, it is the existence of the suffix, any suffix, in the
first place.

  | Alas, but this is an issues we have to deal, whether you like it or not.

Why?   I'm afraid I see no point in opening this can of worms?

  | > surely that software could also recognise ".jp"
  | > at the end of a domain name, and display that in Kanji
  | No doubt. I think it can work that way too. :)

Then why do you want new ("international") top level domains?

  | Then dont! I do not see ".i" as critical to the implementation of iDNS,
  | but just as a mean of multiligual domain marker and a way to make these
  | domain visable to the rest of the world.

Yes, but if UTF-8 were to be used instead, the very existence of more than
ascii in the domain name would serve as the marker, it would be automatic,
and implied, and would simply slot into the DNS tree that we have now.

  | Call it another name,

No, it isn't the name that is the problem, it is its existence.

  | I got it *working*. You can verify it at http://www.idns.org/
  | And so have many others.

I don't doubt but that it is possible to write code to do what you're
proposing.   What I doubt is that it can scale to cover the globe,
and the entire DNS.   As a testbed, I can certainly see it working fine.
I just can't see how it can really function when there are some of these
non-ascii domain names in essentially every domain in the world (even if
you're in a toally ascii country, with English only local users, you might
want to create URLs to your web pages in all kinds of languages, so as
to attract customers from all around the world...)

  | Did I say Australian dont need Multilingual Domain Names?

You implied it.   I said that I didn't see a parallel AU.i tree as a
workable solution), you sad that where multilingual names aren't needed
there's no need to implement any of this...

  | Imaging you entering an email to Martin Duerst using his multilingal email
  | address. the Domain part of his email should be in UTF-8 and the Duerst
  | part of his email is in..erm..some other encoding. Great!

No no, that is never what I meant.   His email address (and apologies
for laziness, but I'm on a plane, and my battery doesn't have long left to
live, so I am going to invent the UTF-5 encoding, rather than calculate it)
could be something like [email-masked] -- when the e-mail software
does its MX lookup on W23M45.de the resolver converts the W23M35 UTF-5
string into the equivalent UTF-8, and does the DNS lookup using that.

  | No offence, but you have your idea on how it should be done and so
  | we do. Ultimately, what is important is "which one will work?".

yes, where "work" includes scaling in a form that the DNS operators of
the world can cope with.

  | I couldnt agreed more. Please read my previous email. I did say a long
  | term aim for iDNS should be UTF-8.

yes, I know.   If you were of the opinion that it ought not be I might be
arguing less.   Not because I believe the contrary, but because I don't
really believe there could ever be a transition.   If a UTF-5 encoding
caught on, and became in widespread use, inertia would keep us with that
forever.  If UTF-8 should be the long term aim, it must be the short erm
aim as well.

  | I will do my best and finish it as soon as I can.

Please do - but don't wait for that.   Publish the draft as soon as
it has even some part more or less complete, don't wait for all of it
to be done.   That is, once you have written something on just one of
the issues, publish the draft - then add something on another one, and
send in an update including that, etc.

  | I have spend the whole day here writing
  | email explaining to the Unicode people why the *heck* i am proposing 
  | yet-another-UTF.

Which, of course, if it were in an (even incomplete) draft, you could
do by just supplying a pointer...

kre

---

From: James Seng <[email-masked]>
Date: Fri, 30 Jul 1999 04:36:06 -0700

> that, right now, and always have (since the DNS appeared).

But I can. And I hope to avoid it if possible. And IMHO, UTF-5 will avoid 
it. Nevertheless, I am not stubborn to stand by UTF-5. If the next BoF 
decided to go ahead with UTF-8, then I will go for UTF-8. I will not let 
my personal belief to stand in the way of I18N DNS. But until then, I will 
continue to stand up to my case on UTF-5.

> is the problem, it is the existence of the suffix, any suffix, in the

Then dont have any suffix! It doesnt matter to me. The point is TAIWAN
in Chinese is not going to have a country code .tw. To me, it is like having
two Greek alphabet appeared at the end of my name.

For example, people acknowledge me as Mr. Seng. That is fine with me.
In Chinese, people will acknowledge me as ²ø¥ý¥Í. That is correct too.
But no one will acknowledge me as Mr. ²ø. It just don't make sense.

> Then why do you want new ("international") top level domains?

And why should I stick myself with an English TLD? 
 
> and implied, and would simply slot into the DNS tree that we have now.

Ok, I think I have repeated this before...

The advantage of UTF-8 as we all know is the compatiblity with US-ASCII.
So if you have a multilingual name say francetélécom.fr, encoded in
UTF-8, you will still end up with a TLD .fr. What this means you do not
need to create any new TLD. And this *is* an advantage which I cannot
deny nor do i attempt to.

But supposing we want to have a domain ¶®ªê.¤½¥q (yahoo.com), encoding it 
in either UTF-8 is not going to give us .COM. And a half solution of ¶®ªê.COM
is not acceptable by any one who feels strongly about their own language.
Imaging the reverse case. Supposing I tell you you can have the name Yahoo,
only if you use the .COM TLD in chinese, ie Yahoo.¤½¥q. Is this acceptable 
to you?

In other words, I18N of DNS will end up having the need to create 
new TLDs whether you use UTF-8 *or* UTF-5. This is as far as I can 
see a political issues that ICANN is going to deal with.
 
> there's no need to implement any of this...

You misunderstood me. What I mean is you should place all normal US-ASCII
domain names under .AU as per norm. And when you do have an multiligual
domain name, say in French, then you place it under ".i". You do not need to
duplicate any English domain names under ".i" as you describe. 

".i" is used symbolically. I dont really care what you call it, or if even
really exist.
 
> string into the equivalent UTF-8, and does the DNS lookup using that.

And the reverse is true too, ie you give me a UTF-8 domain name, and 
I convert it to UTF-5 and do the look up using UTF-5. And this is what
I have done now.

> yes, where "work" includes scaling in a form that the DNS operators of

Hmm...I did not propose any basic change in DNS, only a way to encode 
multilingual characters into DNS name space. I do not see how it will 
affect scaling or destroy the hierarchy of the DNS. Can you please 
explain this?
 
> forever.  If UTF-8 should be the long term aim, it must be the short erm

haha. if that is my purpose, I cerainly didnt managed to shut you up :))

> send in an update including that, etc.

Sorry, I do not like to do half-done job.

For UTF draft, we already expected to get attack from Unicode Consortium.
And as far as the UTF-5 draft is concern, it covers the UTF-5 technical 
details quite clearly so I believe it is complete. No one has attack it 
saying it is not feasible or technically faulted. The only argument is 
the justification for another UTF.

-James Seng

---

From: Robert Elz <[email-masked]>
Date: Thu, 29 Jul 1999 22:41:52 +1000

Date:        Thu, 29 Jul 99 7:58:05 JST
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

Otha-san

  | Your program can automatically distinguish
  | 	or.au.
  | and
  | 	alkjlfjs.au

You mean we should build software that knows what the domain name space
in AU (or any other country) looks like?   And then presume that it won't
alter?   No hope of that - absolutely none.   Software that works here
almost all comes from someplace else, and no way is the AU name space
(looking into the future) stable enough to start building in assumptions
about it into software.

  | My software will display some domain names with local characters,
  | Kanji, which you can not read not even remotely.

Why can't I read them?   If you just mean because I'm an ignorant savage
with no comprehension of Japanese, then I'll accept that (and no, I'm not
accusing you of insulting anyone, I'm doing that to myself).   But had I
the capacity to learn, why cannot I then see your domain names in Kanji?

Eg; My niece is learning Japanese in school (ok, she's just 7, and hasn't
got very far yet...)   Assuming she continues though, and becomes as
proficient as you are with English, why should she not see and understand
Kanji domain names just as well as you do ascii ones?

  | You may upgrade your software display some domain names with your
  | local characters.

What local characters?   There is no such thing here.   What there are
are a vast number of different cultural groups, all of whom would like
to see names in their local languages - and we're likely to have quite
a few of those, all living in the same parent domain.   What I read into
what you are suggesting is that nothing can be done to handle this problem.

  | But, you can not use my software with my locale. Kanji characters
  | must not be displayed to you.

I will assume here that you're saying this because they would be
meaningless to me, I couldn't even copy them correctly.   That's fine.
But would your argument not be just the same if you were Thai and using
Thai characters instead.   I see no reason why those can't be displayed
to me - I can recognise them, copy them, type them (when I setup my system
properly), and even make a badly mangled attempt at pronouncing them, even
though I don't have much idea what most of the results mean (and the way I
pronounce them, nor does anyone else...)   But are you really saying that
I am not to be permitted to see them?   Why?  How do you decide who is
permitted and who is not.   Does your argument extend to the Latin
languages as well, is no-one outside Scandanavia ever to be permitted to
see a name with æ in it?

  | Encoding is easy.
  | The question is when to display local characters.

I would have thought that is easy too - if I have an environment (existing
and enabled) with the necessary support, then display them, otherwise don't.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 30 Jul 99 8:44:39 JST

Kre;

> might be one of the ones where a length restriction would be a bigger pro=
> blem).

That's one of a reason among many on why local encoding, not Unicode
in UTF-8 or any form, is used.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 30 Jul 99 8:30:52 JST

Kre;

> alter? No hope of that - absolutely none.

Let NIC of AU judge it.

An alternative among many is to have L.AU.

> Software that works here

It's an issue of local configuration.

> accusing you of insulting anyone, I'm doing that to myself).

OK. But, you don't have to insult yourself, because no one can
comprehend all the characters in the world, which is often forgotten
in arguments of some Unicode lovers.

> But had I

Note the tense of my statement.  Have you learned it already and
read it at present?

As you said:

	> Software that works here
	> almost all comes from someplace else,

and certain software used in Japan (and Thai) also comes from someplace
else, if you or your niece learns to read new script, you can modify
localization configuration of such software.

> What local characters?

Characters local to you.

> There is no such thing here.

You, later, said you can use Thai.

> What there are
> what you are suggesting is that nothing can be done to handle this proble=
> m.

Thus, the only internationalized DNS is ASCII DNS today.

However, locally within some cultural group, members of the group
may use any convention for there MUA.

Commercial software can be locally configured to use some encoding
under some domain (AU, L.AU, JP or KRE.ORG).

That's why so called "iDNS" can only be localized DNS.

> to me

I can't see, either.

> But are you really saying that
> I am not to be permitted to see them?

How? Can someone forbid you configure your software at your own will?

ccTLDs, of course, can put some restriction on assigned names under
their domain. But, they can not permit or forbid you see anything you
want. They can't effectively control names deep inside TLDs, either.

> How do you decide who is
> permitted and who is not.

Why do you think permission is necessary or meaningful?

> I would have thought that is easy too - if I have an environment (existin=
> g
> and enabled) with the necessary support, then display them, otherwise don=
> 't.

Are you aware that "them" is different locale by locale?

If so, you are agreeing with me that the issue is localization, not
internationalization.

Note that some people simply think all the international characters
can be displayed to everyone.

Note also that a lot of characters have identical shapes (such
as 'A' as Latin, Cylliric and Greek capital letter) or similar
shapes that localization must be carefully designed to exclude
the possibility of choosing wrong characters (case independence,
in a sense, is useful for the purpose with alphabetical characters).

							Masataka Ohta

---

From: Terry Lambert <[email-masked]>
Date: Thu, 29 Jul 1999 11:49:37 -0700

Ugh.  I hate list cross-posts...

> increase the complexity of maintaining the zone files, delegation etc.

No.  One soloution would be to pick one encoding for delegation
within a sub hierarchy, and you force everyone to use it or
they can't play in the subhierarchy.

I agree that Unicode looks like it would be the best choice,
if we want to avoid balkanization of the namespace, but there
is every risk of balkanization using any internationalization
scheme whatsoever.  One need only consider how a Windows 98
client in th US, without Japanese support, is supposed to be
able to contact a Japanese language web server.  Or send mail
to a user on such a machine.  It means that software won't
have to deal with all possible character sets when it goes to
render.  If it makes anyone feel better, then they can round
trip the characters out of Unicode and into ISO-2022-JP or
Shift_JIS to avoid "polluting" their machines.

But much as I would love to argue Unicode with Ohta-san, there
is no need to invent a new encoding, or to make changes anywhere
but in the resolver canonization code.

There are places where a UTF-5 encoding would have utility
(closed captioning systems and teletypes spring immediately
to mind), but I don't think DNS is one of them.

-- Terry Lambert