Consensus Call on Latin Sharp S and Greek Final Sigma

[Shawn Steele]

> Re-introduction of mandatory/normative mapping strikes me as old
> territory that had been settled.

> Vint

Rather, old territory where one faction overrode the concerns and objections of another group, hence UTR#46.

I could live with the current drafts, but I can't implement them without something like UTR#46 to fill in the holes.  Lisa seems to feel that the mere existance of UTR#46 demonstrates that the current drafts aren't filling the needs of all the users.

> We added a non-normative document about mapping for User Interface  
> purposes.

Which is insufficient.

> Implicit in that was awareness that context might make a  
> difference as to choice of mapping.

Which is even worse.  To take eszett, a swiss context may produce different results than a germany context.  So a Germany user ends up at a different web site than a swiss user.  Or, worse, a Germany user visiting a Swiss airport kiosk ends up someplace unexpected.  No matter what else, inconsistent mappings MUST be verbotten.  I cannot think of any practical mechanism to allow different registrars to specify their contexts in a consistent mechanism.  (They'd have to dump mapping tables along with the zone files or something).

(Yes, I realize eszett mappings could be forbidden if it's PVALID, but that's not the point, this example exists for many cases where mapping is interesting, such as dot/dotless capital letter I, etc.)

I cannot update IdnToAscii, IdnToUnicode, IdnToNameprepUnicode (Windows), and the IdnMapping class (.Net), without a well defined and consistent mapping table.  Other implementors seem to share that view regardless of other disagreement about individual characters.  Without well defined, consistent mappings, I'd have to ignore IDNA2008 because I can't have random behavior from system APIs.

-Shawn