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

JFC Morfin jefsey at jefsey.com
Sun Mar 22 00:23:07 CET 2009


At 17:03 21/03/2009, Lisa Dusseault wrote:
>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

John,
Basically I agree with you - however I would talk of "name layering" 
rather than "add-ons", etc. because these add_ons would interfere 
(support but not completely) with the different layers of the added 
value that can be found in naming.

Lisa,
I feel that the Charter is protecting us from the confusion coming 
from the violation of too many of these "DN layers" (IMHO there more 
of them than what is discussed here). Last June, John introduced IMHO 
the correct top boarder of IDNA definition: IDNA is concerned with 
scripts, not with languages. IDNA is a technical protocol, not a 
complex anthropomecanic language grammar.

We only need IDNA to be a way to support scripts to DNS LDH in a 
clear enough way for human (registrant) adaptations to 
language  constraints, with the possible Registry guidance 
(Registries have no control on n+2 domain name levels).

We are not interested as such in natural language issues, but in 
making sure that these natural language issues will be transitively 
(cf. infra) supportable by IDNA, and in documenting users on the way to do it.

Today, for example, French users have no way to use IDNA in a 
transitive manner. Transitive means that whatever A, A -> IDNA -> B 
makes sure that A = B. If this lack of transivity results from the 
need to also be IDNA2003 interoperable, French users having not 
implemented IDNA have no problem in dropping that specific constraint 
when building an IDNA2008 extension that will be transitive in a 
French context.


Now, the only change I would advise in the IDNA2008 current approach 
is to replace

- the registry "registration rules" approach, which may only concerns 
cooperating TLD Managers (the current worms' thread shows that this 
is not something easy to coordinate)
- with a user "syntax recipe" approach. To tell people, if they want 
a given string in a given script to transitively go through, how they 
must design the label they register. This is because IDNA does not 
belong to the DNS DN layer: it should therefore be entirely 
transparent to the DNS DN layer registries.

jfc


>On Fri, Mar 20, 2009 at 2:44 PM, John C Klensin <klensin at jck.com> wrote:
> > 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



More information about the Idna-update mailing list