Greek Casefolding sigma

segred at ics.forth.gr segred at ics.forth.gr
Sun Mar 30 18:44:14 CEST 2008


Dear Paul,

your answer just confirms my fears. Instead of the protocol taking  
care of an issue which is clearly an IDNA200X problem it throws the  
ball to the user interface.

What is there to ensure that we will have a uniform behaviour of all  
applications when they face a final sigma? Nothing.

We ask this problem to be solved inside the protocol and not in *some*  
application layer. It is a matter of correct treatment of a language.

The same applies for the upper case characters. It is unclear to me  
why we shouldn't have Greek Upper case characters but it is OK for the  
Upper Latin characters. If mapping is the solution, then mapping it  
should be.

Kind Regards,

Vaggelis Segredakis


Quoting idna-update-request at alvestrand.no:

> ------------------------------
>
> Message: 2
> Date: Sat, 29 Mar 2008 14:05:26 -0700
> From: Paul Hoffman <phoffman at imc.org>
> Subject: Re: Greek Casefolding sigma
> To: idna-update at alvestrand.no
> Message-ID: <p0624081ac4145e3b40b7@[10.20.30.162]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
> Let me make an attempt at this, since those of the previous posters
> didn't seem to work.
>
> At 9:00 PM +0200 3/29/08, segred at ics.forth.gr wrote:
>> What I ask is not to introduce a 25th character in our language (the
>> final sigma as a new character).
>
> Correct.
>
>> The current status is: The final sigma is mapped to the small sigma.
>
> That is, in IDNA2003, a final sigma in an input string is mapped to a
> small sigma.
>
>> Is the IDNA200X with the DISALLOWED form of final sigma still   
>> preserving this
>> mapping inside the protocol?
>
> No, because there is no mapping inside the protocol. That seems to be
> unclear in the current protocol document
> (draft-klensin-idnabis-protocol-04.txt). However, the protocol does
> suggest, possibly too gently, that the application that takes the
> user's input might do mapping itself, outside the protocol:
>
> 5.3.  Character Changes in Preprocessing or the User Interface
>
>     The Unicode string MAY then be processed, in a way specific to the
>     local environment, to make the result of the IDNA processing match
>     user expectations.  For instance, at this step, it would be
>     reasonable to convert all upper case characters to lower case, if
>     this makes sense in the user's environment.
>
> An interface that understands that a final sigma should be mapped to
> a small sigma would do that in this step.
>
>
> ------------------------------
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the Idna-update mailing list