Subject: Re: [idn] How to match letters

From: [email-masked]
Date: Mon, 25 Jun 2001 11:10:51 -0700

Thank you for pointing me to the RFC I am looking for. 

As RFC 2825 [2] stated, it is a challenge to the technical community how
to
address the user issue from the bottom of the Domain Name system all 
the way up to any fancy display in the future when you can support IPv64 
using Frozen Light [Scientific American, July 2001] technology.  We have 
been avoided the issue by holding the domain naming system back for 
years, as you have stated:
> It isn't a working group attempting the problem stated in [3], or 
> even in
> the charter of _this_ working group.

and it is may blow up at any time in front of us like the labor problem
in China now.  

I believe there is such a technical solution, and thank you for your 
observision, that 
>The set of 63 values are used to form identifiers, unique within 
> delegated
> scope, for a specific classs of a classed lookup service. We could, 
> without
> loss of meaning, assign the familiar Mayan 20-count and lunar 
> identifiers,
> plus 30 Han characters to these values, as some 63 elements of the 
> 7-bit
> ASCII repitorire.
> 

and it is the challenge to stay within the a-z0-9 limit for the sake 
of users, not for the computer programmers.  That is the reason for
user interface limit to a physical English keyboard, a universally 
approved limit.  

Liana

On Mon, 25 Jun 2001 09:34:10 -0400 Eric Brunner-Williams in Portland
Maine <[email-masked]> writes:
> Ms. Ye,
> 
> > I suggest to encode alphabets to ASCII based on ...
> 
> In the narrowest of contexts, this list is attempting to to either 
> add a 64th
> and possibly other values to a set of 63 values, or map some 
> (larger) set of
> values onto a set of 63 values. Alphabets, glyphs, sounds, scripts, 
> languages,
> even characters and encodings [0] are ephemera.
> 
> This corresponds to the set of arch-1, arch-2, and arch-3 choices in 
> Paul
> Hoffman's comparison I-D [1].
> 
> In a larger context, this list is tasked with solving a problem 
> stated only in
> part [2] in Leslie Daigle's tangled web RFC [3].
> 
> The set of 63 values are used to form identifiers, unique within 
> delegated
> scope, for a specific classs of a classed lookup service. We could, 
> without
> loss of meaning, assign the familiar Mayan 20-count and lunar 
> identifiers,
> plus 30 Han characters to these values, as some 63 elements of the 
> 7-bit
> ASCII repitorire.
> 
> The sense of your proposal, mapping IPA and other exotica (which 
> might as
> well be varients of Klingon) into ASCII probably has a place, 
> somewhere.
> It isn't a working group attempting the problem stated in [3], or 
> even in
> the charter of _this_ working group.
> 
> Eric
> 
> [0] Encoding identifier management, e.g., universal (ASCII or 10646) 
> or local
>     (various) being the only non-ephemeral issue
> [1] draft-ietf-idn-compare-0?.txt
> [2] e.g., son-of-rfc1036 is not referenced
> [3] rfc2825

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 25 Jun 2001 14:13:03 -0400

> Thank you for pointing me to the RFC [2825] I am looking for. 

Sure.

> user interface limit to a physical English keyboard, a universally 

Umm. A typing element for the IBM Selectric typerwriters was developed
for the then-new syllabic system in 1976, for Inuktitut, and could be
used for any Cree (etc., modernly UCAS) text. That would be universally
approved Inuktitut.

Eric