[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] The report from the design team
- To: idn@ops.ietf.org, "D. J. Bernstein" <djb@cr.yp.to>
- Subject: Re: [idn] The report from the design team
- From: Marc Tamsky <tamsky@www.tv>
- Date: 13 Feb 2001 20:13:59 -0800
- Delivery-date: Tue, 13 Feb 2001 20:14:48 -0800
- Envelope-to: idn-data@psg.com
>>>>> On 15 Jan 2001 11:56:15 -0000, "D. J. Bernstein" <djb@cr.yp.to> said:
>> The application-only solutions proposed are clearly easier to
>> implement than the infrastructure solutions,
> I don't believe you. We need facts about the actual deployment costs,
> not buzzwords like ``application-only.''
> I've started a web page at http://cr.yp.to/proto/idn.html to tally the
> costs of the proposals. Specific contributions are welcome.
>> However, we cannot simply put binary characters into the current DNS
>> without breaking many protocols and many DNS servers.
> Give us the details. Exactly which pieces of software break, and how?
I concur with Dan's line of questioning here.
Every argument to date has been hand-waving about "software that will
break."
Which pieces of software, that use what protocols will break when
UTF-8 appears in DNS RR?
How do they break?
Is the author/company still maintaining it?
Is it known how easy it is to work a fix?
Has a fix been published?
Is it an input system problem?
Does it depend on the OS resolver getting changed?
More of these questions need to be identified and cataloged. Only
then can anyone say with some basis in fact, and not conjecture, that
one proposal creates more or less work than another.
Today, if those same "broken" pieces of software were to be fed
non-RFC DNS information and they crash, wouldn't that be material for
a new or existing CERT advisory? (DOS vulnerability, host compromise
come to mind.)
Marc.