[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] opting out of SC/TC equivalence
I do have a proposal, but it is not complete. I am
waiting for references to be arrived from US mail.
The relevent part of the proposal of this discussion
has two parts: Using script tags to patrol certain
range of UCS which is relevent to that scripts. This
is posted a few days ago, no one seems to care
about.
The second relevent part of this discussion is a
relational database model of [nameprep], I had
three postings on it too. Nobody seems care about it
either. Why do I want to talk more about it?
Talking about scoping of this WG? which is defined
in [RFC 2825]. Please check it.
To answer John's question:
>And, unless whatever is done is isolated -- through procedures,
>structure, or layering-- in a way that is robust, accessible to
>all users of URLs based in the Chinese language, and that does
>not fragment the Internet, we also need to be sure that the
>tables and mechanisms that do SC/TC equivalence don't
>accidentally map Kanji or Hangul into SC.
>
> john
>
A part of the database table look like this:
Unicode Unicode GB BIG5 Chinese Unicode KSC Korean
CJK TC StepCode Hangul StepCode
For some rows Korean does not use, which would be empty.
This is one search operation for mapping and ACE encoding!
And this will take care of Kanji, Greek and Cyrillic mapping too.
When IETF accepting this model and let local standards have
direct access of [nameprep] the GB<=>BIG5 mapping takes
care of TC/SC mapping table.
Liana
On Wed, 29 Aug 2001 07:07:57 -0700 Dave Crocker <dhc@dcrocker.net>
writes:
> At 01:20 AM 8/29/2001, Harald Tveit Alvestrand wrote:
> >--On 28. august 2001 13:40 -0700 liana.ydisg@juno.com wrote:
> >> I happend to have an idea that 1100 half size
> >>code point may solve part of the problem and another 200
> >>TC/SC listing completes it. This can be used in [nameprep].
> >>What do you think?
> >
> >I would be happy to see a complete proposal.
>
>
> Excuse me, but I had the impression that solving this problem was
> rather
> clearly outside of the requirements for this working group.
>
> At a minimum, it would be very helpful to get explicit resolution
> about the
> requirement to solve this, in this working group, as well as the
> requirement to solve it immediately, rather than consider it for a
> later
> version of the working group effort.
>
> d/
>
>
> ----------
> Dave Crocker <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking <http://www.brandenburg.com>
> tel +1.408.246.8253; fax +1.408.273.6464
>
>