<br><br><div class="gmail_quote">On Mon, Jul 27, 2009 at 5:52 PM, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Jul 26, 2009 at 06:37, Yoshiro YONEYA <<a href="mailto:yone@jprs.co.jp">yone@jprs.co.jp</a>><br>
wrote:<br>
<br>
> I'm wondering if the general procedure is applied to FULL STOP<br>
characters.<br>
> For example, Unicode string (FW- stands for Full Width)<br>
<br>
</div>--On Sunday, July 26, 2009 07:52 -0700 Mark Davis ⌛<br>
<div class="im"><<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br>
<br>
> I agree that that should be done, but John Klensin was against<br>
> it. Something about not being able to recognize separate<br>
> labels (although current technology does it just fine).<br>
<br>
</div>Mark, it really is not that "I'm against it". I've just<br>
summarized, several times, some rather aggressive feedback we've<br>
gotten about the issue. To repeat that summary (in even briefer<br>
form than before), there is a fairly fundamental DNS requirement<br>
that one be able to convert labels from and to the external<br>
(label.label...) form to the internal (length-label,<br>
length-label,...) one without knowing anything about the labels<br>
themselves, even if those labels are "just octets" rather than<br>
anything that is specifically ASCII, LDH, UTF-8, etc. In other<br>
words, that conversion has to be able to be performed, not only<br>
by IDNA-aware applications, but applications that don't make any<br>
check at all about the contents of the labels.</blockquote><div><br></div><div>I have not seen your earlier messages about this issue, and cannot claim to be following this list religiously so I apologize if I'm reiterating any beaten-to-death arguments.</div>
<div><br></div><div>I can definitely sympathize about the programming side of getting things into and out of internal representation. Some questions/observations:</div><div><br></div><div><div>1. I wonder how many domain names stored (as part of URLs in bookmarks, or hyperlinks in a document) contain ideographic full-stop in the real world. My feeling is that it is only a concern at keyboard / input method time.</div>
<div><br></div></div><div>2. The protocol document mostly deals with labels, and leave the combining and splitting of labels to RFC1034/5. As such, the input to the mapping steps at lookup time is, of course, a label. Allowing it to be further split into multiple labels is asking for trouble. However, I wonder if we could not change the language or have a section in the -protocol doc to say that application (at time of user input) MAY apply some transformation to the whole "domain string"?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
As several people have pointed out, if one could somehow find a<br>
character that is not actually used in the particular script of<br>
interest and immediately map it at keyboard-> OS time into a<br>
period, there would be no problem. But that character isn't<br>
going to be on the user's keyboard, so it probably isn't a<br>
solution to any interesting problem. The difficulty with these<br>
other dot-look-alikes is that they are important for other uses<br>
in the relevant languages/scripts so that the notion of always<br>
mapping them into something else doesn't work either.<br><font class="Apple-style-span" color="#888888"></font></blockquote><div><br></div><div>Don't understand this one at all, but maybe I'm just missing contexts in your earlier messages. </div>
<div><br></div><div>=wil</div></div>