[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
- Subject: Re: [idn] The report from the design team
- From: "Eric A. Hall" <ehall@ehsco.com>
- Date: Tue, 13 Feb 2001 20:53:52 -0800
- Delivery-date: Tue, 13 Feb 2001 20:54:05 -0800
- Envelope-to: idn-data@psg.com
- Organization: EHS Company
> Every argument to date has been hand-waving about "software that will
> break."
My .02 to this is that I don't believe we should be requiring that a
solution make all legacy implementations forward compatibile.
Note that this is different from backwards compatible. The requirements as
stated are trying to make legacy gear forward compatibile with some future
solution. Instead, it should be focused on ensuring that whatever future
solution is chosen does not willingly break legacy equipment.
We certainly don't design RRs so that they instantly function with all
legacy equipment. We don't design ESMTP extensions so that they
immediately function with legacy mailers. Instead we design so that we
don't break legacy stuff, and then leave it up to the net admins and
operators to upgrade when the feature is important.
IMO we should be treating IDNS the same way. We are limiting ourselves by
an artifical and unreasonable restriction when we demand that all
proposals must "allow any system anywhere to resolve any internationalized
domain name." That requirement should be removed from the spec completely.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/