Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
2.0.0
The focus of this release has been on stabilizing the existing functionality of 1.0.x, fixing bugs and providing a production ready DTLS implementation so that CoAP clients and servers can communicate securely with each other.
During the course of development, major parts of the protocol stack have been refactored or rewritten in order to make Californium suitable for production use cases. The test suite has been signifacantly extended to increase test coverage and assert compliance with the arbitrary RFCs implemented by Californium.
Most work has been spent on improving/stabilizing the following features
- Support for DTLS 1.2 as defined by RFC6347 plus:
- ECDSA and PSK based cipher suites required by Lightweight M2M 1.0
- Server Name Indication (SNI), Maximum Fragment Length Negotiation as defined by RFC6066
- usage of RawPublicKeys as defined by RFC7250
- automatic session resumption to better support operation of clients behind a NAT firewall
- non-RFC7252 compliant request/response matching to better support long-term observations
- Blockwise transfer as defined by RFC7959
- Observing resources as defined by RFC7641
The following features have been added:
- Experimental (currently not complete) implementation of CoAP over TCP (RFC 8323), mostly at the level of draft-ietf-core-coap-tcp-tls-09
- Experimental implementation of DTLS 1.2 Connection ID (draft-ietf-tls-dtls-connection-id-07). The draft is not released, the new record type and hello extension have early assigned code-points. According to the IETF, these code-point values are to be considered final, though.
- Experimental implementation of OSCORE (Object Security for Constrained RESTful Environments), see draft-ietf-core-object-security-16.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
Given that this is a major release, there have been some changes being made that break compatibility with previous versions.
In particular, the CoAP stack's external interface that is used by client code to send CoAP requests and receive responses has been altered to better support use cases where the same client interacts with multiple CoAP servers as is the case for example on a Lightweight M2M server which retrieves data from its registered clients (note that in this case the LWM2M server plays the role of the CoAP client whereas the LWM2M client represents the CoAP server).
Another area where API has changed is the interface between the generic stack and the transport layer. The changes have been made to improve error handling as well as to allow for arbitrary transport protocols being used for CoAP exchanges.
The CoapEndpoint has been adapted to follow the builder pattern and therefore the public constructors are marked as deprecated.
The DTLS transport layer has been adapted to follow the builder pattern to allow for easier and less error prone setting of its many configuration parameters.
In order to improve the CoAP stack's flexibility regarding deplyoyment scenarios, a set of interfaces have been introduced which allow client code to use arbitrary strategies for managing CoAP tokens and observations. In particular this allows for the deployment of Californium in a clustered setup. To support internet scenarios, where addresses are frequently changing, we decided to generate token as system-wide identifier and not only as "client-local", as specified in RFC7252, 5.3.1. For request without tokens provided by the application layer, token are generated accordingly. For token provided by the application layer, they MUST obey this changed uniqness rule. Maybe we can add such a client-local scope again in future.
The handling of block-wise transfers has been refactored into its own layer in the CoAP stack in order to provide for better encapsulation and isolation of the functionality.
There still is only a limited set of user documentation available. Most of Californium's functionality is demonstrated by means of example application code that is contained in the repository. The example code, however, is up to date and illustrates basic and more advanced usage patterns.
The project web site has been updated to link to the Californium sandbox server hosted at Eclipse.
Californium is a library that is supposed to be embedded into application code that wants to communicate over CoAP. As such, it does not per se provide a user interface apart from its public APIs.
The original way of configuring the DTLS layer by means of a complex set of constructors with arbitrary paramaters has been removed.
Californium implements the following standards:
- Constrained Application Protocol (RFC 7252)
- Datagram Transport Layer Security 1.2 (RFC6347)
- Block-wise Transfers in CoAP (RFC 7959)
- Observing Resources in the Constrained Application Protocol (RFC 7641)
- CoAP over TCP (draft-ietf-core-coap-tcp-tls-09)
- experimental implementation only
Over the last two years there has been a considerable increase in community perception (and hopefully adoption). The increasing number and origin of issues on GitHub seems to indicate that Californium is perceived as a strong option when it comes to implementing CoAP based products.
A joint project of Ericsson and the Research Institute of Sweden has contributed an implementation of the upcoming RFC for Object Security for Constrained RESTful Environments (OSCORE).
Other OSS projects using or planning to use Californium
- The Eclipse leshan project implements Lightweight M2M on top of Californium
- The Eclipse Hono project includes a protocol adapter supporting CoAP based communication with constrained devices based on Californium
- Eclipse SmartHome supports CoAP based communication with devices based on Californium
- Log in to post comments