[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] Re: comment on the TRACE



> Edmon,
>
> From: "Edmon" <edmon@neteka.com>
> Subject: Re: [idn] NSI whitepaper on ML Resolution
> Date: Wed, 13 Dec 2000 15:14:15 -0500
>
> > I would really like to hear some comments on the TRACE-CNAME approach.

Its great to hear some comments...

>
> My understanding about TRACE is that TRACE is not an ACE. Because,
>
> - the prefix of TRACE, 0x7f, is a control character, not an ASCII.
>   (I wonder how users can input the prefix. One of the important
>    benefit of ACE is anyone can input it by typing or cut and paste.)
>   ASCII in IDN manner is characters allowed in STD13.
> - using non-ASCII characters on DNS needs update of DNS servers.
>
TRACE is purely a server end ACE implementation.  If the query is
transported to the server in ACE, then there is no problem.  The 0x7f is
only used in the zonefile and BIND already supports the use of \127 input.
But disallowing an average user to type it in brings good benefit as I have
explained about the registration and cybersquatting issues.

> So, I think you have to have transition strategy from ACE to TRACE
> before transit from TRACE to UTF-8.  Isn't it an overhead?
>

Again, TRACE is not a new protocol or ACE scheme, it is meant to be a
specification for the deployment of ACE schemes for the server end to take
care of requests that are sent in through non-ACE-compliant client
applications.  These requests will no doubt be received as we transition
into ACE, cause not everyone in the world will switch their applications
right away.


Edmon


> --
> Yoshiro YONEYA <yone@po.ntts.co.jp>
>            aka <yone@nic.ad.jp


____________NetZero Free Internet Access and Email_________
Download Now     http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___________________________________________________________