Talk:Constrained Application Protocol

Some references seem a bit arbitrary.

I would stick to referring either standards or drafts or very well known references instead of random articles. — Preceding unsigned comment added by 62.237.32.194 (talk) 11:25, 2 November 2016 (UTC)

Comments on multicast

RFC7390 defines reliable multicast for CoAP, the article is misleading that RFC7390 is unreliable multicast.

Security issues - please be more specific!

The section about "Security issues" is somehow unspecific. It points to references, which scope is wider than CoAP.

> Although the protocol standard includes provisions for mitigating the threat of DDoS amplification attacks, these provisions are not implemented in practice.

I'm not sure, if this should refer to. 1. RFC 7252, 11.3., Risk of Amplification 2. or general to use DTLS (referenced by the second part of that sentence).

I personally would sum up, that not using encryption in a public network, comes with general risks, regardless of the used protocol. Sure, using UDP comes with the specific risk class of spoofing and amplification attacks. RFC 7252 (and RFC 6347) consider that specific UDP risks and mitigates them. The statement "these provisions are not implemented in practice" comes without evidence. In my experience, such issues are more or less a question of awareness, rather than an issues of a specific protocol.

The other two references of that section seems to cite articles, where I'm not sure, if the authors really read the specification (RFC7959), at least more than the first pages. Page 6, "Both sides have a say in the block size that actually will be used." is simply interpreted wrong, [https://tools.ietf.org/html/rfc7959#page-11 Page 11, "(The effect is that, if the server uses the smaller of (1) its preferred block size and (2) the block size requested, all blocks for a body use the same block size.)" explains, how to interpret it.

Also here, sure, it requires awareness, but I'm also not sure, if the authors have tested, if these mass-peers are really setup using large blocksize. — Preceding unsigned comment added by AchimKraus (talk • contribs) 10:09, 18 January 2021 (UTC)

Misleading Message Format Diagram

I have very recently relied on the figure depicting the CoAP message format, here in the article.

I have to say it was quite misleading for the following reasons:

• the offset column starts from octet 4/bit 32 while it should start from octet 0/bit 0
• more importantly, the options are shown as taking exactly 4 bytes, while (as correctly explained in the text) they can occupy a variable number of bytes determined by their number and lengths
• it is particularly misleading to read from the graph that a byte with hex value 0xFF (or binary 11111111) is to be found at octet offset 20 (or should it be 16, see first point above). In fact, such a end-of-options marker can be found at very different offsets based on the length of tokens and number and length of options

--Giatorta (talk) 16:46, 9 April 2022 (UTC)