I am trying to implement an OCF compliant cloud interface in golang that interfaces with mainflux (www.mainflux.com<http://www.mainflux.com>) but in the process of working on the coap implementation, I noticed what appears to be inconsistencies between the OCF spec and the implementations, but I wanted to double check before jumping to conclusions:
-The OCF core spec only mentions port 5683 for CoAP communication whereas RFC 8323 section 8.2 says that 5684 should be the default port for coaps+tcp. It also says "A TLS server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled." Yet ALPN has been explicitly disabled in our copy of mbedTLS (https://github.com/iotivity/iotivity/blob/master/extlibs/mbedtls/config-iotivity.h). -speaking of ALPN, section 12.3.4 of the OCF core spec states "For the 'coaps+tcp' URI scheme the 'TLS Application Layer Protocol Negotiation Extension' IETF RFC 7301 shall be used". Is ALPN implemented somewhere outside of mbedTLS or is this an oversight in the implementation and CTT for not verifying this? For the record, it doesn't appear at first glance like iotivity-constrained uses any custom config files for mbedTLS so this issue probably only applies to iotivity. -In a recent commit to iotivity-constrained which added TCP support, (https://github.com/iotivity/iotivity-constrained/commit/00d8baee002b658e7f34215bae01bf6d28047646) the code was set up such that when communicating via TCP, "blockwise transfer logic is not executed". I assume this is because the blockwise transfer code is an implementation of RFC7959 which is focused on UDP. RFC8323 section 6 extends that spec in order to make it a good fit for TCP and it's explicitly referenced in section 12.3.8 of the OCF core spec. While 12.3.8 only says how the implementation must work IF it's implemented, section 12.2.8 of the OCF core spec says that blockwise transfer functionality should be present on all clients, as well as servers which, "generate a content payload that would exceed the size of a CoAP datagram as the result of handling any defined CRUDN operation". I'm interpreting these two sections together as a requirement of the codebase to support RFC8323 compliant block-wise transfers over TCP, and I assume any device with OTA update support would need to deal with payloads larger than a CoAP datagram so this isn't exactly an edge case. Should the CTT be testing for this? With regard to the issues of port number and ALPN: it would seem like an easy fix is to better align ourselves with RFC8323 by changing the OCF core spec such that the default port for coaps+tcp is 5684, and that if ALPN isn't performed then a TCP listener on port 5684 will default to coaps+tcp, thus mitigating the need for ALPN in the first place for this use case. Networking isn't exactly my bailiwick though, so I assume someone with more experience and authority within the OCF will have a better idea of what to do. With regard to the RFC8323 blockwise transfers over TCP: according to section 6 of RFC8323, It seems like this is a pretty essential feature to implement if we want to be able to send OTA updates over CoAP or have a fully functional CoAP<=>HTTP proxy. Not sure how high of a priority this is though.
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
