Re: [idn] Alternative Solutions

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

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