<br><br><div class="gmail_quote">2009/4/26 Vint Cerf <span dir="ltr">&lt;<a href="mailto:vint@google.com">vint@google.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">1. At best I can barely make out what Elisabeth is talking about but in any case the thread does not strike me as relevant to our work</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>2. We are not going to change punycode at this point so complaints about its function are inappropriate to this WG</div></div></blockquote><div><br></div><div>Dear Mr. Cerf,</div><div>
at best I can barely make out what you are refering to.  </div><div><br></div><div>- There is no issue about DNS.</div><div>- There no issue about punycode.</div><div>- There is no issue about finalizing mapping function. </div>
<div>- Along the charter there should be no issue about the location of the mapping function.</div><div><br></div><div>So there should be no issue at all. </div><div><br></div><div>This is why I consider that the work of this WG is completed, except the application developper information document by Patrick Falström. But I have not understood if you wanted or not it to be a WG-IDNABIS deliverable.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div>What we need now is to finalize the mapping function and its application to IDN lookups in IDNA2008.</div>
</div></blockquote><div><br></div><div>What needs to be defined is what &quot;IDN lookups&quot; can be. I plain words that I can understand as a user there are two possibilities:</div><div><br></div><div>1. one is as per the charter: IDNs are mapped into regular LDH DNs at application level, resulting in regular DN lookups. I am fully satisfied with this option.</div>
<div><br></div><div>2. another one is not as per the charter: IDNs mapping is bundled with lookup at protocol level, making the IDNA2008 scriptural space non transparent, i.e. non neutral.  I understand you prefer that option. </div>
<div><br></div><div>If I am uncorrect, please explain me where.</div><div>Thank you !<br></div><div><br></div><div>Elisabeth Blanconil</div><div><br></div><div> On Apr 26, 2009, at 12:27 AM, Elisabeth Blanconil wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div class="h5"><div class="gmail_quote">2009/4/25 Gervase Markham <span dir="ltr">&lt;<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> <div>On 24/04/09 18:27, Elisabeth Blanconil wrote:<br> <blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
 There is nothing to object.<br> <br> The &quot;.fra&quot; project is destined to support the full French language<br> scriptural bandwidth and therefore regular pragmatic environment. Our<br> job is to support semantic addresses (i.e. also domain names) the<br>
 semantic of which demands majuscules.<br> </blockquote> <br></div> [Apologies if this is old ground for people.]<br> <br> But in the current infrastructure, you can type capital letters into your web browser and nothing breaks. It even continues to display those capital letters to you. This doesn&#39;t require the DNS be case-sensitive. In effect, DNS has built into it a mechanism were every possible case-variant of a name is bundled together. Why does supporting the French language fully require the ability for (the equivalents of) <a href="http://ABC.com" target="_blank">http://ABC.com</a> and <a href="http://abc.com" target="_blank">http://abc.com</a> to take you to different web sites?</blockquote>
 <div><br>This is very simple. The real issue we (as an R&amp;D group) is semiotic digital facilitation integration. This means that when some human wants to convey a meaning, a thought, he can use a very large number of mediatic artifacts. One of these artifacts is the character set attached to his natural language. If that character set is stable, it means that it represents the necessary scriptural bandwidth to carry every meaning people want to express or need to understand in the context of that natural language (syntax, metalanguage, usage, cultural back-ground, etc.)<br>
 <br>The French language calls at least for a scriptural bandwidth of 90 characters. English language actually calls for at least 50. I say at least because we work on this with different centers of expertise and of authority. One of the reason is that French differentiate &quot;majusculese&quot; and &quot;minuscules&quot; and even in some cases &quot;mediuscules&quot;. The latter case is the rule in France for postal addresses. Discrepancies with network addresses is something that would probably call for some serious legal review.<br>
 <br>There is a great difference in using a limited English script set as in the DNS as a technical patch, and reducing the French script set to that English script set, with all the undefined costs and confusion it would create at no identified advantage.<br>
 <br></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> Can you explain why case-*sensitivity* (as opposed to case-preserving) *in the protocol* is necessary for your purposes?</blockquote>
<div><br>No one ever talked about &quot;in the protocol&quot; but the TATWEEL proposition that france@large and ASIWG did not support and would call for the work of this WG to come to a stop (as per the Charter).<br> <br>
The Charter and every of us, I hope, agree that the protocol level MUST not affect, and MUST respect, the DNS. We are here speaking of Semantic Addresses which are not specific to the Internet and therefore belong to the &quot;user application layer&quot;. It seems that we need to be very careful in avoiding to confuse network application, interapplication and user application layers. This also determines how to support the (virtual) presentation layer.<br>
 <br>In practical terms, it only means that &quot;ABC&quot; will be not be punycoded as &quot;abc&quot;, as the current Internet default (by lack of) presentation layer does. The &quot;.fra&quot; presentation will therefore be different from the &quot;default&quot; internet presentation transparently to the DNS. Off-protocol mapping gives a full command to users over their Domain Name Applications (DNA).<br>
 <br>Best.<br><br>Elisabeth Blanconil<br><br>PS. I was busy with family business today. I hope I can have some Draft completed by Monday after-noon.<br></div></div></div></div><div class="im"> _______________________________________________<br>
Idna-update mailing list<br><a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br><a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a></div>
</blockquote></div></div></div></blockquote></div>