Dear Colleagues,<br>I will respond to Martin and John one shot.<br><br>At 04:39 14/09/2009, John C Klensin wrote:<br>--On Monday, September 14, 2009 02:11 +0200 jean-michel bernier<br>de portzamparc <<a href="mailto:jmabdp@gmail.com">jmabdp@gmail.com</a>> wrote:<br>
<br>> Dear colleagues,<br>> among the points we introduced during the WG/LC that have not<br>> been addressed yeat is the end to end support of script<br>> oriented metadata (one example being the French majuscules).<br>
> Metadata can be supported either:<br>> <br>> - explicitely through a specific new code from "unassigned" -<br>> since Language Tag and Private Use control are disallowed<br><br>As is any use of an UNASSIGNED code. The use of such codes is a<br>
protocol violation; conforming implementations will not look up<br>labels containing them.<br><br><div style="margin-left: 40px; color: rgb(51, 102, 255);"><span style="color: rgb(102, 51, 255);">Correct. This is why there would be no violation of IDNA by an extended punnyplus algorithm. </span><br>
</div><br>> - implicitely through an unlike sequence of PVALID codes (ex:<br>> FE73-0061 ... 007A)<br><br>Since there is no prohibition on such strings, nothing prevents<br>you from using them and interpreting them in a special way,<br>
assuming that FE73 is not problematic from a Bidi standpoint<br>(while it is identified as a "Arabic" character, the code point<br>does not appear in Arabic-Shaping.txt, which drives Bidi).<br>However, most applications globally will interpret them as valid<br>
labels, many or most applications will warn against them as<br>mixing scripts, and attempts to use specific characters as<br>metadata indicators will not work satisfactorily except in your<br>particular applications.<br><br>
<div style="margin-left: 40px;"><span style="color: rgb(102, 102, 204);">This is why I propose that code. It increases the robustness of the security. It should only go through seemlessly with punyplus aware applications.</span><br style="color: rgb(102, 102, 204);">
</div><br> > If I call "punnyplus" the extended algorithm that will provide<br>> this support: - in the first case there is no risk of<br>> confusion since it will only work if both ends are punnyplus<br>
> enabled.<br><br>In the first case, anyone supporting "punnyplus" will be in<br>violation of IDNA.<br><br><div style="margin-left: 40px;"><span style="color: rgb(102, 51, 255);">They will only support IDNA and more. </span><br>
</div><br>> - in the second case there is no risk of confusion either but<br>> the sending end is to be punyplus enabled.<br><br>And the receiving system has to know to apply "punyplus" rules<br>rather than IDNA rules.<br>
<br><div style="margin-left: 40px;"><span style="color: rgb(102, 51, 255);">No. It will receive an A-label. I suppose that every host will soon accept U and A labels as aliases, no matter if their hosting service or ISP or operating system supports punycode or not. The matter is only that ecole.fra and Ecole.fra may target different hosts and be filtered out in case of error.</span><br>
</div><br>> If the WG documents remain unchanged in terms of French<br>> majuscules support, the support of the two will be offered as<br>> a response to the "+" entry. Ex. http://+Etat.fr.<br><br>That would be an interoperability problem. I would be quite<br>
surprised if FRNIC went along and more surprised if ICANN<br>permitted any gTLD to do this.<br><br><div style="margin-left: 40px;"><span style="color: rgb(102, 51, 255);">We are not at this stage interested in AFNIC nor with ICANN. We are interested in a standard better use of IDNA and in Project.FRA and Multilinc test beds. We are confident that by the time the two test beds have been carried and published their reporst, punyplus is adopted as an Internet standard by the IESG, majuscule metadata is supported off the shelves by ISO 10646 and Unicode. However, before introducing an NWIP on the matter, it is better to investigate and test different solutions and get them validated.</span> <br style="color: rgb(102, 51, 255);">
</div><br>At 09:42 14/09/2009, Martin J. Dürst wrote:<br>Hello John, Jean-Michel, others,<br><br>On 2009/09/14 11:39, John C Klensin wrote:<br>><br>> --On Monday, September 14, 2009 02:11 +0200 jean-michel bernier<br>
> de portzamparc<<a href="mailto:jmabdp@gmail.com">jmabdp@gmail.com</a>> wrote:<br>><br>>> Dear colleagues,<br>>> among the points we introduced during the WG/LC that have not<br>>> been addressed yeat is the end to end support of script<br>
>> oriented metadata (one example being the French majuscules).<br>>> Metadata can be supported either:<br><br>>> - implicitely through an unlike sequence of PVALID codes (ex:<br>>> FE73-0061 ... 007A)<br>
><br>> Since there is no prohibition on such strings, nothing prevents<br>> you from using them and interpreting them in a special way,<br>> assuming that FE73 is not problematic from a Bidi standpoint<br>> (while it is identified as a "Arabic" character, the code point<br>
> does not appear in Arabic-Shaping.txt, which drives Bidi).<br><br>Where in Bidi does it say so? The Bidi document refers to Bidi <br>properties, and these are defined in UnicodeData.txt <br>(<a href="http://www.unicode.org/Public/UNIDATA/UnicodeData.txt">http://www.unicode.org/Public/UNIDATA/UnicodeData.txt</a>). There, U+FE73 <br>
is AL (Arabic Letter), which means that the above won't work exactly as <br>proposed. Of course, there are ample other characters in Unicode which <br>may be suited for misuse for the above mentioned purpose.<br><br><div style="margin-left: 40px;">
<span style="color: rgb(102, 51, 255);">In selecting that code, I just looked at what might cause the most of possible errors if it was not replaced by punyplus. I am not a Unicode expert and every advice is welcome.</span><br>
</div><br>> However, most applications globally will interpret them as valid<br>> labels, many or most applications will warn against them as<br>> mixing scripts, and attempts to use specific characters as<br>> metadata indicators will not work satisfactorily except in your<br>
> particular applications.<br><br>Yes indeed.<br><br><div style="margin-left: 40px;"><span style="color: rgb(102, 51, 255);">This is exactly what I want to obtain. It will result in an error. This is the usual protection that was adopted against IDNA misuses? </span><br>
</div><br>>> If the WG documents remain unchanged in terms of French<br>>> majuscules support, the support of the two will be offered as<br>>> a response to the "+" entry. Ex. http://+Etat.fr.<br>
<br>While I'm writing this mail, some comments on majuscules that I have <br>been thinking about for quite a while.<br><br>On careful reading, the French article <br><a href="http://fr.wikipedia.org/wiki/Majuscule">http://fr.wikipedia.org/wiki/Majuscule</a> and the English counterpart at <br>
<a href="http://en.wikipedia.org/wiki/Majuscule">http://en.wikipedia.org/wiki/Majuscule</a> aren't too different at all. Not <br>only French, but a wide range (if not all) European languages know a <br>difference between 'majuscules' and 'capitales', and good orthography <br>
and typography is impossible without these concepts, even if they may be <br>less explicitly distinguished in other languages than in French.<br><br><div style="margin-left: 40px; color: rgb(102, 51, 255);">Correct. <br></div>
<br>The reason why this distinction hasn't made it into character encoding <br>is in part historical (less computers than typewriters), but a big part <br>of it, in my opinion, has to be attributed to the fact that a large <br>
majority of the population everywhere around the world thinks primarily <br>visually. I.e. most people everywhere around the world want an upper <br>case letter when they want an upper case letter and a lower case letter <br>
when they want a lower case letter, and on first approximation, they <br>don't care whether something is a 'majuscule' or a 'capitale' because <br>they both look the same. Trying to teach everybody to always be aware of <br>
the difference and press the right shift key would simply be impossible. <br>That's not only the case for this specific difference, but is also a <br>widely reported phenomenon on other levels, such as document appearance <br>
vs. document structure (think nicely structured, valid (X)HTML) vs. "it <br>has to look the same on every browser").<br><br>This may be difficult to understand for people who think mainly <br>logically rather than visually. I suggest they take a Myers-Briggs test <br>
and compare their result with the percentages for each type.<br><br><div style="margin-left: 40px;"><span style="color: rgb(102, 51, 255);">Unicode and punycode strive to respect the entered cases. IDNA does not for a reason which is now gone (correction of the misunderstanding between I would call Unicode real case folding and DNS virtual case folding). As long as Unicode/punycode permitted to be transparent to what users enter, nobody cared about the reasons why they were entered. When an IDNA internal reason came and conflict with the user reasons a solution has to be found. </span><br style="color: rgb(102, 51, 255);">
<br style="color: rgb(102, 51, 255);"><span style="color: rgb(102, 51, 255);">The new pre-punycode lower casing, is a change in the punycode algorithm, which when corellated with the DNS "virtual" lower casing permits a robust support of everything, except upper casing. This has therefore to be corrected : the Unicode codepoint that isentered MUST be received on the other end, otherwise IDNA is in breach of the basic Internet end to end concept. </span><br style="color: rgb(102, 51, 255);">
<br style="color: rgb(102, 51, 255);"><span style="color: rgb(102, 51, 255);">There are two ways of considering this. As a punycode change (what the Charter prohibits) or as a pre/post punycode change. If punycode must receive lowercased entries (an IDNA addition), IDNA must cater for the required output uppercasing when needed. </span><br style="color: rgb(102, 51, 255);">
<br style="color: rgb(102, 51, 255);"><span style="color: rgb(102, 51, 255);">What "+" indicates in http://+Etat.fra is not that E must be an upper case but that Etat (State) is a case sensitive entry. http://+état.fra (status) will result in a lowercase output. </span><br>
<br><span style="color: rgb(102, 51, 255);">Now, it is true that Unicode imperfectly supports majuscules. It supports their orthotypography not their grammar, i.e. the reason why they are entered as uppercases (i.e. that they are majuscules, i.e. a metalanguage information). Introducing in ISO 10646 a way to support that kind of metalangue information is only a plus, because some typographic style rendering might use it. For example, accentuated majuscules should be rendered in best mechanical printing as accentuated upper cases, but should be rendered as non- accentuated uppercases in manual scripting. These are "should" and a fount may propose more precision that Unicode could not support if required. </span><br>
<br></div><span style="color: rgb(102, 51, 255);">Portzamparc</span><br style="color: rgb(102, 51, 255);"><div style="margin-left: 40px;"><br style="color: rgb(102, 51, 255);"></div><br>