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: <div style="margin-left: 40px;">
<p>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 : « <font style="font-variant: small-caps;">Longtemps Marcel s’est couché de bonne heure</font> ».</p>
</div><p>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 "o" in "rove", "move", and "love" needs to be in the encoding, or that the difference between the "." in "1.2", "etc.", or "." 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! </p>
Nor, of course, should anyone think of trying to capture this distinction in IDNA.<br><br>Mark
<br><br><div class="gmail_quote">On Wed, Jul 1, 2009 at 06:13, jefsey <span dir="ltr"><<a href="mailto:jefsey@jefsey.com">jefsey@jefsey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">At 14:38 01/07/2009, Vint Cerf wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jefsey, maybe my email rendering code is broken but the string I am<br>
seeing in your message looks like a purely ascii string making it a<br>
conventional ascii domain name not requiring any special treatment.<br>
</blockquote>
<br></div>
Vint,<br>
The string you see on your screen is ASCII - the string I enter is not. This is because Unicode is being used and Unicode does not properly supports the French language orthotypography.<br>
<br>
In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII but a French "E" majuscule. I am sure Unicode has no problem in supporting them, or TLD Tables can be used. "Ecole.fra" is a user domain name which may have nothing to do (except phishing) with "école.fra", "ecole.fra" and "École.fra".<br>
<br>
This means there are wo problems:<br>
<br>
- they are to be able to resolve different IP addresses.<br>
- they also are to be able to resolve the same IP address.<br>
<br>
However, the decision is only with the registrant. So, the simplest is to consider each usage domain name separately. If some are to resolve the same IP, the registrant will only register several domain names.<br><font color="#888888">
<br>
jfc</font><div><div></div><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 04:18 01/07/2009, Vint Cerf wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
jefsey, it cannot be an A-label since that is defined to include<br>
"xn--" as a prefix.<br>
</blockquote>
<br>
Dear Vint,<br>
This is the conflict we have and the resulting confusion.<br>
<br>
- usage considers what is enter in usage applications (from the<br>
entire Unicode set [actually it needs much more (ex.Natal from M$]<br>
_including_ ASCII)<br>
- I consider what the DNS is asked to resolve after an algorithm<br>
(including null and punycode ones) has been applied.<br>
- you consider complex U-/A-... labels which do not overlap.<br>
"Ecole.fra" is not supported by this label list.<br>
<br>
"Ecole.fra",<br>
1) it is a U-label<br>
2) but you do not want to support it as xn--cole-abc.fra. You keep<br>
it as an non punycoded yet A-label without "xn--" prefix.<br>
3) this confuses Andrew and John (who should not be concerned)<br>
because they try to understand how the DNS and Unicode casefolding<br>
could support the orthogonal User's casefolding (i.e.<br>
orthotypography).<br>
<br>
I see no other solution that to carry the mapping:<br>
- at the user application layer (outside of the Internet pile) and<br>
the Internet should remain transparent to "xn--" labels.<br>
- through a different presentation, and casefolding mapping etc.<br>
using "xs--" labels.<br>
<br>
Neither DNS nor Unicode casefolding are concerned. Only usage's side<br>
application (this is why the architecture is named IDNA): usage<br>
casefolding is to be decided and managed by the user through his<br>
application (if he wants to have it), depending on his own context,<br>
language, culture, job, kind of application, etc. and if the other<br>
end supports additional usage side features. This permits an<br>
application to application relation, where entropic actions (as<br>
required by the DNS resolution) can be restored through a<br>
negantropic process supported by metadata exchanges. As Elisabeth<br>
explained it.<br>
<br>
This being said, if you find a case (so far there is none) where a<br>
entropic mapping (casefolding or other) is universally accepted by<br>
users - or restored through a negentropic process such as what we<br>
call "duplex entities" -, supported by exvery encryption system,<br>
transparent to other technologies as well (netneutrality), etc. it<br>
could very well be investigated at protocol level (i.e within the<br>
Internet pile). Otherwise mapping can only be processed outside of<br>
the Internet pile. This is exactly the target and Charter of IDNA as<br>
I read and respect it.<br>
<br>
jfc<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 17:12 30/06/2009, Andrew Sullivan wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
and, in particular, if we want to be sensitive to such upper and<br>
lower case when the data comes back to us from the DNS resolver<br>
level.<br>
</blockquote>
<br>
Please, let not confuse :<br>
<br>
1) the DNS layer, where you run the game the way you want according<br>
to your published rules, and the Application Domain Names.<br>
2) French majuscules and upper cases.<br>
<br>
The U-label, A-label, etc. wording IMHO helps that confusion. Is<br>
Ecole.fra an U-label or an A-label? All I know is that it is an<br>
application domain name (like in "IDNA"). Also, that if the proposed<br>
text does not actually document the "ecole.fra, école.fra,<br>
Ecole.fra" case, this case will have to be documented during the<br>
IETF/LC.<br>
<br>
May be it is the best thing to do? so the whole IETF community may<br>
decide what does concern the whole community?<br>
jfc<br>
<br>
_______________________________________________<br>
Idna-arabicscript mailing list<br>
Arabic Script IDN Working Group (ASIWG)<br>
<a href="mailto:Idna-arabicscript@lists.irnic.ir" target="_blank">Idna-arabicscript@lists.irnic.ir</a><br>
<a href="http://lists.irnic.ir/mailman/listinfo/idna-arabicscript" target="_blank">http://lists.irnic.ir/mailman/listinfo/idna-arabicscript</a><br>
</blockquote></blockquote></blockquote></blockquote>
<br>
_______________________________________________<br>
Idna-arabicscript mailing list<br>
Arabic Script IDN Working Group (ASIWG)<br>
<a href="mailto:Idna-arabicscript@lists.irnic.ir" target="_blank">Idna-arabicscript@lists.irnic.ir</a><br>
<a href="http://lists.irnic.ir/mailman/listinfo/idna-arabicscript" target="_blank">http://lists.irnic.ir/mailman/listinfo/idna-arabicscript</a><br>
</div></div></blockquote></div><br>