Re: [Cbor] Multiple questions with CBOR for DNS

[Martine Sophie Lenders <[e-mail]>]

Hi Carsten, Esko,

On 09.11.23 14:44, Esko Dijk wrote:
 > […]
 >
 > So ideally we constrain our CBOR format here to 0 or 1 questions, 
which it can efficiently encode, while keeping some extension option 
open to - in the future, if really needed - be able to add questions. 
So that older versions of a CBOR DNS parser would just ignore the 
additional questions.
 > This may be done via a CBOR tag, or some extra (reserved) items that 
can be added later in a CBOR list; so that we don’t burden today's 
format with extra structure or extra bytes just to support the 
multi-question case.
 > It's a bit like being able to add an "extension" to the format for 
the rare cases that it would be needed as discussed for the CRI format 
in CoRE.
 >
 > Nit in the document: the section 8.2.1 section header should have a 
'+' in it :)
 >

Fixed in Editor's Copy on GitHub.

On 09.11.23 15:18, Carsten Bormann wrote:
> Hi Esko,
> 
>> question-section = [question+]
>>      question = (
>>        name: domain-name,
>>        ? type-spec,
>>      )
> 
> The “+” here actually can be efficiently implemented, as long as domain-name and type-spec don’t overlap.

That raises two questions to me:

(1) Can the necessity of type-spec when the number of `question`s is >1 
somehow expressed in CDDL?
(2) Does CDDL support the extension of rules in a separate document 
(e.g., an update RFC)? This probably goes into a wider discussion. We 
were thinking about this in a different context, where a collegue needed 
to extend the DNS+CBOR format for their own purposes. In a manner which 
should probably not and was never supposed to be covered by the general 
case presented in our draft. Another use case for rule extension in the 
DNS+CBOR scope could be new, future resource record types that could 
benefit from a dedicated format (like we did with `opt-rr`) and need to 
extend the `rr` rule.

> So we can define the question-section to be extensible to multiple questions without additional encoding cost.
> Whether people implement this in the DNS servers of course is a different question.
> 
> Grüße, Carsten

Best
Martine


> 
>