Re: [idn] Why follow IDNA with UTF-8?

["Eric A. Hall" <ehall@ehsco.com>]

Paul Hoffman / IMC wrote:
> 
> At 11:36 AM -0500 7/15/01, Eric A. Hall wrote:
> >Let me expand on this by saying that any application which supports
> >version negotiation is a candidate for UTF8 migration.
> 
> Not unless there is a possible need for that migration. And, again,
> you have not shown even a single example of that possible need.

I do not assume that I can predict all possible uses of inline UTF8 data.
What I do know is that people will not want ACE in their soup.

If you are only wanting one possible example, think of a protocol for
replicating mail-routing maps. Wouldn't it be beneficial for the admins of
the affected mail servers to have a common format for that data? Wouldn't
it make sense to use UTF8 for the IDNs in the router maps, given its
usability with multiple languages? Furthermore, wouldn't it be beneficial
if the data and the IDN protocol both used the same encodings? How would
it benefit anybody to manage ACE-encoded lists of mail domains? How would
it benefit anybody to replicate a UTF8 list that had to be converted into
ACE for pre-processing? If UTF8 were available for the list contents and
the pre-processing, wouldn't it that be beneficial to the users?

Clearly there are natural benefits to using UTF8 everywhere. Providing
access to UTF8 (whether with this mechanism or some other) allows for
greater levels of functionality, servicability and usability.

> >It's not a different DNS. I don't know why you're saying that. The
> >same authoritative servers and the same zone data is being used.
> >What is different about it?
> 
> It uses a different part of the DNS protocol, namely the marking of
> the UTF-8 requests and responses. We are talking about *protocols*
> here, not file formats.

By this argument, every RR represents a different DNS.

> >  New protocols are already required to use ISO-10646 for charsets,
> 
> That statement is incorrect. BCP 18 says ...

I was referring to RFC2130.

As to the other comments following this, all I will say is that I was
referring to the commentary provided in RFC2130. I was not intending to
insult anybody, and if anybody was offended by any misrepresentation or
misintepretation, I apologize for the brush.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/