Re: [core] Interest in defining CoAP over Unix Domain sockets?

[Carsten Bormann <[e-mail]>]

Hi Jon,

> There has been a request for supporting CoAP over Unix Domain sockets – primarily for a reverse proxy which is secured to the outside world but wants to distribute the CoAP traffic internally within the appliance to various server applications.  See https://github.com/obgm/libcoap/issues/958 .

I agree that this would be useful practical addition.
While interoperability would be limited to a single system, different software does need to interact on a system, so having a common specification for doing this is useful.
 
> With libcoap, I have found that only minimal changes are required to the library to support Unix Domain sockets (mainly additions of some ‘case AF_UNIX:’ when handling the sockets) which then supports CoAP over datagram, CoAP over stream, CoAP over DTLS over datagram and CoAP over TLS over stream.

With the approach proposed, we would add another four URI-schemes to coap:, coaps:, coap+tcp:, coaps+tcp.  I’m not thrilled, but this probably can be done.

> Defining what a Unix Domain CoAP URI looks like for a client to parse is the more contentious area.  There is a fairly full discussion about this for http in https://github.com/whatwg/url/issues/577 with no major conclusions reached.  It all hinges on how best to embed the Unix Domain path into the URI.

The important consideration is that this needs to be compatible with the URI standard RFC 3986 (STD 66 [1]), so various libraries that might process the URI before it gets to the CoAP implementation are not confused.  (This will also enable compatibility with draft-ietf-core-href [2].)
 
> For me, something like “coap+unix//[/unix/domain/path]/some/path” makes some sort of sense, but that does not work for all.

For one useful analogy, Jupyter seems to allow http+unix://%2Ftmp%2Ftest.sock/ [3].

I think Jupyter’s syntax is compatible with STD 66, while brackets are not (these are used for IPv6 or IPvFuture, and we probably don’t want to declare UNIX domain sockets as IPv4711).
  
> 
> Worth pursuing further?

I think so.

I’m thinking about a way to shoe this into the existing URI-schemes, e.g., by saying that an initial / (percent-encoded %2F) in a reg-name triggers a switch to UNIX domain.
This would save adding four more URI schemes, but does smell a bit hacky.

Grüße, Carsten

[1]: https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2
[2]: https://www.ietf.org/archive/id/draft-ietf-core-href-11.html
[3]: https://github.com/jupyter/notebook/pull/4835