Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison

[Jefsey]

At 18:09 07/08/2014, John C Klensin wrote:
>Jefsey,
>
>I am not sure I understand what you are talking about but, if I
>do, it is about an almost completely different topic.

John,

as you may remember I am not interested in Unicode per se. I am 
interested in the open pragmatic use of the digisphere through 
whatever is available and people want to use. This calls for external 
(fringe to fringe) innovations not to be constrained by any internal 
(end to end) MUST. As far as I undedrstand, the issue being raised 
concerns orthotypography in a  specific language?

This has been ruled out of the IDNA2008 scope. Because it was ruled 
out the Unicode scope.

Now, what may have to be clarified is what a user calls confusable. 
For users, "confusables" are different codepoint sequences that look 
the same (whatever the reason). If the Hamza added sequences are not 
creating internet use confusion, we are not concerned. If they are, 
we are concerned. However, we MUST not decide for others: we only are 
to give them the possibility to decide by themselves.

A digital name supports a semantic address through group of visual 
signs. Whatever the underlying code, version, etc. For the time being 
the IETF has chosen a single underlying typographic code to support 
the digital names' signs. That code does not consider orthotypography 
(i.e. semantic constraints that are language dependant). So the IETF 
has chosed that its end to end protocol are not concerned by 
orthotypographic issues. Tomorrow we can chose an additional code to 
Unicode: we need the use of these two codes to be transparent to our 
own use, independently from any orthotypographic issue. This is the 
metric of our choice.

1. TLD Managers must be able to use their own add-ons to support or 
not orthotypographic aspects in their zone. How do you know if you 
will not create conflicts today with Hamza, or in "equivalent" other cases?
2. If you consider Hamza you must consider French majucules. Or am I wrong?

Best.
jfc

>At 19:37 07/08/2014, John C Klensin wrote:
>p.s. RFC 5895 was never intended to be standards track.  Talking 
>about "denying" that status to it is misleading at be

Short memories. Anyway, the point is that without Paul's and Pete's 
solution I would never have given up the orthotypographic requirement 
and IDNA would have been technically and politically blocked. I 
consider that RFC 5895 is one of the most fundamental architectural 
RFCs of the internet as it illustrates how the internet architecture 
survives external diversity, by subsidiarity at the fringe. This is 
where French majuscules can be treated (layer six experimentation).