[idn] [nameprep] architecture

[liana.ydisg@juno.com]

I had offered my suggestion, and it seems that
did not get cross due to poor e-mail handling.  
Let me try it again.

I am addressing the Unicode CJK section. Where
U   Unicode
cjk   CJK
A   ACE in transliterated StepCode
K  KSC
J  JIS  
G  GB
B Big5

h  Hangul
j  Japanese Kana
c  Chinese Pinyin

The [nameprep] data table headers in the following 
form:

U-cjk  U-sc  G-sc  B-tc  A-c   U-h  K  A-h   U-j  J  A-j

TC/SC is reflected in U-cjk  U-sc, compatible
with current case folding.

G-sc  B-tc are local code search key for three puposes:
1. to get Unicode for registration Unicode conflict check.
2. to get A-c for DNS id  for DNS matching.
3. for reverseg searching from  A-c to local display. 

When G-sc  B-tc is out of dated say in next 20 years, 
the columns can be deleted. The first two columns
are untouched. The same is for K and J.

U-cjk <-> U-h are treated as case folding as well as 
U-cjk <-> U-j   

A-c A-h A-j are three sets of transliteration code for
the same codepoint, where registration checking
needs it when doing keyboard searching. 

This is the table I have been talking about, and I
shall call it [nameprep].  With this table, [IDNA] takes
 in an IDN label and output  an  ACE label, 
or ACE label output IDN label, a universal IDN
interface. 
Within this [IDNA], a tag identification routine and
three tagged procedures per srcipt is required.  
1) Tagged conversion: search key -display code, 
	receive-ACE.
2) Tagged reversion: decompose a ACE id receive 
display IDN code. 
3) Tagged display: compose a display string from
IDN code.  

URL cut and Paste:
 loop for all labels:
	Get IDN label from URL buffer, 
	call [IDNA], receive ACE label, 
	replace IDN label with ACE label
  until end of URL, 
  send URL to DNS. 

Now I'd like to talk about keyword searching. Using
IDN registration as an example, [IDNR]: 
1) get wish-name, 
      call [IDNA] wishiname, receive ACE label. 
      send ACE to DNS search, bad go to 1).
      good go to 2)
2) call [IDNA] ACE, receive Unicode-name.
     send  Unicode-name to IDN search, 
     good, go to 3).
     bad, go to 1)
3)Register wish-name in Unicode-name with ACE.

Liana



On Sat, 1 Sep 2001 11:26:56 -0700 Paul Hoffman / IMC <phoffman@imc.org>
writes:
> At 1:41 AM +0800 9/2/01, tsenglm@????.??.tw wrote:
> >I  just enhansize the issuse can not be neglected.
> 
> It is not being neglected. It has been addressed repeatedly here. 
> Because there cannot be a universally-deployed technical solution in 
> 
> IDN, it must be deployed as rule that zone administrators know that 
> they should follow.
> 
> >   We all know the
> >registration of ML.com will renew around November,  so there are 
> time
> >schedule pressure ,  I  hope they can work in right way and produce 
> less
> >confusings in using TC/SC.
> 
> VeriSign GRS is a zone administrator like all other zone 
> administrators. If they mess up, the folks controlling them (in this 
> 
> case, ICANN) should tell them to fix the problem.
> 
> >   Actually , I should not to worry them if I
> >assume they have troubles in it, but it is not so fair to users. 
> For CJK
> >users , we need it work properly.
> 
> For *all* users, we need it to work properly. Please remember that 
> most people in the world will find interface problems with IDN, just 
> 
> the way they find them with the current DNS. (Said a different way, 
> we will probably manage to offend almost everyone with whatever we 
> do 
> here.) If we can make sound technical decisions to reduce the 
> problems, fine; if not, we should finish and let the most-qualified 
> people work on the non-technical solutions.
> 
> It is clear that we cannot find sound technical solutions to the 
> simplified-traditional problem. So, we should move on, making sure 
> that whatever technical solution we create doesn't *prevent* a later 
> 
> non-technical solution.
> 
> If you can show where the current IDNA/ACE/nameprep solutions 
> prevent 
> an eventual traditional-simplified solution, please speak up. 
> Otherwise, it is probably better to spend your time starting to work 
> 
> on the non-technical solution, such as suggestions to zone 
> administrators. The sooner that happens, the sooner that the users 
> will get what they want.
> 
> These statements may sound harsh to the people who have never 
> participated in the IETF before now, but they are the way that every 
> 
> protocol is made. For every protocol, problems that could not be 
> solved technically in the protocol get solved in the marketplace. 
> This is true for HTTP, SMTP, Internet telephony, and on and on. IDN 
> will be no different.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>