Consensus Call Tranche 8 (Character Adjustments)

[Vaggelis Segredakis]

> Consensus Call Tranche 8 (character adjustments)
> 
> Place your reply here: [YES or NO]

Conditional YES

> COMMENTS:

I have no real knowledge of the problems that are behind (8.a) and (8.c) and
I cannot say yes/no to them. I say YES to discuss the final sigma issue.

> (8.b) Make Greek final sigma Protocol-Valid per list discussion.

I would like the final sigma to continue working as today so that
registrants can use small caps domain names as they usually do in the Greek
language, typing the final sigma at the end of the word.

Please accept an example for clarification reasons for the members of our
list:

It would be best if "κύπρος" and "κύπροσ" were represented with different
punycode translation since they would be correctly represented in the
address bar.

However, although in IDNA2008 the upper case characters are invalid I am
sure that they will be accepted in the browser and translated to small case
characters. In this translation case, there is no upper case character
equivalent to the final sigma. Both final sigma and medial sigma have the
same uppercase (Σ).

This brings us to the case where if you have registered "κύπρος", you will
have no way to write this domain in upper case, other than misspell it to
"ΚΥΠΡΟς" while somebody else could have registered "κύπροσ" (xn--vxakcel0d)
- "ΚΥΠΡΟΣ" in uppercase and on purpose phish for your clients who rightfully
think that "ΚΥΠΡΟΣ" is the correct uppercase equivalent for "κύπρος".

If in IDNA2008 you make final sigma and medial sigma different characters
but you accept both, in the Greek registry we will try to make a DNAME of
the two domain names and protect our registrants. I do not expect this to be
the case with the gTLDs or anyone else allowing registrations in Greek
characters.

At present the protocol as proposed excludes the final sigma from the table
of characters that are valid for registration. The certain thing for me,
however, is that the use of the final sigma in an address bar is mandatory
for the representation of the Greek language and it should somehow be in the
protocol.

Since we have two possible solutions, I could discuss on the pros and cons
of any of them. My preference is with the one where the protocol proactively
prohibits phishing and allows for the correct translation from Upper case to
Lower case for a good user experience of the IDNs. Thus I propose to
maintain the IDNA2003 solution, the character mapping, in IDNA2008.

Kind Regards,
 
Vaggelis Segredakis
Administrator of the .GR Top Level Domain
Institute of Computer Science
Foundation for Research and Technology - Hellas
Tel. +30-281-0391450
Fax +30-281-0391451
Email segred at ics.forth.gr