From edmonds@mycre.ws Thu Mar 10 18:57:12 2016 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 Content-Disposition: inline X-RT-Interface: API References: <20160309205325.GA9403@mycre.ws> <20160309214631.GA25960@isc.org> <20160310001829.A32C9442E5EA@rock.dv.isc.org> <20160310015846.GA29285@isc.org> <20160310022606.411FF4430A96@rock.dv.isc.org> Message-ID: <20160310185708.GA31082@mycre.ws> content-type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by bugs.isc.org (Postfix) with ESMTP id 9B6B571B5A8 for ; Thu, 10 Mar 2016 18:57:12 +0000 (UTC) Received: from chase.mycre.ws (chase.mycre.ws [70.89.251.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "chase.mycre.ws", Issuer "mycre.ws" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 88C471FCAF2 for ; Thu, 10 Mar 2016 18:57:10 +0000 (UTC) Received: by chase.mycre.ws (Postfix, from userid 1000) id 65BAE12C1CFA; Thu, 10 Mar 2016 13:57:08 -0500 (EST) Delivered-To: bind9-bugs@bugs.isc.org Subject: Re: [ISC-Bugs #41900] Unpresentable records cause AXFR failure? Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Date: Thu, 10 Mar 2016 13:57:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.ams1.isc.org To: "Mark Andrews via RT" Content-Transfer-Encoding: 8bit From: "Robert Edmonds" RT-Message-ID: Content-Length: 1494 Hi, Mark Andrews via RT wrote: > DNS developers testing ambigious corner cases will do this but no > one else ever will. Better to test the heck out of the ambiguous corner cases than not, IMHO. I also happen to think that ambiguous corner cases shouldn't cause zone transfer failures... > The RFC itself needs to be fixed. It is self contradictory. > > One of the following needs to be changed. > > Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' > through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT > contain any other characters. Matching of tag values is case > insensitive. > > or > > Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower > case. I actually don't think these two excerpts are contradictory at all. §5.1 ("Syntax") is describing the wire format, while §5.1.1 ("Canonical Presentation Format") is describing the presentation format. The reasoning in the rejection of erratum 4061 explicitly says that they can differ. Now, I disagree with the reasoning in the rejection of erratum 4061 and it smells like a post-hoc rationalization for a dumb mistake in the spec to me, and I think RRTYPE specifications should be required to have 1-to-1 convertibility between wire formats and canonical presentation formats (i.e., without resorting to generic RFC 3597 presentation format). I don't know of any text anywhere that explicitly requires that currently, though. -- Robert Edmonds