Issues lists and the "preprocessing" topic

[Mark Davis]

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).
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 http://docs.google.com/Doc?id=dfqr8rd5_51c3nrskcx, 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.

Mark


On Wed, Aug 20, 2008 at 1:15 PM, Andrew Sullivan <ajs at commandprompt.com>wrote:

> On Wed, Aug 20, 2008 at 10:11:00AM -0700, Lisa Dusseault wrote:
>
> > sophisticated about URIs than browsers are.  Text editors, WYSIWYG
> > editors, calendar clients, IM clients, presentation authoring
> > software, file readers (like PDF readers) -- these all may present
> > URIs that users can click on and allow users to enter non-ASCII
> > characters into such URIs.
>
> This discussion strikes me as an example of the thing I was worrying
> about right after Dublin.  In the hope of trying to make clearer what
> I was yittering about that time, I'm going to try again.  I think
> there may be two cases, and some of us ("at least one" may boil down
> just to me!) may sometimes conflate them.
>
> One of these cases is what we might call "narrow IDNA context".  I
> think of this as applications using names as part of the resolution
> step of performing network operations.  In some cases, those names
> include at least one U-label.  It seems to me that addressing this
> context can be boiled down to a strict problem of what gets encoded in
> the ASCII-compatible encoding, what cases are tricky (and how to deal
> with them), and what cases simply won't be allowed at all. I believe
> some of the WG participants think this is the entire problem that the
> WG should address, and that anything else is something entirely
> outside our charter.
>
> Another case is something we might call "wide IDNA context": the way
> in which applications use U-labels, what they ought to do with them
> when handing them around, indexing them, &c.  This is not analogous to
> gethostbyname() and friends, but analogous to how traditional FQDNs,
> URIs, &c. are interpreted by network-aware (but not
> "network-competent") applications today.  I think that those who
> believe the narrow context is the only thing on charter here believe
> that all of these issues are just problems high up in the application
> space, and that they're none of our business.
>
> I think that IDNA2003 tried very hard to cleave to the narrow context,
> and left most of the issues to the application's space.  I think that
> the attempt to unhook from a specific version of Unicode can
> nevertheless be made to fit in the narrow context.  I have a sneaking
> suspicion that attempts to ensure stability with IDNA2003, and
> especially any other local mapping, is really a wide context problem.
> I'm undecided about whether wide context problems are on-charter in
> this WG.
>
> If I have completely misunderstood everything (it's not the first
> time), I'd appreciate the relevant poke in the correct direction.
>
> Best,
>
> A
>
> --
> Andrew Sullivan
> ajs at commandprompt.com
> +1 503 667 4564 x104
> http://www.commandprompt.com/
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080820/bab1fa89/attachment-0001.htm