Subject: Re: [idn] what are the IDN identifiers?

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 29 Nov 2001 14:35:47 +0800

> First, I have never used the term "multilingual",
> second, I have always speak about IDN identifiers.

Once you touch "dealing with language" topic, you are talking about
"multilingual domain names" and away from IDN identifiers.

-James Seng

---

From: liana Ye <[email-masked]>
Date: Wed, 28 Nov 2001 21:53:27 -0600

First, I have never used the term "multilingual", 
second, I have always speak about IDN identifiers.
These are the terms I have been very careful.  If 
I have given you the impression to argue for 
something more then these, then I think my 
message have not get cross yet.
 In one word, I am arguing for John's layer
two stuff to be dealt with in his layer one, is this 
multilingual?  I think this is the difference we have 
started from beginning, from allowing TC/SC in
[nameprep].  This is nothing to do with "multilingual".

Liana

On Thu, 29 Nov 2001 13:18:23 +0800 "James Seng/Personal"
<[email-masked]> writes:
> Additional notes:
> 
> This is nothing to do with "close minded". I am just not interested 
> to
> get muddy with the discussion, just like the murky topic of 
> definition
> of hostnames. But I be happy to watch by the side to see the 
> discussion
> to see if there is any conclusion.
> 
> language vs script does not implies anything about "tags". If you
> referring some solution you or someone else proposed, that certainly
> does not cross my mind.
> 
> I am just not interested to discuss "multilingual domain names". If 
> you
> *think* it is possible, please go on. Just dont involve me, 
> *please*.
> The only reason I am even writing this is because you address your 
> mail
> to me.
> 
> -James Seng
> 
> > Thank you, I like your conclusion very much, so you are close
> > minded about using tags, is that correct?
> >
> > Liana
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Nov 2001 06:42:41 -0500

--On Wednesday, 28 November, 2001 21:53 -0600 liana Ye
<[email-masked]> wrote:

>...

But, Liana, these sorts of things are precisely why there is a
layer 2, so I'm not sure I understand what you are suggesting.

To go through that once again:

(i) In the general case, we cannot handle TC-SC, or any other
language-sensitive, or context-sensitive, translations or
matchings in the DNS.  A number of special cases and/or subsets
can be made to work.  But special cases and subsets are very
confusing to users who expect the generalizations if anything
appears to work.   And, without a clear demonstration that there
is a solution for the [more] general case on the near horizon,
it would be irresponsible for the IETF to approve a "this
handles the easy case, we will deal with hard cases later" style
of solution -- that sort of approach is almost always bad
systems design, and demonstrably so here.

(ii) Language tagging in the DNS in some form would help a bit,
but doing such tagging has gotten, as far as I can tell, not
even a sign of consensus in the WG.  It is reasonable that it
has not, if only because nothing the WG has done or agreed to
would change the fundamental character-by-character nature of
the DNS or the assumption that the characters of a label can be
chosen from any valid character from the selected subset of the
relevant CCS, in any order (with the exception of the legacy
rules about hyphen-minus).

One way to look at the above is that the DNS just doesn't have
enough information available during matching.  The matching
algorithms don't have access to language information, country
information, or other things than could be used to sort out
similarities and variants.  And the DNS does exact matches -- no
ambiguities permitted.  If the needed information isn't there,
no matching tricks or "preparation" is going to help -- there is
no place in the DNS or either magic of "do what I mean"
capabilities either.

One can, again, get partially around those problems with
client-side code --nameprep is precisely such a partial solution
(or a potentially-complete solution to a narrower problem).  But
complex client-side solutions have a history of causing
interoperability problems and user confusion.  Client software
suppliers find it just too tempting to provide codes that are
"just a little better" than required by the standard.  In this
case, that means that user-supplied names will be interpreted
differently depending on which client software package is used,
and that is very bad news.  Worse, interoperability testing in
the usual IETF sense is impossible in these cases, since any
damage has been done before a single bit crosses the wire.

Search Layer 2 (and 3, actually) are responses to these specific
issues, not exercises in protocol design.  The documents didn't
appear two years ago because it was important to understand how
far a DNS-based solution could be extended.  I suggest that we
now know, and that the answer is "not into these language
problems, or context problems, or even script problems that
involve considering characters more than one at a time".

"DNS Search", or, now, "IRNSS", is also, so far, just a
framework.  We have proposals for sublayer 2 on the table, but
neither is complete and more proposals are welcome.  But that
framework explicitly provides for:

	* Language information
	
	* Country information
	
	* Matching functions that can consider complete name
	strings, not just individual characters and one label at
	a time.
	
	* Matching functions that can do parallel table lookups,
	apply spelling differentiators, and do other "fuzzy"
	things and do them as predictable, server-side
	operations.

Isn't that the set of tools you are looking for?

See following note on IRNSS.

    john