From marka@isc.org Thu Mar 10 00:04:11 2016 In-Reply-To: Your message of "Wed, 09 Mar 2016 22:43:08 -0000." X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-RT-Interface: API References: <20160309205325.GA9403@mycre.ws> <20160309214631.GA25960@isc.org> <20160309221444.GA13890@mycre.ws> <20160309224307.GB25960@isc.org> content-type: text/plain; charset="utf-8" Message-ID: <20160310000405.86DF3442E3C3@rock.dv.isc.org> 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 8610671B5A8 for ; Thu, 10 Mar 2016 00:04:11 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id EDEFC1FCBC4 for ; Thu, 10 Mar 2016 00:04:08 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B9CB216008E for ; Thu, 10 Mar 2016 00:04:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9FC32160090 for ; Thu, 10 Mar 2016 00:04:07 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kBJOewS_z6sZ for ; Thu, 10 Mar 2016 00:04:07 +0000 (UTC) Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 60C2516008E for ; Thu, 10 Mar 2016 00:04:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 86DF3442E3C3 for ; Thu, 10 Mar 2016 11:04:05 +1100 (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 11:04:05 +1100 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.ams1.isc.org To: bind9-bugs@isc.org From: "Mark Andrews" RT-Message-ID: Content-Length: 1635 https://www.ietf.org/archive/id/draft-hallambaker-donotissue-04.txt This is what was used to allocate the typecode. Note the MUST NOT. Tag The property identifier, a sequence of ASCII characters. Tag values MAY contain ASCII characters a through z and the numbers 0 through 9. Tag values MUST NOT contain any other characters. Matching of tag values is case insensitive. I don't care what RFC 6844 says here. Once the code point is allocated the code point format is frozen. This is the direct result of changing the specification after the fact. The IESG should have rejected the change. There is zero need for anything other than ASCII here as it is a protocol element. RFC 6844 also has: Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. Which makes the RFC 6844 self contradictory. It is either this sequence or it isn't. Mark In message , "Evan Hunt via RT " writes: > On Wed, Mar 09, 2016 at 10:14:48PM +0000, Robert Edmonds via RT wrote: > > In the case where you have to render an unpresentable CAA record (for > > instance because you might be writing a text master file format zone to > > disk), couldn't you just fall back on RFC 3597 generic presentation > > format for the record data? E.g., > > > > caa.example. IN CAA \# 03 00 01 20 > > Very smart suggestion, thank you. > > > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=41900 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org