Talk:Constrained Application Protocol

This is the talk page for discussing improvements to the Constrained Application Protocol article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Articles for creation

	This article was reviewed by member(s) of WikiProject Articles for creation. The project works to allow users to contribute quality articles and media files to the encyclopedia and track their progress as they are developed. To participate, please visit the project page for more information.Articles for creationWikipedia:WikiProject Articles for creationTemplate:WikiProject Articles for creationAfC articles
	This article was accepted on 23 August 2011 by reviewer KuduIO (talk · contribs).

Internet Low‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
Low	This article has been rated as Low-importance on the project's importance scale.

Some references seem a bit arbitrary.[edit]

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

Comments on multicast[edit]

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

Security issues - please be more specific![edit]

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

Misleading Message Format Diagram[edit]

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