[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Alternative Solutions
Actually I think there was a similar approach presented by the JPNIC team in
Pittsburgh, which proposes using the DNS server to perform canonicalization.
This can be extended to do transformation to ACE or mapping to an LDH.
However, the problem with these solutions is that we are lacing DNS with
meta-records which cause additional burden on applications as they have yet
again another layer to deal with when processing these identifiers.
Again, this makes me seriously doubt that a pretty solution to
internationalized identifiers can be found by tweaking DNS as it is.
maynar
----- Original Message -----
From: "Edmon" <edmon@neteka.com>
To: <idn@ops.ietf.org>; "Adam M. Costello" <amc@cs.berkeley.edu>
Sent: Wednesday, May 02, 2001 11:47 AM
Subject: Re: [idn] Alternative Solutions
> Extending your idea back to an algorithmic approach, we could set it so
that
> the LDH names be created using ACE and that nameservers during loading
would
> check that they are consistent with the unicode name. When the LDH
response
> is received by the DNS, it will be utilized for other protocols such as
> mail.
> Edmon
>
> > Edmon <edmon@neteka.com> wrote:
> >
> > > Server-side ACE - ACE transformation takes place at server end
> >
> > If it's on the server, it doesn't have to be an algorithmic
> > transformation; it can just be a distributed lookup table (which is what
> > DNS is anyway).
> >
> > Two new resource record types could be created, one that gives the
> > Unicode domain name associated with an LDH (letter/digit/hyphen) name,
> > and one that gives the LDH name associated with a Unicode name. This
> > is analogous to the A and PTR records that map between LDH names and IP
> > addresses in both directions.
> >
> > Example scenario: I type a Cyrillic email address into my IDN-aware
> > email program. It performs nameprep and sends the result in a DNS
> > query using a canonical encoding (UTF-16 say). It gets back both an IP
> > address (which it uses to connect to the remote SMTP server if there is
> > no MX record) and an LDH domain name. It puts the LDH name in the To:
> > field of the message header, in order to conform to RFC 822.
> >
> > Suppose the message is sent to multiple recipients. They can all reply
> > to everyone in the To: field, because the domain names there are LDH
> > names. Additionally, IDN-aware mail programs can do a DNS lookup on the
> > LDH domain names to discover the corresponding Unicode domain names, and
> > show the latter to the user.
> >
> > I don't think this requires any changes to the DNS protocol, only the
> > addition of two new resource record types.
> >
> > I don't like this idea as much as ACE, for two reasons: First, the
> > mapping between LDH names and Unicode names cannot be done offline.
> > Second, there is no guarantee that the mapping is consistent in the
> > two directions (just as there is currently no guarantee of consistency
> > between A and PTR records). It has one advantage over ACE, though: The
> > LDH names can be chosen arbitrarily, and need not look like gibberish.
> >
> > AMC
>
>