Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison
Jefsey
jefsey at jefsey.com
Thu Aug 7 20:07:21 CEST 2014
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).
More information about the Idna-update
mailing list