Re: [idn] WG Update

[=?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= <tsenglm@cc.ncu.edu.tw>]

> As in the 2. General Requirements of 2.3 Canonicalization
>
> [21] In order to retain backward compatibility with the current DNS,
> the service MUST retain the case-insensitive comparison for US-ASCII
> as specified in RFC 1035. For example, Latin capital letter A (U+0041)
> MUST match Latin small letter a (U+0061). Unicode Technical Report #21
> describes some of the issues with case mapping. Case-insensitivity for
> non US-ASCII MUST be discussed in the protocol proposal.
>
> I recommend modify the last line "MUST be discussed" to be
> "MUST be provided", as to be " Case-insensitivity for non US-ASCII MUST be
> provided in the protocol proposal"
>
        The term " Case-insenstivitty for non US-ASCII "  should be defined
and described clearly, especially in any phase before ACE translation.
        Unicode is the collection of all scripts in all native code.  Some
scripts  are  alphabetic  font of "Full size  or double character size ASCII
font" coded in  native code and collected in UNICODE table.  That part  are
treated the same as US-ASCII characters in nameprep by case mapping with the
table of Unicode Technical Reports #21. I think this part is not related to
the issue of Case-incenstivity for non-US-ASCII ".
         The TC/SC equivalent class is always conceptually described by the
similar properties of  case in ASCII characters ,  but one thing in
retaining the out-look of original form is very inportant in CJK characters
of equivalent class .  That is say, to retain the case-insensitive
comparison for US-ASCII should not be implemented with nameprep  by
"force-all-to-lower-case" , I think the approach of "forced all ASCII
characters to lower case and losing the information of case" is not
necessary in nameprep phase. So, the key point of "Case-insenstivity for non
US-ASCII " is to reserve the case information before ACE translation.
Because AMC-ACE-Z  encoding has the feature that can retain the case of
US-ASCII characters in  ACE formatted IDN.   And the comparison is
accomplished by the current LDH-DNS server in insensitive-case comparison.
        The backward compatibility in retainning  the out-look of case of
ASCII is important now . It is  not just to keep the compatibilty of past
ASCII name but also help to use the case anotation of AMC-ACE-Z to  support
CJK characters can be recovered to the original scripts form.  The
comparison of TC/SC equivalent class are also based on the same feature of
case-insensitive comparison in LDH-DNS but it need to retain all the
original case form in passing-thru all processing phase. So the non-ASCII
part of IDN can be recoveried to their original scripts form.

L.M.Tseng

> Beside [21], I think draft requirement-08 still need all the WG members to
> review carefully to insure it meet the real IDN requirements.
>
> Erin Chen
>
> James Seng/Personal ¼g¤J¡G
>
> > In the last London meeting, there are still some outstanding issues
> > which we agreed to bring it back to the mailing list to discuss.
> >
> > First, the issue of nameprep. nameprep have been renamed to stringprep
> > and the new draft is available few days ago. Please review
> > draft-ietf-idn-nameprep-06.txt.
> >
> > And related to nameprep are the jpchar, hanguelchar and tsconv drafts.
> > The authors should get together to consider an architecture document.
> > We should set a deadline for this to be concluded, probably sometime
> > before Salt Lake meeting.
> >
> > This architecture document should take into consideration of:
> > a. the recommendation from the Unicode Consortium to the WG dated 02Sept
> > b. the source and stablity of the referenced work/codepoints
> >
> > (Personally, I would strongly recommend that nameprep remains as it is
> > and the rest of the "localization" to be deal at a different level,
> > either at the input method or below at the zone file.)
> >
> >