Re: TKEY compatibility problems
"D. J. Bernstein" <djb@cr.yp.to> Wed, 18 July 2001 13:32 UTC
Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21602 for <dnsext-archive@lists.ietf.org>; Wed, 18 Jul 2001 09:32:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mqk1-000IqU-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 05:47:49 -0700
Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Mqk0-000Ine-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 05:47:48 -0700
Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MqjV-0000M2-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 08:47:17 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: "D. J. Bernstein" <djb@cr.yp.to>
To: namedroppers@ops.ietf.org
Subject: Re: TKEY compatibility problems
References: <E15LHAw-0007rZ-00@psg.com> <E15KpfA-000ISO-00@psg.com> <E15LDdz-0002Xy-00@psg.com> <E15LHAw-0007rZ-00@psg.com> <E15LpAZ-000Ctn-00@psg.com> <E15MbJe-00056a-00@psg.com> <E15McKa-0007HP-00@psg.com> <E15Mek4-000CbU-00@psg.com> <E15MgGn-000GQ6-00@psg.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15Mqk1-000IqU-00@psg.com>
Date: Wed, 18 Jul 2001 05:47:49 -0700
Content-Transfer-Encoding: 7bit
Kevin Darcy writes: > It also bewilders me somewhat Does it bewilder you that---to take a provocative example---RFC 2821 clearly prohibits SMTP clients from sending non-ASCII header bytes, but clearly allows SMTP servers to accept those bytes? > that Dan can *agree* that it's illegal for a > server to *send* zone data in non-Answer sections of an AXFR, AXFR server implementors have to stick to the answer section for interoperability with BIND. Anything else would be a disaster. > but at the same time argue that an AXFR client can *accept* it there. That works just fine. There's no interoperability problem. The TKEY discussion is about certain nonexistent types of TKEY servers that also wouldn't work with existing caches. Those servers have to be prohibited, not merely discouraged. > If protocol-extension records can > appear in the Additional Section of responses to regular queries, Unextended caches that obey the RFC 1034, RFC 1035, and RFC 1123 rules, such as my cache and the BIND 9 cache, will treat those as normal records. If the protocol extension has a problem with this, as TKEY does, then the extension is broken. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
- Re: TKEY compatibility problems D. J. Bernstein
- Re: TKEY compatibility problems Robert Elz