-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, September 21, 2016 3:33 AM
To: Gomes, Vinicius <vinicius.gomes(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: zoap architecture question...

Hi Vinicius

On 20 September 2016 at 15:03, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> wrote:

Just a little background: when I wrote sol-coap, for the Soletta
project, I took the opposite way, I tried to handle everything inside
sol-coap. In the end, some users were coding around some of the
"features".

zoap, for now, will stay out of users way, at the cost of some
repeated code. Later, hhen we have a couple of concrete use cases,
zoap will become more opinionated.

- corrupt packet, header incomplete (no message id)
-> ignore it
- corrupt packet, but header complete (included message id)
-> ignore unrecognized versions
-> respond with con on reset messages.

Lowering this logic into the coap layer encapsulates it in one place,
which should be simpler to verify, and, at least superficially should
simplify the implementation of coap consumers.... are there other
issues involved here that make is desirable to push such logic
upwards?

There are a couple of points that should be taken into consideration:

- zoap is largely independent of the network stack (by design) and it
doesn't have any buffers of its own;
- zoap doesn't have all the information to handle that correctly, for
example, an application may choose to ignore all invalid packets from
a multicast address, to avoid increasing the noise;

Thanks, I appreciate you taking the time to explain some of the relevant back ground issues.

But as always, if you have ideas (or patches :-) ) so we can reach the
middle ground faster, I am all ears.

Understood ;-)

... just two more questions...
- What are your thoughts / plan for zoap on yaip?
- Are you aware of anyone working on lwm2m over zoap ?

Cheers
/Marcus

Cheers
/Marcus

Cheers,
--
Vinicius