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
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
