Re: [Cbor] Multiple questions with CBOR for DNS
Martine Sophie Lenders <martine.lenders@tu-dresden.de> Fri, 10 November 2023 08:43 UTC
Return-Path: <martine.lenders@tu-dresden.de>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39282C15C283; Fri, 10 Nov 2023 00:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzwjAmWbHj1n; Fri, 10 Nov 2023 00:43:42 -0800 (PST)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4E4C16F417; Fri, 10 Nov 2023 00:43:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:CC:To :Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tpRvcyarg2pQdphzfQ+qwH/FsOz9+GJrVp+2tQZQlzg=; b=HipSoydrjRKS6jXIsCt+Nefg7d 4mgdBKdNPVoM0eqUqBuOYJD5woEYbw4tKUWrwoGX5KtWHKuWs0oqGiPvlrP8XBXDl06t2B5q1Z8cR 6OpAtXmwVQohnDkZ+NP0yCeSRS7ueQ/LYLi+ccE6VuR0MFh0snvtKgImM33OGiExw/aQqWZpZh7gS 5C7YGxHedlEtMpVmSIbTmWdfTDRhuBYIwDlijsU21g2kLokr4+V/UX7DVJkREE1CjJTB2I1PqkKTG mS0iBix83Psgce+yO/dIelWJXT8gg+fHJkgBUuoVuFu5ar510QKodKpuWCqjDsSixbp5NcGCQUJ7W 9CFButAA==;
Received: from [172.26.34.117] (helo=msx.tu-dresden.de) by mailout4.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <martine.lenders@tu-dresden.de>) id 1r1N72-005gsP-45; Fri, 10 Nov 2023 09:43:36 +0100
Received: from [31.133.128.152] (31.133.128.152) by msx-l317.msx.ad.zih.tu-dresden.de (172.26.34.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Fri, 10 Nov 2023 09:43:33 +0100
Message-ID: <14fd34aa-b9f1-4449-9331-2082052aaba4@tu-dresden.de>
Date: Fri, 10 Nov 2023 09:43:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Joe Hildebrand <hildjj@cursive.net>, Carsten Bormann <cabo@tzi.org>
CC: Esko Dijk <esko.dijk@iotconsultancy.nl>, "cbor@ietf.org" <cbor@ietf.org>, "draft-lenders-dns-cbor.authors@ietf.org" <draft-lenders-dns-cbor.authors@ietf.org>
References: <90f306d4-d887-43f6-8990-3c39a7ffcb46@tu-dresden.de> <DU0P190MB19784314798812652C9398CFFDAFA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <c36a1e19d66c40009e0abe51f9c2bcf5@msx-l317.msx.ad.zih.tu-dresden.de> <66bc2b17-888b-440e-9eae-4ea2633f157d@tu-dresden.de> <d1191e0d356248ef83c413469e025d81@msx-l317.msx.ad.zih.tu-dresden.de> <83a63ff9-e36f-4e82-918b-4294570a6598@tu-dresden.de> <4C5086F6-1B56-4428-B0B0-63DA4DFBA2BA@tzi.org> <e48d9ae3b8634c3096d7430d57a7f7e1@msx-l317.msx.ad.zih.tu-dresden.de>
From: Martine Sophie Lenders <martine.lenders@tu-dresden.de>
In-Reply-To: <e48d9ae3b8634c3096d7430d57a7f7e1@msx-l317.msx.ad.zih.tu-dresden.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms010407080302090705030702"
X-ClientProxiedBy: MSX-L311.msx.ad.zih.tu-dresden.de (172.26.34.111) To msx-l317.msx.ad.zih.tu-dresden.de (172.26.34.117)
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Z9bB4Kv78MIyiQJT97T-7MidE0k>
Subject: Re: [Cbor] Multiple questions with CBOR for DNS
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2023 08:43:46 -0000
If we make the type mandatory, it is not necessary to define it as `undefined` or `null`. Currently, it defaults to 28 (AAAA records), so if we make the type necessary it should be the according record type number. But that exactly should make clear, that we are not just adding a single byte but up to three, as the number space of record types is 1 to 65535. That said, maybe it makes sense to make the type necessary. The AAAA record type was picked as a default based on what we see on the current Internet, where address resolution types (i.e. A and AAAA records) are the most prevalent, but that might change. Will look into that. Best Martine Lenders On 09.11.23 19:38, Joe Hildebrand wrote: > Wouldn't it be easier to make type-spec mandatory for all questions, and allow `undefined` or `null` (pick one) as the type-spec? You're only adding a single byte. > > — > Joe Hildebrand > >> On Nov 9, 2023, at 8:25 AM, Carsten Bormann <cabo@tzi.org> wrote: >> >> How about: >> >> question-section = [ >> * full-question, >> ? last-question >> ] >> >> full-question = ( >> name: domain-name, >> type-spec, >> ) >> >> last-question = ( >> name: domain-name, >> ? type-spec, >> ) >> >> It is a bit hard in this form to maintain the requirement for at least one question, because if the last question is also a full question, it will be gobbled up by the `* question` part. >> (An intersection would work, but requires two parsing threads.) >> >>> In the current draft, it is not, but if we go for the name component route, it will become hard to distinguish between the name for a second question or another component of the name for the first. Just necessitating at least a type in-between the names would help with that >> >> Grüße, Carsten >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >
- [Cbor] Multiple questions with CBOR for DNS Martine Sophie Lenders
- Re: [Cbor] Multiple questions with CBOR for DNS Esko Dijk
- Re: [Cbor] Multiple questions with CBOR for DNS Carsten Bormann
- Re: [Cbor] Multiple questions with CBOR for DNS Martine Sophie Lenders
- Re: [Cbor] Multiple questions with CBOR for DNS Carsten Bormann
- Re: [Cbor] Multiple questions with CBOR for DNS Martine Sophie Lenders
- Re: [Cbor] Multiple questions with CBOR for DNS Carsten Bormann
- Re: [Cbor] Multiple questions with CBOR for DNS Joe Hildebrand
- Re: [Cbor] Multiple questions with CBOR for DNS Martine Sophie Lenders
- Re: [Cbor] Multiple questions with CBOR for DNS Carsten Bormann