IAB Statement on Identifiers and Unicode 7.0.0

[Patrik Fältström]

> On 28 jan 2015, at 19:21, Michel Suignard <michel at suignard.com> wrote:
> 
> I have some sympathy for the issue at hand with the unfortunately misnamed U+08A1, and related issues shown by the IAB document, but banning a character such as U+0626 which has been in Unicode since version 1.1 (I don't understand what you mean by " was added after the combination of the codepoints to the Unicode Standard" in that context) is totally unrealistic unless you want to severely crippled Arabic representation in any sorts of identifiers.

Sorry, I was not clear enough, and I understand you did not understand.

With a base character and combination character it was from an IETF point of view possible to create U+08A1 before Unicode 7.0.0, and then U+08A1 was added. One possible solution (as you know IETF did look at) was to ban U+08A1, and let the old construction be what should be used. Other solutions that have been discussed include banning for registration, but allow the code point to still be PVALID in IDNA. And various other solutions. I guess you have seen most ideas.

But what I saw IAB found was that similar situations exists for other code points (like the o-dash case that Mark brought up). And because of this, IAB "just" say:

> This is why, in order to avoid making a change to any exception lists prematurely, the IAB recommends that the following characters and character sequences be excluded from use in any new identifiers until that solution is found:

I.e. IAB do not know what the solution should be, and this is what IAB is saying. Note "until that solution is found" and "any new identifiers".

This is "just" about buying time so that the issue can be discussed. But, of course, the big thing is that there obviously is a difference in view on what is "similar" and not between UTC and IETF that now must must must be discussed.

   Patrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20150128/ad7e00da/attachment-0001.sig>