Subject: Re: [Sip] i18n issue: composed characters

From: [email-masked]
Date: Tue, 26 Nov 2002 06:39:29 -0500

I would agree that we should specify guidelines for this. 

More than latin representations, Im worried about the composition of Asian 
languages which seem to have this issue.
And yes -> internationalization (geez you only realize how long this word 
is when you start typing it) is definetely happening today.

Technically,  I am totally against loading the proxy with normalization - 
Id much rather this happens at the UA side. 
However, practically, I am not sure if we can enforce this - and the 
reason I am not sure is because I dont know the acceptability
of unicode encoding norms in various nations. 

Be that may, we could look into including a SHOULD clause that a UA 
wishing to support unicode SHOULD normalize it according
to xxx scheme before sending it out. And a proxy MAY decide to implement 
the unicode translation (for situations where enforcing
a unicode normalization across UAs may not be practical).

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066

Adam Roach <[email-masked]>
Sent by: [email-masked]
11/26/2002 01:21 AM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        [Sip] i18n issue: composed characters

While digging through the confctrl archives, circa 08/99, I
came across a thread that probably shouldn't be lost now that
we have started giving internationalization more serious thought.

With Unicode, there are two different ways to encode most
accented Latin characters. I beleive the same issue occurs
in several other character sets (e.g. composition of Korean
Hangul versus use of precomposed characters).

For example, the character "Å" (an "A" with a loop over it)
can be encoded in Unicode as U+00C5 or as U+212B or as the
combination U+0041 U+030A.

Now, with multiple possible encodings for single characters,
we have the problem of, for example, someone registering as
"sip:[email-masked]", and someone else inviting
"sip:[email-masked]". In both cases, the interface
would render the user portion as "Åse" to the users, but
matching is difficult.

Of course, we *could* just leave this as a server implementation
issue. This is a bit of a pain, since it means that *all* servers
need to perform normalization of unicode characters before
doing any processing. Bleah.

Alternately, taking the suggestion Kevin Payne made so many years
ago, we could specify that any user agent that has the ability
to accept characters that might have multiple Unicode encodings
is responsible for normalization of that input to a single, canonical
form.

My understanding is that Unicode defines at least two methods
of normalization (Canonical and Compatibility), and that a proposal
was floated to define two *additional* methods by performing the
decomposition described by Unicode, followed by a canonical
composition. This has the advantage of taking less space. It's not
clear whether this method [1] made it into any Unicode standards.

So, do we want to address this issue at all, or so we just let
things break?

/a

[1] http://www.unicode.org/unicode/reports/tr15/tr15-10.html
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip