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

[Brian E Carpenter <[e-mail]>]

On 23-Aug-22 06:43, Carsten Bormann wrote:
>>
>> Aka: grasp-option can not represent the purely numeric ttl anymore.

That's actually a bug in the changes I was proposing. It will be
fixed but I doubt that the cbor list cares.

>>
>> We could do a one-off fix for ttl by channging message-structure, but
>> i really don't see why we would want to constrain grasp-option to be
>> less than any, see below.
> 
> Correct.
> 
> Grasp-option really is the lower layer of extensibility, which allows you to create new messages that then conform to message-structure.  These should provide maximum flexibility.
> 
> (Message should be/employ a socket, to make this extension point more visible.)
> 
> The production that is called grasp-option should not be called grasp-option, because it is not just about options, it’s all elements in a message after the common header.

Correct. Will fix.

> 
>> 2) Still want to understand .within correctly i think it does not doe
>> not work as you hope above.
>>
>> Carsten claimed offlist, that in your above syntax, grasp-option would
>> match some option that is not yet defined, as long as it matches
>> option-structure. From reading rfc8610, i think this is wrong, because
>> numeric-option is an AND between option and option-structure, so only
>> any currently defined options will be matched. No extensibility to
>> include any future options, even if they match option-structure.
> 
> I’m not sure I understand the context of this, but yes, .within is a .and.  So you have to have both message-structure accept the message and the message choice as well.
> 
> Obviously, we need a second layer of extensibility beyond adding new messages: adding new options to a message.
> 
> So each message production should have a *grasp-really-option at the end, where that stands for an actual (registered) option.

I don't really see that. But let's have that argument about a complete
updated CDDL spec, and not waste cbor@'s time.

    Brian

> 
>>
>> Of course, i can be wrong, but then rfc8610 text is really misleading.
>>
>> 3) Here is what i propose:
>>
>>
>>     grasp-option = valid-option / objective / any
>>     valid-option = option .within option-structure
> 
> (Valid-option is your grasp-really-option.)
> 
>>     option-structure = [*any]
> 
> No, an option starts with an option-type, so this should be
> 
>     option-structure = [option-type, *any]
> 
>>     option-type = uint
> 
> Yep.
> 
> 
>>
>>
>>     flood-message = [M_FLOOD, session-id, initiator, ttl,
>>                     +[objective, (locator-option / [])], *grasp-option]
> 
> Yes.
> 
>>     "All other"-message = [ ... existing definitions ..., *grasp-option]
> 
> Yes, that would be the whole-sale introduction of the second layer.
> (Grasp-really-option, actually.)
> 
> The [~message, *grasp-really-option] approach might be able to do this with fewer changes.
> 
>> […]
> 
>> We may also want to carve out ranges to indicate that an option received
>> with such a numbe,if not known to the receiver must not be ignored but
>> needs to result in an error condition.
> 
> (Negative numbers would lend themselves to this…)
> 
>> 5) M_FLOOD
>>
>> M_FLOOD still has the added issue, that it can have multiple objectives,
>> and we do not have a way to express per-objective options. Which bugs me.
> 
> … a fourth layer of extensibility…
> 
> Grüße, Carsten
> 
>