URIs and CRIs in CoAP APIs

In CoAP implementation APIs, URIs and/or lists of CoAP Options that carry a URI are used. This Wiki is intended to collect some information about this aspect.

Unstructured collection of examples:

• aiocoap and coap-handler-implementations both take paths of resources as lists of text strings (e.g implementing a /sensors/temp/ would be expressed as ["sensors", "temp", ""]).
  • Both perform some kind of option stripping: By the time the application handler receives a CoAP request, leading path options were "consumed" (for example, a sensor array mounted at ["sensors"] would only see ["temp", ""] in the request). This is convenient for building mount point independent handlers, but some handlers might still need to know what got stripped (eg. to produce RFC6690 references to sub-resources -- there always means !). The CRI information model might be a convenient tool for telling the handler a "base address" (the term being used sloppily here), which would both grant access to the path and the full URI (including scheme and host address). While the stripping already happens, the CRI-information-model based APIs are currently being developed in the cri branch.
• libcoap represents URIs as data structure coap_uri_t. Helper functions exist to create this data structure from a string, and to retrieve query and path as strings from a request PDU.

Conversion

Constrained implementations that avoid URI string conversions might easily find themselves converting CoAP request options back and forth with CRIs. Noteworthy properties of this process are:

• Text options in the path and query parts can be converted trivially. Unless one dwells on the subtleties of being Net-Unicode (which are not really enforceable due to the changing nature of Unicode), precisely the text string forms of CRIs are convertable, and any PET forms are not expressible in CoAP anyway.
• A potential bump in the road is that the normalized form of an empty-path CoAP URI (eg. coap://localhost/) has a trailing slash (the version without the trailing slash is normalized into that one per scheme specific rules). Only that path has different representations, with the CRI form being [""] ([] expresses the denormalized form), and the Uri-Path options list being []. ([""] is not a valid CoAP message). A possible way for implementations to deal with this is to transparently express an empty path option list as a single empty option towards the application, emulating the CRI version. This has convenient effects on the implementation of sub-tree handlers that may be serving under some prefix of the path or at the root of the server, in that they do not need to implement different handling for the two variants at their / resource.