CoAP size2 and Etag support

[bergzand]

Description

Now that we have Block2 support for Nanocoap merged, I was thinking about expanding this to size2 and Etag support. They complement the block2 options nicely. My first question here is if this is still within the goals of Nanocoap or that this should be a gcoap only thing.

When all data already has to be added to a buffer via the block2 calls (instead of the direct memcpy to buffer), it is easy to calculate a size2 option and an etag option value calculated via $MECHANISM. Both of these options have to be updated after the full payload is known, similar to how the more bit from the block2 option is handled at the moment.

My ideas so far are:

1. Add them as a submodule to Nanocoap as always on when compiled in, every handler that is block2 also gets an etag and size2 slapped on it.

2. Expand the coap_resource_t struct with flags to indicate special processing. an unset flag must never change the behaviour otherwise it would cause an api change. The advantage is that we can easily flag certain handlers to include the etag and/or the size2 option without having to modify the handlers themselves

3. Modify the handlers on a case by case basis, for example by adding flags and the necessary data to the nanocoap_block_slicer_t struct and reuse it for the etag and size2 options. Of course, only adding this based on an enabled submodule is trivial.

What I like to know is how you think about this.

Useful links

https://tools.ietf.org/html/rfc7959#section-4
https://tools.ietf.org/html/rfc7252#section-5.10.6

[kaspar030]

My first question here is if this is still within the goals of Nanocoap or that this should be a gcoap only thing.

Anything optional is very welcome in nanocoap. :)

[kb2ma]

I agree that addition of ETag and SizeN options is valuable. I also think it's worthwhile to think of a low impact way to add this to nanocoap. Give me a few days to think this through.

I will think of this in the context of how Block1 and Block2 are presently implemented and opportunities for refactoring.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.