Subject: [idn] How to match letters

From: Dan <[email-masked]>
Date: Sun, 24 Jun 2001 11:24:41 +0200 (MEST)

We have now and then discussed what letters are to be matched as
equals. In the nameprep document some work is done and there is
no other draft available. I could write one for the Latin based
alphabets (this includes Greek and Russian), if that is wanted.
(I cannot write how to do matching for other parts as I have
no language knowledge about them).

There are two important things I have come across related to
matching names (I have worked a lot with LDAP/X.500 directories):

1) matching based on equivalent glyphs
2) matching based on equivalent sounds

An example of 1) is that in UCS, Latin upper case A, Greek upper case Alpha
and Cyrillic upper case A have the same glyph.
Using my Swedish keyboard I could enter names in Greek or Cyrillic, but
I do not have three equivalent looking "A"s on my keyboard. Instead I
would use the same A for all names.
From this I think name matching must treat all equivalent looking
letters as the same - this also resulting in lower/upper case versions
of those letters treated as the same even if their glyph does not match.
Does anybody have any problems with this? Or is there some other way
to do it?

An example of 2) is Swedish "ö" (o with diearesis) and Danish
"ø" (or with stroke). They both represent the same vowal and somebody
in Denmark would often enter a Swedish name using the Danish version of
the letter, and the other way round from Sweden.
So the letters "ö" and "ø" should match as the same.
How many more of this kind is there? Any problems doing this kind
of matching?

   Dan

---

From: [email-masked]
Date: Wed, 27 Jun 2001 19:24:13 -0700

Dear Eric:
	I do not want to say [BCPxxx], I used the "best current 
practice" in its generic way.  If this is offending you, I feel 
my expression has accomplished more then what I hoped. 
 
	And thank you for assure me that 

>encoding schemes which are onto a 63 element set (6-bit minus 
> one
> encoding, or generally, sub-8 encodings) have their proponents.
 
	If the compression rate can be improved with reasonable 
cost, then I am all for it. 

	I do think if the WG agree that  it is better to leave DUDE where 
it is and let some of the phonetic based issues to be resoved before 
[NamePrep], then it could state it as such, it is complementing the 
current WG proposal and makes it better.   Like an automobile licence
number, some people want to pay extra to get a statment on it. 
Is this going to effect future deployment of any new technology? 
I don't think so.  Only if you want completely abandon the 
communication functions of ASCII in DNS.  It may waste someone's
work which has started, but none of us is short of such an opportunity, 
except me, I guess.

Let me know if I have offended you again.

Liana

On Wed, 27 Jun 2001 17:39:59 -0400 Eric Brunner-Williams in Portland
Maine <[email-masked]> writes:
> Ms. Ye,
> 
> If you want to argue that a qwerty keyboard is an instance of 
> something,
> feel free. Personally I think it is an instance of "keyboard". To 
> use a
> term such as "BCP" in an IETF context takes a little bit more than 
> just
> assertion. Personally I don't think there is the slightest 
> connection.
> 
> Again, encoding schemes which are onto a 63 element set (6-bit minus 
> one
> encoding, or generally, sub-8 encodings) have their proponents, I'm 
> just
> not one. rfc768 specifies an 8-bit byte transport. rfc793 does as 
> well.
> 
> Eric
>