Q3: What characters should be allowed in a revised IDNA2008 specification?

[Mark Davis]

Understood. But we've heard a very clear statement from DENIC on the similar
case, with eszett. That is, they prefer a mapping, and if there is a
mapping, they want it to be the same as IDNA2003. We haven't heard a clear
statement from Greek participants on the issue, so we need to work to make
sure everyone understands the current situation.

And, the Greek case could also be handled compatibly by slight
postprocessing for display and choice of names; eg, map sigma to final sigma
if final. Then "Cyprus-Travel" works fine, and we don't have URLs going to
two different locations.

Mark


On Thu, Apr 2, 2009 at 12:52, Harald Alvestrand <harald at alvestrand.no>wrote:

> Mark Davis wrote:
>
>> I agree, and I think there is rough consensus to that effect.
>>
>> My biggest concern as far as a transitional appendix is not the Hearts and
>> others, but the cases where IDNA2003 and IDNA2008 produce *divergent*
>> completely valid A-Labels. For that, I think we must have a very good story
>> because of security and interoperability issues.
>>
>> If we have M-Labels (whether full NFKC-CF-RDI or some subset), then it
>> looks like the sigma and eszett would go away, so that leaves us with only
>> two cases; ZWJ and ZWNJ. In that case the recommended transitional strategy
>> can devolve to:
>>
>>    * Lookup with IDNA2008. If it fails, remove any ZWJ/NJ, and try again.
>>
>>  if we go with lowercasing rather than casefolding, eszett and final sigma
> survive.
>
> If we go with lowercasing, "CyprusTravel" in Greek can be represented with
> a final sigma for "Cyprus"; if we go with casefolding, we end up with
> "cyprustravel" using a non-final sigma.
>
>                       Harald
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090402/b549bedf/attachment-0001.htm