Re: [idn] Alternative Solutions

["Edmon" <edmon@neteka.com>]

>From my understanding, the Walid Patent states that the method is
1. intercept multilingual request
2. convert multilingual characters into LDH
3. resolve using LDH

which means using a client or proxy to intercept and convert before sending
LDH to DNS.  ACEing mutlilingual characters is not part of the patent if it
is not done during DNS request.

my suggestion below should have no conflict with the Walid Patent
1. there is no interception -- requests are sent and responded to as is
2. there are no conversion -- additional record contains LDH which could be
used
3. resolution depends on the UTF characters

It gives us the benefit of working with ACE
- alphanumeric could be typed by admins or other people who wish to contact
the domain using its LDH form
- other protocols and apps could use LDH
- mode bit response could be introduced to other protocols as needed (if
apps need to upgrade for display of ACE, then they might as well upgrade for
the mode bit, while in the intermediary, they can use the LDH)
and avoids the Walid Patent

Edmon




> What about this:
> since for IDNA we assume that there needs to be a client upgrade anyway,
> adding more stuff should be ok.
>
> - client sends DNS request with mode bit in UTF
> - Server returns UTF=A/A6/MX, etc AND UTF=LDH(in an ACE)
> - client then chooses to use straight UTF or LDH info when using DNS info
in
> other apps
>   based on - if the other app is IDN aware, it uses UTF with mode bit
>                  - if the other app is nonIDN aware, it uses LDH in ACE
>
> This gives us the benefits of ACE being able to be used for other
protocols
> which are not upgraded yet and also provides a clear path foward towards a
> UTF+mode bit longer term solution.
>
> Edmon
>
>
> > > >> Server-side ACE - ACE transformation takes place at server end
> > > >
> > > > even if you set up another way to do queries for IDNs
> > > > (whether this is a separate protocol or a mode bit or whatever)
> > > > you still need ACE for client protocols that only support ASCII
> > > > names.
> > >
> > > Unless we go either into a new class (or some EDNS-required
> > > mechanism) that prevents an "international" name from being seen,
> > > and an "international" query from being made, except by IDN-aware
> > > applications.
> >
> > *AND* we insist that "international" names are never leaked
> > *by any protocol* (including, say, SMTP) to an application that
> > doesn't understand them.  In practice this means not just a mode
> > bit for DNS but also a mode bit for every protocol that carries
> > DNS names.
> >
> > which doesn't seem like a very attractive path to me.
> >
> > Keith
>