Re: [DNSOP] DNS-in-JSON draft

"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 21 September 2016 18:29 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B6212B91A for <dnsop@ietfa.amsl.com>; Wed, 21 Sep 2016 11:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHmrOJcbqBhN for <dnsop@ietfa.amsl.com>; Wed, 21 Sep 2016 11:29:19 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C59912B825 for <dnsop@ietf.org>; Wed, 21 Sep 2016 11:29:19 -0700 (PDT)
Received: from [10.32.60.158] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u8LITFEB032756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Sep 2016 11:29:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.158]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Shane Kerr" <shane@time-travellers.org>
Date: Wed, 21 Sep 2016 11:29:15 -0700
Message-ID: <0D9FCC70-45CB-43EB-90E5-F02924ADE512@vpnc.org>
In-Reply-To: <20160906124448.2c66cf2a@pallas.home.time-travellers.org>
References: <DB336274-A631-471E-8277-D6690A87C834@vpnc.org> <20160905154737.5a1c67e5@pallas.home.time-travellers.org> <EC47A7C8-56E3-4891-8F12-73617AE566C4@vpnc.org> <20160906124448.2c66cf2a@pallas.home.time-travellers.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/buBQgpfANN5xKgBzpn70jdv29iI>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] DNS-in-JSON draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 18:29:20 -0000

On 5 Sep 2016, at 21:44, Shane Kerr wrote:

>>> First, it seems like it might be nice to have a way to express RDATA
>>> in
>>> DNS presentation format. The document is very clear that no way is
>>> provided for this, but it seems like it would be really, really
>>> useful.
>>
>> If it useful for a particular application for particular RDATA, that
>> application could easily specify a format in its profile. If that
>> catches on, I could update this document with a collection of those. 
>> But
>> I don't want to start now by specifying the formats I would want 
>> myself.
>
> Hm... I guess I don't see why the DNS-in-JSON draft can't simply say
> that the formats are those documented in the RFC for any particular
> RTYPE? Each RTYPE has a defined format, right?

Sure, but some of those types don't have definitions of names for the 
presentation format, and some of the early ones have less-than-clear 
names. Also, for RTYPEs that have multiple parts to the RDATA, what 
would it mean to get an answer that had only some of them?

>
>>> Next, is compressedNAME likely to be useful? I'm not arguing 
>>> strongly
>>> against it, but since it involves pointers and those are not going 
>>> to
>>> be useful with a JSON object, I don't really see much point.
>>
>> I doubt they will be that useful, but a receiver might want to know
>> which names in a message were compressed and which were not. I admit
>> that it would be clearer for that receiver to just look through the
>> message or section binary fields.
>
> Maybe it could be a value that describes something like this:
>
> "compressedNAME": { "isCompressed": "yes", "length": 7 }
>
> The "length" would be the compressed length. The uncompressed length
> can be found by looking at the name.

Good suggestion!

>>> I don't see any mention of whether things like TYPEname and 
>>> CLASSname
>>> are case-sensitive and if they are not which case they should be. My
>>> recommendation would be to make them case-insensitive, although not
>>> every field can be so having to tag each might be a bit much?
>>
>> Well, this brought up an ugly problem. The name in the IANA registry 
>> for
>> class 1 is "Internet (IN)". Chaos and Hesiod are similarly bad. I'm
>> going to change the definition of the class names to be 'String whose
>> value is "IN", "CH", "HS", or has the format in {{RFC3597}}'. I don't
>> think I really need to add to TYPEs that the name is case-sensitive,
>> since it says "from the IANA RR TYPEs registry".
>
> Makes sense. Stupid DNS classes. :)
>
> Can you explicitly say that TYPEs are case-INsensitive then? It might
> save some poor coder at some point, since programming languages
> generally default to case-sensitive comparisons...

No, but I will say the opposite, which is more deterministic for 
receivers.

--Paul Hoffman