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

[Carsten Bormann <[e-mail]>]

> 
> Aka: grasp-option can not represent the purely numeric ttl anymore.
> 
> 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.

> 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.


> 
> 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