Basic IDN assumptions (was: Re: The Future of IDNA)

[Lisa Dusseault]

Yes, this helps.  I think we were just drawing the lines of what is
"in" IDNA differently.  I was thinking of the whole system as part of
IDNA, though of course we aren't chartered  to do any HTTP or email
work right now (or even URIs/IRIs, badly as that seems to be needed)

Lisa

On Fri, Mar 20, 2009 at 2:44 PM, John C Klensin <klensin at jck.com> wrote:
>
>
> --On Friday, March 20, 2009 09:40 -0700 Lisa Dusseault
> <lisa.dusseault at gmail.com> wrote:
>
>> Hi John,
>>
>> On Thu, Mar 19, 2009 at 10:37 PM, John C Klensin
>> <klensin at jck.com> wrote:
>>
>>>
>>> (3)  Whatever one does with IDNA, it can't be protocol
>>> specific, optimized to work with the web and less
>>> satisfactory, or relying on different mechanisms, for other
>>> applications.
>
>> You identify this as a basic assumption.  Can you elaborate?
>
> >From your comments below, I obviously was not specific and/or
> clear enough.  I hope that what follows will help.  First, let
> me try to restate the above...
>
> IDNA is designed as a DNS add-on to permit internationalization.
> As a DNS add-on, IDNA (with a given prefix, whatever that is)
> cannot have different interpretation rules for labels that
> depend on the applications that they are called from, nor can
> the DNS detect the application protocol that is asking a
> question.
>
> None of that prevents some piece of application-type-specific
> protocol between an application and whatever reaches IDNA from
> handling _its_ input in ways that are different from the way a
> different application might do it as long as what goes into or
> comes out of IDNA is constant.
>
> It was exactly that option that caused me to start thinking
> about the IRI -> URI interface.   Even if the URI -> IDNA
> interface was protocol-independent and either closely tied to
> IDNA's specifications or using A-labels exclusively and
> therefore not invoking IDNA directly at all (not actually
> necessary, but probably desirable), one could, in principle,
> redefine the IRI-> URI interface to be protocol-dependent and,
> in particular, do different types of mappings for, e.g., "http"
> and "mail" protocol types.
>
> Whether that would be wise or not is a separate question but it
> is clear to me that, architecturally, it would be possible to do
> things with specific protocols at that layer that are not
> possible with IDNA itself (partially because an IRI-> URI
> interface is able to know what the protocol is in a way that
> IDNA-> DNS interfaces are not).
>
> Now...
>
>> HTTP is special due to its scale, dependence on URLs in HTML,
>> its server control over display.  Email and, to a lesser
>> extent, any popular federated communication tool, is special
>> too -- getting so many new domains in address headers from one
>> home server that accepts message delivery.
>
> Right.
>
>> Why couldn't we do addons to the Web or email infrastructure
>> that helped users deal with IDNAs?  Isn't that kind of work
>> very likely at some point -- e.g. how to do searches and
>> filters on an IMAP server where IDNA hostnames might appear in
>> addresses?
>
> Indeed.  I've been thinking about doing those operations a
> fractional layer or two below what the paragraph above suggests
> to me, but my point was "not in IDNA" not "not at all".    My
> conceptual model at the moment is that we have, approximately....
>
>  Actual application (web browsers, email clients,...)
>  *  -> Application protocols and data formats
>  *           (HTTP, SMTP, HTML, XML, Mail Format stuff)
>  *     -> Application-facing (and internationalized)
>  *           identifiers (presumably IRIs)
>  *        -> IRI-URI decoder
>  *        -> Network-facing identifiers (URIs)
>  *           -> URI decoder
>  *           -> IDNA
>  *           -> DNS
>
> What I was thinking about was trying to redraw that picture so
> that the bottom four categories would, in terms of information
> refinement, be...
>
>  *     -> Application-facing (and internationalized)
>  *           identifiers (presumably IRIs)
>  *        -> IRI-IDNA interface
>  *           -> IRI-URI decoder
>  *           -> IDNA
>  *           -> Network-facing identifiers (URIs)
>  *               -> URI decoder
>  *               -> DNS
>
> with the IRI-> IDNA interface doing protocol-specific operations
> before calling on IDNA and then passing A-labels into the URIs.
>
> You can draw the pictures in many other ways, probably more
> clearly, but perhaps that makes the general idea clear (and it
> is strictly a general idea, not a proposal).
>
> More important, what I was trying to say is that the part of
> this that is identified in both pictures above as "IDNA" cannot
> be protocol-dependent, any more than the part that is labeled
> "DNS" can.
>
>> Further, the kinds of things we might imagine doing in Web
>> server info files or in IMAP searches might have an effect on
>> what we do in IDNA now.
>
> While I agree in practice, that is a topic I'm trying to steer
> away from just because, if we block IDNA while we are imagining,
> the degree to which we have been bogged down for the last year
> will look really speedy.  I'm pretty sure you didn't intend
> that, but some of the postings from others have seemed to lead
> in that direction.
>
>> I wonder if the confusion is in "whatever one does with IDNA",
>> if you mean something specific with that or really "whatever".
>
> Something very specific to what is done inside the IDNA protocol
> itself.
>
> Does that help?
>
>     john
>
>