[Cbor] GRASP packet header extensions (CBOR question)

[Toerless Eckert <[e-mail]>]

[ Sorry for cross-post but given how this is about ANIMA GRASP, a CBOR
  protocol, i think its the best/fastest way to converge. ]

In GRASP (RFC8990] we define the GRASP message structure as follows:

message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option]

MESSAGE_TYPE = 0..255
session-id = 0..4294967295 ; up to 32 bits
grasp-option = any

Then we've defined a few MESSAGE_TYPEs of which the one we are primarily
interested in now is:

flood-message = [M_FLOOD, session-id, initiator, ttl,
                +[objective, (locator-option / [])]]

(its also the most difficult one).

objective = [ objective-name, objective-flags, loop-count, ?objective-value ]
objective-name = text
objective-value = any

[ Not official GRASP language, but i always think of the objective to be the
 payload and the rest of the message to be the GRASP header. ]

The M_FLOOD message is already something special because all other GRASP
message types we have only have at most one objective, but because M_FLOOD
multicasts the message, we wanted the optimization to send fewer multicast
packets by coalescing them (good for low-power IoT devices).

So now the question is how we want to generically as possible extend the header.
Our specific first goal is a signature extension, but hopefully we don't
need to discuss this here (in this thread), as its not a CBOR/CDDL encoding question.

Brians suggestion, if i understand him right would be something like this:

EXTENSION_TYPE = 0..255
grasp-extension = [ EXTENSION_TYPE, *any ]
grasp-option /= grasp-extension

flood-message = [M_FLOOD, session-id, initiator, ttl,
                +[objective, (locator-option / [])], *grasp-option ]

Lets look at three different messages:

  A) [M_FLOOD, session-id, initiator, ttl,
       [    [ "objective1", ...] , locator-option ], [     [ "objective2", ...], locator-option ] ]
      (A1) (A2)                                      (A3) (A4)

  B) [M_FLOOD, session-id, initiator, ttl,
       [     ["objective1", ...], locator-option ], [    115, whatever ]]
       (B1) (B2)                                   (B3)  (B4)

  C) [M_FLOOD, session-id, initiator, ttl,
       [     ["objective1", ...], locator-option ], somethingelse, [   115, whatever ]]
       (C1) (C2)                                   (C3)           (C4) (C5)
       

When receiving message A, and looking after ttl, the next element in the array, (A1)
is itself an array, AND the first element of that array is also an array, so
this can only be an objective. Likewise logic for (A3), (A4).

When receiving B), same logic for (B1), (B2), then after (B3) the check is that the first
element of the array is of type numeric (B4) instead of array, so this must be a
grasp-extension.

When receiving C), same logic for (C1), (C2), but then at (C3) the array element is
not of type array itself, so it can't contain an objective nor can it be a grasp-extension.
But it is still matching the any of grasp-option, so its still a valid M_FLOOD grasp
messages and simply needs to be ignored (maybe we later on come up with additional stuff
that wouldn't be an array... And then at (C4), (C5) the logic to recognize a 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).

- does "grasp-option /= grasp-extension" work. 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, so that we can ensure that grasp-extension is always the option
  that MUST be used if it matches - instead of any.

- So everything ok ? or any other concerns ?

Cheers
    toerless