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

Jon Shallow <supjps-ietf@jpshallow.com> Tue, 13 December 2022 11:13 UTC

Return-Path: <supjps-ietf@jpshallow.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 516E9C151711 for <core@ietfa.amsl.com>; Tue, 13 Dec 2022 03:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AckZdSAeiOB6 for <core@ietfa.amsl.com>; Tue, 13 Dec 2022 03:13:27 -0800 (PST)
Received: from mail.jpshallow.com (mail.jpshallow.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CF4C1516F1 for <core@ietf.org>; Tue, 13 Dec 2022 03:13:26 -0800 (PST)
Received: from [] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1p53Dt-00047D-LC for ietf-supjps-core@ietf.org; Tue, 13 Dec 2022 11:13:21 +0000
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: core@ietf.org
Date: Tue, 13 Dec 2022 11:13:01 -0000
Message-ID: <004601d90ee3$dd59df80$980d9e80$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01D90EE3.DD5AA2D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdkO49fbjJ0CUpB7S4ehQgS5OqB0NQ==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FKvB8zOrw-FbqR7ZiOjulj8BNOk>
Subject: [core] Interest in defining CoAP over Unix Domain sockets?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2022 11:13:32 -0000

Hi there,


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


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


As the server can only bind to an unique path, different paths need to be
used for datagram, stream etc.


To support multiple clients per server, each client needs to bind to an
unique path (for datagram) so that the server knows where to send responses
to. For stream, having the client bind to an unique path aids logging in the
server for troubleshooting issues.


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


For me, something like "coap+unix//[/unix/domain/path]/some/path" makes some
sort of sense, but that does not work for all.


There is a footnote for the coap:// etc. schemes in

[1] CoAP registers different URI schemes for accessing CoAP resources 

via different protocols. This approach runs counter to the WWW principle
that a URI identifies a resource and that multiple URIs for identifying the
same resource should be avoided


Worth pursuing further?