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

[Toerless Eckert <[e-mail]>]

On Mon, Aug 22, 2022 at 08:43:57PM +0200, Carsten Bormann wrote:
[... snip...]
> > 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.

I think we've got that covered in our understanding.

> So each message production should have a *grasp-really-option at the end, where that stands for an actual (registered) option.

But that would not suffice to receive and ignore an option that
was not specified in the CDDL at the time of the implementation of the
receiver.

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

Oops. typo. Thanks

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

Hah. "~" is the unravel i was asking for in my other mail. Can that be
used to do inline moficiation:

    flood-message = [ ~flood-message, *grasp-option ]

Or does that have to be a new name on the left-hand side ?

> > […]
> 
> > 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…)

Right... 

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

Yeah. Still trying to find the killer use-case of two objectives requring different
options to make that point.

Thanks
    Toerless

> 
> Grüße, Carsten
> 
> 

-- 
---
[e-mail]