The real issue: interopability, and a proposal (Was: Consensus Call on Latin Sharp S and Greek Final Sigma)
alexander.mayrhofer at nic.at
Tue Dec 1 12:56:01 CET 2009
> > - add text to Section 5 of idnabis-protocol that says
> > "characters that are PVALID MUST NOT be subject to
> I like this idea. It seems to capture something that was essentially
> obvious to me, but apparently not to some others.
> Essentially, it says
> "don't mess around with valid domain names".
It wasn't obvious to me. I was assuming some text like that to be there, but i couldn't find it in the drafts. On the other hand, i'm not entirely sure whether there *are* cases where a mapping of PVALID characters might make sense - therefore the version more focused on the Exceptions.
For simplicity, i would definitely prefer the more general form, because it would at least "protect" the well known PVALID characters from any mappings prior to lookup, and hence provide a common ground for all mappings.
It might, however, also make it impossible to create a IDNA2003-compatible mapping.
> > Or (more focused)
> > "characters that are listed as Exceptions (F) in
> Section 2.6
> > of [tables] MUST NOT be subject to mappings"
> This would essentially say that you *can* map anything else, starting
> with 'a', which I think would definitely be the wrong
> message, and not
> what anybody would intend.
> > (and i'm pretty sure it creates problems elsewhere),
> What kinds of problems would that be?
Problems with situations where mapping PVALID characters *might* be sensible, for whatever reason. I'm not a script expert - but for example, to map digits 0..9 in various languages always to the ASCII equivalents? I can see that the tables draft has digits in non-ASCII scripts that are PVALID:
104A0..104A9; PVALID # OSMANYA DIGIT ZERO..OSMANYA DIGIT NINE
The requirement would prevent mapping those - i'm not sure this case makes sense, but I'm sure there are better examples, though.
More information about the Idna-update