coap-technology / coap-technology.github.io Goto Github PK

Another C implementation of CoAP that is missing on the website: https://github.com/Lobaro/lobaro-coap

On the page "Tools", there's the sentence " The final CoAP protocol is supported by Wireshark 1.12, the development version of Wireshark.".
This is no longer true since version 1.12 has been released as stable

https://coap.technology/impls.html under "Browser based":

The link to the "Copper" Firefox extension is now dead… Mozilla revised their API in a manner that broke Copper, and it would appear the author has stopped maintaining the website as well as the extension as a result.

Shame, because it was one of the best tools available at the time.

Hi! 👋

clicking on RFC 7252 on page https://coap.technology/spec.html yields a 404 from the ietf.org as the link is http instead of https.
See curl -I http://tools.ietf.org/html/rfc7252.

Teufelchen

there exists a coap implementation for python3 with asyncio called "aiocoap". please consider adding it; given the structure of the implementations page, it would best fit on "Server-side":

<h3 id="python">Python 3</h3>
<p><b>aiocoap</b> implements CoAP natively on Python 3.4's <a href="https://docs.python.org/3.4/library/asyncio.html">asyncio</a> mechanisms, and provides command line tools for resource fetching and proxying:</p>
<p><a class="btn" href="https://github.com/chrysn/aiocoap">View details &raquo;</a></p>

for contex: aiocoap ias based on the txThings library already mentioned on the page, but has been forked by me in consultation with the oridinal author for adaption to python3 mechanisms, and has since diverged considerably.

Based on the input from the last CoRE/LwM2M protocol, I suggest we add an FAQ or "teaching CoAP" section to coap.technology.

If we manage to do that in a way that the section can live in a dedicated git repository, that repository's issue tracker can be a place where questions on general CoAP topics can be moved in (eg. if they show up in LwM2M's trackers), and either closed as works-for-me with a reference to existing text or processed into an FAQ entry or additional documentation.

The main page says under Tutorials : "Zach Shelby has made available a CoAP overview and tutorial. Slides here; watch at:"

The "Slides here" is a link, which points to http://community.arm.com/servlet/JiveServlet/previewBody/8633-102-2-15471/ARM%20CoAP%20Tutorial%20April%2030%202014.pdf

Unfortunately that link is stale and gets an HTTP 404.

Maybe of interst for you, we just released our CoAP implementation for IBMs Mote Runner
Platform (*). MR CoAP (written in an embedded version of Java) is an implementation of CoAP, including the Observe and Block extensions, for IBMs Mote Runner operating system.

MR-CoAP is available here:
https://github.com/MR-CoAP
(under the modified BSD Licence)

Feel free to add this implementation to http://coap.technology/impls.html in case you think it is interesting for a wider audience.

All the best!

(*)
http://www.zurich.ibm.com/moterunner/
http://www-03.ibm.com/press/us/en/pressrelease/42227.wss

Hello,

we have created a mini client/server version of CoAP targeting microcontrollers running MicroPython. Its main difference compared to the established Python implementations aiocoap and CoAPthon is its size and complexity since this library will be used on microcontrollers that support MicroPython such as: Pycom devices, ESP32, ESP8266.

link: https://github.com/insighio/microCoAPy

Kind regards.

Rust implementation of CoAP: https://github.com/Covertness/coap-rs

A rare situation where a CoAP server is modifying the message token has been found. CoAPthon server is generating a message token when the request's token is empty. #16 has been opened to see if it is legal, but this behaviour has shown a CoAP client implementation (h5.coap) is checking that the token received matches the one sent.

When an empty-token message is sent from h5.coap clients to a CoAPthon server, the second is generating a token and thus the acknowledgement is being rejected, sending the original empty-token message again (and receiving a random-token ack again) until the maximum allowed number of retries is reached.

I'm quite sure that CoAPthon's behaviour of generating a token is not RFC compliant, but is h5.coap token matching check RFC compliant? I know for certain that most CoAP client implementations do not check this. The only reference I've found in the specification is in section 5.3.2:

In case a message carrying a response is unexpected (the client is not waiting for a response from the identified endpoint, at the endpoint addressed, and/or with the given token), the response is rejected (Sections 4.2 and 4.3).

The bolded section may be a definition of this situation thus meaning that the response is unexpected and therefore should be rejected. Is h5.coap, being the only implementation that takes this into consideration as far as I know, the only RFC compliant client implementation in this sense?

I am working at RISE in a project together with Ericsson on contributing support for OSCORE to Californium. Would it be possible to mention OSCORE somewhere including that Californium now has support for it? It is now included in the 2.0.x-branch of Californium.

It seems that an other Python coap implementation is available. https://github.com/openwsn-berkeley/coap

An implementation in C; API description at https://cesanta.com/docs/coap/client-example.html. Mongoose is a networking library that comes with an implementation of CoAP messages, among other protocols.

Zepto Life has open-sourced a very polished Coap Server for microcontrollers;
https://github.com/zeptolife/zcoap-server

It's under active development.

It would be great if you could add this to your implementations website!

Thanks,

~Andy

When a client sends a confirmable request with an empty token, the server should send the piggybacked acknowledgement with an empty token as specified in 5.3.2:

2. In a piggybacked response, the Message ID of the Confirmable
   request and the Acknowledgement MUST match, and the tokens of the
   response and original request MUST match. In a separate
   response, just the tokens of the response and original request
   MUST match.

Is a server allowed to change the token on a non-piggybacked acknowledgment? I think this needs to be defined in the specification. Only piggybacked and separate responses are specified in the previous cite.

Please enable https support for the site. Not supporting https demonstrates that security is not taken security seriously.

Instructions on how to enable it:
https://blog.github.com/2018-05-01-github-pages-custom-domains-https/

Could be interesting to mention protocols and standards using CoAP in the page like OMA LWM2M and maybe ETSI M2M, IPSO

the datatracker references all have to be prefixed with "https://" these days ...

Hello @cabo,

for some time (weeks) I am not able to access the coap.technology. I see that there is some issue reported in the July, so looks like it worked in the meantime, but I recall like 2 months ago, page was not loaded, and today I face the same issue. I asked also other people from different locations, they face the same issue.

Are you aware of these outages ?

I'm curious if option names are case-sensitive? In RFC2616, section 4.2 Message Headers, the header names are deemed case-insensitive.

I did not see case-sensitivity mentioned in RFC7252.

Was this an oversight? Is there some way to propose its inclusion, or is it too late for that?

linking relevant issue: coapjs/node-coap#71