<html>
<body>
Dear all,<br>
Will I answer Mark? No. <br><br>
My prority is now with the Interplus Draft as a working document. So I
would lack the time. But mainly this is because I could not.<br>
What Mark talks about is not nonsense.However, (1) everyone knows it (2)
it is by nature a different topic.<br>
I am a multilinguist (simultaneous technical support of a language
diversity), not a linguist (discussing individual language
cases).<br><br>
Mark's interest is in <b>globalization</b>, i.e. the system he invented
to support foreign languages in English technologies. As such it is a
great success. It has the technical cons and pros of being an English
language machine-centric system.<br><br>
My interest is in <b>presentation</b> and <b>extended services</b>
network layers. This what we need in order to empower:<br>
- without constraints every language (including English, French, Arabic,
Chinese etc.) <br>
- as part of semiotic (including scripts) mediatic end to end functions
(access, addressing, delivery, routing, etc.) , <br>
- in every technology (including the Internet), <br>
- in using every coding (<b>including Unicode</b>),<br>
- for every application (including IDNA), <br>
- in every environment from brain cells to outerspace identified by their
namespaces.<br>
This is a people centric system, to accomodate the relations of the
people diversity in what they are and what they do. Is it a reason why to
disregard Unicode? No!&nbsp; As fas as the Internet is concerned, Unicode
is a structured set of code-points. If IDNA users are happy with it, the
Internet should be happy with it. If they are not, they should be not.
<br><br>
Does that mean that Unicode should be disregarded ? No!<br><br>
The same as Unicode is not a reason for disregarding the DNS (this is the
justification of IDNA). Each addresses the needs of a different layer.
Layers need to cooperate. In order for all them to progress in
symbiosis.<br><br>
NB. what Marks discusses is not obsolete, it is just (as he documents it
himself very well) a layer below what I discuss. <br>
Best.<br>
jfc<br>
&nbsp;<br>
&nbsp;<br><br>
At 01:47 03/07/2009, Mark Davis wrote:<br>
<blockquote type=cite class=cite cite="">What Jefsey suggests is all
nonsense.<br><br>
Here is what is happening. Basically, one can make a distinction between
capital letters that are required linguistically (the <i>L</i> at the
start of the sentence below and the <i>M</i> at the start of the proper
name <i>Marcel</i> in the example below) and those that just happen to
have a capital form (because the sentence is set in all caps). The former
in French are called <i>majuscules</i>, and the latter <i>capitales</i>.
>From Wikipedia: <br><br>
La phrase : Â«Â LONGTEMPS MARCEL S’EST COUCHÉ DE BONNE HEURE » est
Ă©crite en capitales, mais seule la première et la dixième lettres sont
majuscules. On s’en rend mieux compte si on Ă©crit cette phrase en
petites capitales : Â«Â Longtemps Marcel s’est couchĂ© de bonne heureÂ
».<br><br>
However, that distinction is not captured in Unicode, nor in ASCII, nor
in any other character encodings that I know of, <b>nor should it be</b>.
There are many distinctions in the <i>usage</i> of characters that are
not, and should not be, represented in the encoding. One could just as
well argue that the distinction between the pronunciation of
&quot;o&quot; in &quot;rove&quot;, &quot;move&quot;, and &quot;love&quot;
needs to be in the encoding, or that the difference between the
&quot;.&quot; in &quot;1.2&quot;, &quot;etc.&quot;, or &quot;.&quot; at
the end of a sentence needs to be in the encoding. That would end up with
scads of identical characters that people would not distinguish when
keying, could not distinguish in display, are not in any existing data,
could not be depended on in processing, but would be just a marvelous
opportunity for spoofing! <br>
Nor, of course, should anyone think of trying to capture this distinction
in IDNA.<br>
<br>
Mark </blockquote></body>
</html>