<div dir="ltr">The direction of the IDNAbis specifications in making a clear separation between what is in the "wire protocol" and what is more free-form text that is mapped to the "wire protocol" (by casing and normalization) is good. But I agree with Erik's points the mapping is far from just a UI issue -- the mapping issue is all over the place (see previous messages).<div>
<br></div><div>Based on comments from John and others at the meeting, however, it appears that the working group is fundamentally not interested in having a common specification for a mapping phase be part of the IDNAbis, and that it would be better done by organizations like Unicode or others. Based on that, I modified the draft at <a href="http://docs.google.com/Doc?id=dfqr8rd5_51c3nrskcx" target="_blank">http://docs.google.com/Doc?id=dfqr8rd5_51c3nrskcx</a>, and submitted it to the UTC for consideration. The UTC decided at its quarterly meeting last week to post a draft specification based on that document for public review and comment. I'll post to this list when that draft is available.</div>
<div><br></div><div>Mark<br>
<br><br><div class="gmail_quote">On Wed, Aug 20, 2008 at 1:15 PM, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@commandprompt.com" target="_blank">ajs@commandprompt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Aug 20, 2008 at 10:11:00AM -0700, Lisa Dusseault wrote:<br>
<br>
> sophisticated about URIs than browsers are. Text editors, WYSIWYG<br>
> editors, calendar clients, IM clients, presentation authoring<br>
> software, file readers (like PDF readers) -- these all may present<br>
> URIs that users can click on and allow users to enter non-ASCII<br>
> characters into such URIs.<br>
<br>
</div>This discussion strikes me as an example of the thing I was worrying<br>
about right after Dublin. In the hope of trying to make clearer what<br>
I was yittering about that time, I'm going to try again. I think<br>
there may be two cases, and some of us ("at least one" may boil down<br>
just to me!) may sometimes conflate them.<br>
<br>
One of these cases is what we might call "narrow IDNA context". I<br>
think of this as applications using names as part of the resolution<br>
step of performing network operations. In some cases, those names<br>
include at least one U-label. It seems to me that addressing this<br>
context can be boiled down to a strict problem of what gets encoded in<br>
the ASCII-compatible encoding, what cases are tricky (and how to deal<br>
with them), and what cases simply won't be allowed at all. I believe<br>
some of the WG participants think this is the entire problem that the<br>
WG should address, and that anything else is something entirely<br>
outside our charter.<br>
<br>
Another case is something we might call "wide IDNA context": the way<br>
in which applications use U-labels, what they ought to do with them<br>
when handing them around, indexing them, &c. This is not analogous to<br>
gethostbyname() and friends, but analogous to how traditional FQDNs,<br>
URIs, &c. are interpreted by network-aware (but not<br>
"network-competent") applications today. I think that those who<br>
believe the narrow context is the only thing on charter here believe<br>
that all of these issues are just problems high up in the application<br>
space, and that they're none of our business.<br>
<br>
I think that IDNA2003 tried very hard to cleave to the narrow context,<br>
and left most of the issues to the application's space. I think that<br>
the attempt to unhook from a specific version of Unicode can<br>
nevertheless be made to fit in the narrow context. I have a sneaking<br>
suspicion that attempts to ensure stability with IDNA2003, and<br>
especially any other local mapping, is really a wide context problem.<br>
I'm undecided about whether wide context problems are on-charter in<br>
this WG.<br>
<br>
If I have completely misunderstood everything (it's not the first<br>
time), I'd appreciate the relevant poke in the correct direction.<br>
<br>
Best,<br>
<br>
A<br>
<font color="#888888"><br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@commandprompt.com" target="_blank">ajs@commandprompt.com</a><br>
+1 503 667 4564 x104<br>
<a href="http://www.commandprompt.com/" target="_blank">http://www.commandprompt.com/</a><br>
</font><div><div></div><div>_______________________________________________<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><br>
</div></div></blockquote></div><br></div></div>