Re: [Cbor] GRASP packet header extensions (CBOR question)

[Toerless Eckert <[e-mail]>]

On Fri, Aug 19, 2022 at 08:56:35PM +0200, Carsten Bormann wrote:
> > EXTENSION_TYPE = 0..255
> 
> There is no reason to limit this to 255.

Agreed. I just copied from MESSAGE_TYPE in GRASP.

> ➔ EXTENSION_TYPE = uint
> 
> (Do you plan to creat a registry for these?

Probably we should. Typical subdivision into stds. action, FCFS and experimental use at your own risk ranges..

> > grasp-extension = [ EXTENSION_TYPE, *any ]
> 
> This is of course possible.
> CBOR also has tags, which might be a more natural structure.

Right. Wonder what the difference would be.

> > grasp-option /= grasp-extension
> 
> This doesn’t make sense: grasp-option already is any, so adding alternatives is not going to have any effect.
> Why are you using grasp-option here in any case?
> You should be using your grasp-extension right away.

Right. I bring this up as a question at the end

> > flood-message = [M_FLOOD, session-id, initiator, ttl,
> >                +[objective, (locator-option / [])], *grasp-option ]
> 
> ➔ flood-message = [M_FLOOD, session-id, initiator, ttl,
>                +[objective, (locator-option / [])], *grasp-extension ]
> > […]
> > Questions:
> > 
> > - Is it ok. to expect the analysis to have to do two steps (e.g.: A1, A2 or B3, B4)
> >  to decide whats' next (i called that lookahead in another mail thread).
> 
> I don’t understand the question.  To find the end of +[objective, …], you look for the first element of the [M_FLOOD, …] array that doesn’t match the structure [[text…]…] that each of +[objective…] resolves to.

That pretty much what i was trying to detail in my explanation.
Aka: Do wee consider it to be "ok" to to a "doesn’t match the structure [[text…]…] "
as you so nicely summarize.

Aka: What type of matches do we think is not too complex (lookahead or whatever one wants to call it).

> > - does "grasp-option /= grasp-extension" work.
> 
> It sure “works”, but doesn’t do anything.
> 
> > I ask because previously grasp-option
> >  was "any", so logically i am not sure if CDDL expect to pick the alternative that
> >  is more specific,
> 
> No; choices are tried in sequence (“prioritized choice" [1]).

Ah!. So i would have to write:

  grasp-option = grasp-extension / any

I was afraid i would have to find a pattern that represents any without grasp-extension..

> There is no point in mixing grasp-extension up with the wild card grasp-option.

But how then would i be able to define my example C), where i have an unknown (any) list
element, and i want to make it clear in CBOR that that is still a valid M_FLOOD message,
even though there are list element(s) that are neither objectives nor well-defined extensions -
but just some stuff someone in a future spec did introduce.

Cheers
    Toerless

> Grüße, Carsten
> 

-- 
---
[e-mail]