The real issue: interopability, and a proposal (Was: Consensus Call on Latin Sharp S and Greek Final Sigma)

[Alexander Mayrhofer]

> > - add text to Section 5 of idnabis-protocol that says
> >
> >          "characters that are PVALID MUST NOT be subject to 
> mappings".
> 
> 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.
 
Alex