On 13-Dec-20 13:05, Michael Richardson wrote:
>
> GRASP objectives look like:
>
> objective = [objective-name, objective-flags, loop-count, ?objective-value]
> objective-name = text ;see section "Format of Objective Options"
> objective-flags = uint .bits objective-flag
> loop-count = 0..255
>
> so, ['string', uint, uint, otherstuff]
>
> There can be an array of objectives.
Right, but only in an M_FLOOD message at present. Of course, we could
in theory add other message formats with multiple objectives.
> If any of the objectives do not match the above CDDL, what do I do?
A related question was raised on the API draft by Ben Kaduk: how do we
apply the (new) recommendations on CBOR validation in RFC8949?
> Options are:
> 1) throw away that objective and move on to the others, which maybe
> look right?
I would say that by the nature of M_FLOOD, that is the logically
correct approach.
> 2) throw away the entire message.
>
> (2) is certainly easier to code.
Each objective is a self-contained CBOR array, so could
be parsed quite independently of the others.
[pause to glance at my code]
However, I did do it the lazy way, i.e. the parsing loop exits
on the first error. (If you look at my code, that's in the
elif ... M_FLOOD case inside _parse_msg().)
It would indeed be a little more work to skip the faulty objectives
and process the valid ones. I probably should add that to my
code since it would be useful for debugging.
> (1) seems way more future proof.
It depends on whether you prefer the Postel principle or
draft-iab-use-it-or-lose-it.
Regards
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
