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

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
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor