<br>Mark<br><br>On Thu, Apr 2, 2009 at 07:45, Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>> wrote:<br>> mark, my point was that under the rules of IDN, you can convert from A-Label<br>> to U-label with assurance of precision. So you can cater to human<br>
> readability. Storing in U-label for doesn't work for non-IDN aware<br>> applications and might even confuse them. This is a presentation issue<br>> surely?<br><br>\x{49}\x{20}\x{63}\x{6F}\x{75}\x{6C}\x{64}\x{20}\x{77}\x{72}\x{69}\x{74}\x{65}\x{20}\x{74}\x{68}\x{69}\x{73}\x{20}\x{69}\x{6E}\x{20}\x{68}\x{65}\x{78}\x{20}\x{63}\x{6F}\x{64}\x{65}\x{73}\x{2E} (I could write this in hex codes.) Using those hex codes is just a presentation issue as well; but what is best for storage depends on the context.<br>
<br>We all agree that A-Labels and U-Labels are equivalent. And clearly you have to convert to A-Labels before doing a DNS lookup. But up until that point, it is an open issue as to what makes more sense for particular implemenations. For data that might be fed directly to an IDNA unaware application, A-Label is clearly the best. For the database example, on the other hand, it makes no sense to store an A-Label -- it just makes every level of interaction more complicated than it need be; a U-Label is best for storage. It just needs to be converted to an A-Label at some time before a DNS lookup.<br>
<br>So I think the most we can say in the document is something like: <br><br><div style="margin-left: 40px;">Implementations SHOULD store A-Labels or U-Labels, and SHOULD NOT store M-Labels. Where the stored labels are to be channeled unaltered to IDNA-unaware implementations, the storage SHOULD be A-Labels.<br>
</div><br>While that needs some wordsmithing, does the direction work for you?<br><br>><br>> v<br>><br>><br>> Vint Cerf<br>> Google<br>> 1818 Library Street, Suite 400<br>> Reston, VA 20190<br>> 202-370-5637<br>
> <a href="mailto:vint@google.com">vint@google.com</a><br>><br>><br>><br>><br>> On Apr 2, 2009, at 10:33 AM, Mark Davis wrote:<br>><br>>> I think the main storage benefits are human readability. It is much<br>
>> easier to read:<br>>><br>>> href="<a href="http://xn--mxabir3a6f.el">http://εύβοια.el</a>"<br>>> rather than<br>>> href="<a href="http://xn--mxabir3a6f.el">http://xn--mxabir3a6f.el</a>"<br>
>><br>>> or in some XML:<br>>><br>>> <url><a href="http://xn--mxabir3a6f.el">http://εύβοια.el</a></url><br>>> rather than<br>>> <url><a href="http://xn--mxabir3a6f.el">http://xn--mxabir3a6f.el</a></url><br>
>><br>>> But there are other issues: URL's are stored all over the place. If I<br>>> have one in an SQL database, I want to be able to do a SELECT Data<br>>> WHERE Url LIKE '<a href="http://xn--mxabir3a6f">http://εύβοια</a>%' and not '<a href="http://xn--mxabir3a6f">http://xn--mxabir3a6f</a>%'.<br>
>><br>>> And there are formal problems, because substrings in Unicode space<br>>> don't match substrings in PunyCode space. that if my URL were<br>>> "<a href="http://xn----vlbedmcdb5a7bjigbc9jyd.el">http://εύβοια-ξενοδοχείο.el</a>" (a made up example), then its A-Label<br>
>> form is "<a href="http://xn----vlbedmcdb5a7bjigbc9jyd.el">http://xn----vlbedmcdb5a7bjigbc9jyd.el</a>". The SELECT of<br>>> '<a href="http://xn--mxabir3a6f">http://xn--mxabir3a6f</a>%' would fail. Moreover, Url LIKE<br>
>> 'xn--mxabir3a6f%' can even return false results, strings whose U-Label<br>>> doesn't start with '<a href="http://xn--mxabir3a6f">http://εύβοια</a>%'<br>>><br>>> Mark<br>>><br>
>> On Thu, Apr 2, 2009 at 05:50, Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>> wrote:<br>>>><br>>>> Martin,<br>>>><br>>>> I continue to be somewhat confused by logic that suggests that storage<br>
>>> benefits from being in the U-label form. A-labels are almost de facto<br>>>> normative since they work withIDN-aware and IDN-unaware appllications.<br>>>> IDN-aware applications should be able to generate the corresponding U-label<br>
>>> for presentation. IdN-unaware applications. Won't even recognize a U-label<br>>>> domain name as valid IWoild think. Consequently, storage in A-label form<br>>>> seems the rational choice. If you disagree, it must be because you see a<br>
>>> flaw in the reasoning above. Can you clarify? V<br>>>><br>>>> ----- Original Message -----<br>>>> From: <a href="mailto:idna-update-bounces@alvestrand.no">idna-update-bounces@alvestrand.no</a><br>
>>> <<a href="mailto:idna-update-bounces@alvestrand.no">idna-update-bounces@alvestrand.no</a>><br>>>> To: Harald Alvestrand <<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>><br>
>>> Cc: Andrew Sullivan <<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a>>; <a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a><br>>>> <<a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>><br>
>>> Sent: Thu Apr 02 03:37:30 2009<br>>>> Subject: Re: Touchstones for "Mapping"<br>>>><br>>>> There are two sides here, the protocol correctness and<br>>>> the content correctness. By content correctness, I mean<br>
>>> whether the link e.g. goes to the intended page.<br>>>> Completely impossible to check with punycode, of course.<br>>>><br>>>> Regards, Martin.<br>>>><br>>>> On 2009/04/02 16:56, Harald Alvestrand wrote:<br>
>>>><br>>>>> Martin J. Dürst wrote:<br>>>>>><br>>>>>> I very much agree with Harald. We are working on IDNs because we want<br>>>>>> humans to be able to easily read domain names in their script. Storing<br>
>>>>> them as A-Labels when there is a reasonable chance that humans will<br>>>>>> have a look at them (e.g. in HTML or XML source, email source,...)<br>>>>>> is against the very intent of IDNs. Authors are humans, too, even<br>
>>>>> if they work on plain text :-!<br>>>>><br>>>>> I can argue the other side of the argument for HTML and XML, though.....<br>>>>> the main thing being that humans who *enter* IDNs in Unicode form<br>
>>>> without the benefit of conformance-enforcing software interfaces will<br>>>>> just about always get them wrong (due to bizarrities of case,<br>>>>> compatibility characters and other weirdnesses).<br>
>>>><br>>>>> If they enter A-labels by hand, it's pretty certain they've<br>>>>> cut-and-pasted them.<br>>>>><br>>>>> Harald<br>>>>><br>
>>>><br>>>>> _______________________________________________<br>>>>> Idna-update mailing list<br>>>>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
>>>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>>>>><br>>>><br>>>> --<br>>>> #-# Martin J.Dürst, Professor, Aoyama Gakuin University<br>
>>> #-# <a href="http://www.sw.it.aoyama.ac.jp">http://www.sw.it.aoyama.ac.jp</a> mailto:<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a><br>>>> _______________________________________________<br>
>>> Idna-update mailing list<br>>>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>>>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
>>> _______________________________________________<br>>>> Idna-update mailing list<br>>>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>>>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
>>><br>>> _______________________________________________<br>>> Idna-update mailing list<br>>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
><br>><br><br>