Subject: Re: [idn] Dots, and a path to working IDNs

From: [email-masked]
Date: Thu, 31 May 2001 23:40:40 -0700

On Fri, 1 Jun 2001 02:55:34 +0000 "Adam M. Costello"
<[email-masked]> writes:
> [email-masked] wrote:
> 
> > Allow me to comment on your UTF-8 as a long term solution.
> 
> If I understand correctly, you are proposing an alternative model 
> for
> representing characters.  Currently, characters are represented as
> indices into a table.  If a character is not in the table, it cannot 
> be
> represented.
> 
> You are proposing that instead of a table of characters, we have a
> table of character-building-blocks, and to represent characters as
> instructions for how to compose them from the building blocks.  This
> would allow new/obscure characters to be used without deploying new
> fonts everywhere.
> 
> (You also propose to represent the building blocks phonetically 
> using
> ASCII, but I think that's an orthogonal issue.)
> 
> Is my understanding roughly correct?
>

Yes.
 
> It's an interesting idea, but dramatically different from the 
> current
> text model.  I suspect that you'd have to change lots of things in 
> all
> applications and all operating systems to make this work.
> 

1. For people don't want to change anything of the current 
environment, leave current file format alone. Only when 
it needs to be sent over the wire as ASCII file, then 
convert it into StepCode format.  So you may attach it on a
e-mail and not be garbled on the other end (especially 
through one legacy system on its way).

2. For DNS registrar, it may provide a StepCode convertion
program of their own locale. I do not see anything else
 needed, unless someone wants to take the full advantage 
of StepCode.
.
> Regarding the use of English keyboards, I'm not sure what your point 
> is.
> The representation of text in a file or on a wire is unrelated to 
> how
> users type that text, right?
> 
> AMC
> 
Not quite, but good catch. It is depending on which operating 
model you are asuming.  But that is another subject.

Liana Ye

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Jun 2001 09:55:01 -0400

Liana,

Thanks for taking the time to explain what you are trying to do.
I hope I understand it now.  The comments below are based on my
current understanding -- if I have gotten it wrong, please try
to keep explaining.

--On Thursday, 31 May, 2001 23:40 -0700 [email-masked]
wrote:

>...
>> (You also propose to represent the building blocks
>> phonetically  using
>...
 
>> Regarding the use of English keyboards, I'm not sure what
>> your point  is.
>> The representation of text in a file or on a wire is
>> unrelated to  how

_If_ I correctly understand this, you will quickly run into the
problem that many languages contain words that are pronounced
the same way but spelled differently and words that are spelled
the same way but pronounced differently.  As long as the DNS is
essentially/historically text-based, overlaying a phonetic
system on it is a problem for those languages and words (i.e.,
the mappings are not unique).

Worse, it is not clear that one can establish a set of
conventions for representations of characters that work across
scripts.  From very young ages, people get used to variations on
ways to print or write characters in their own languages
(scripts) but not in others: some variations in characters
derived from the Roman alphabet that are considered "font
details" would be sufficient to cause "different character" in
other scripts.  Indeed, as has been suggested in other contexts,
the glyphs for "i" and "j" may represent the same character or
not depending on whether the particular language treats them as
distinct; a different language may have different rules using
the same script.

Similar problems presumably apply with phonetic representations.
The international phonetic alphabet (see the 164ff in the
Unicode 3.0 book) has changed, and presumably improved, since I
learned how to use it 40-odd years ago. But I recall its being
considered "good enough", rather than "exact", and that the
phonetic community does not believe that a better system exists
or that a significantly better one is possible across language
groups.

Switching from a script-and-text-based model to a character-form
or phonetic one consequently exchanges one set of problems for
another, rather than reducing, IMO, the total number of problems.

But I think the most serious problem, as Adam suggests, is just
compatibility between systems: a mix of the two is probably
worse than either by itself.

That said, one might think of either phonetic or character-shape
schemes as candidates for a "layer 3" search system as outlined
in my "DNS search" discussion (draft-klensin-dns-search-00.txt).
If one could use such systems as a means of input which would
then go through a software process of both searching (not
exact-match DNS lookups) databases for possible matches and,
where necessary, dialogue with the users, they might become very
strong candidates, especially where the users were not easily
able to put more direct representations of the characters in
from keyboards.

   john

---

From: "Sean X. Zhang" <[email-masked]>
Date: Fri, 1 Jun 2001 11:07:00 -0700 (PDT)

> > Is my understanding roughly correct?

This is indeed an interesting idea and has been discussed numerous times
in other forums. To "represent" characters as described above would have 
to introduce fundamental changes to all applications and all operating
systems utilizing the characters. That's what ISO-10646 and Unicode 
are about. I'd prefer to work within the constraint of existing encoding
mechanisms. I may be wrong, but I don't think this list is the most 
appropriate forum for introducing these changes. 

Sean X. Zhang

> > applications and all operating systems to make this work.

....

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Mon, 4 Jun 2001 12:38:30 -0400

|      I'd prefer to work within the constraint of existing encoding
| mechanisms. I may be wrong, but I don't think this list is the most 
| appropriate forum for introducing these changes. 

  I strongly agree here.  This sounds like another interesting idea to put 
into the discussion around jck's directory service proposals.  In the 
context of this WG this represents in my mind 'another ACE', and has
significant disadvantages when compared to the other proposed algorithms, 
with not any strong benefits over other proposals.

  -bws