On 20-Aug-22 06:56, Carsten Bormann wrote:
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
[…]
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
There is no reason to limit this to 255.
➔ EXTENSION_TYPE = uint
(Do you plan to creat a registry for these?
The 'extension_type' terminology is confusing, because these would
be new GRASP options, and they already have a registry.
grasp-extension = [ EXTENSION_TYPE, *any ]
This is of course possible.
CBOR also has tags, which might be a more natural structure.
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.
IMHO there is no need to use 'extension' at all.
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.
As I've already said off list, there is no issue in decoding because CBOR
delivers the type as well as the value. If the first item is a string, we've
found a GRASP objective. If it's an integer, we've found a numeric option.
Anything else, it's an error.
Brian
- 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]).
[1]: https://www.rfc-editor.org/rfc/rfc8610.html#appendix-A
There is no point in mixing grasp-extension up with the wild card grasp-option.
Grüße, Carsten
_______________________________________________
CBOR mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
