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

supjps-ietf@jpshallow.com Wed, 14 December 2022 17:23 UTC

Return-Path: <jon.shallow@jpshallow.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D15C1522B1 for <core@ietfa.amsl.com>; Wed, 14 Dec 2022 09:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh3vwbKoPoWN for <core@ietfa.amsl.com>; Wed, 14 Dec 2022 09:23:47 -0800 (PST)
Received: from mail.jpshallow.com (mail.jpshallow.com [31.22.13.189]) (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 6CECBC1522A7 for <core@ietf.org>; Wed, 14 Dec 2022 09:23:46 -0800 (PST)
Received: from [192.168.0.78] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1p5VTs-000527-4i; Wed, 14 Dec 2022 17:23:44 +0000
From: supjps-ietf@jpshallow.com
To: 'Carsten Bormann' <cabo@tzi.org>
Cc: core@ietf.org
References: <004601d90ee3$dd59df80$980d9e80$@jpshallow.com> <E270AC49-755E-4275-9F69-2D08B542E537@tzi.org> <014a01d90fce$043349d0$0c99dd70$@jpshallow.com>
In-Reply-To: <014a01d90fce$043349d0$0c99dd70$@jpshallow.com>
Date: Wed, 14 Dec 2022 17:23:22 -0000
Message-ID: <016701d90fe0$c49d3bb0$4dd7b310$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI0eiyo13tkLZMJo+2rfTYfx7famQFWV2EZAjAko9Ctmo75wA==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9ej7x9HoyAQLhS-r-zvVhDc0kdo>
Subject: Re: [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: Wed, 14 Dec 2022 17:23:51 -0000

Hi all,

A further thought.

If the Unix Domain URI is encoded as coap+unix://some.local.path/another/path,
the host reg-name would be "some.local.path" which when passed to the CoAP logic as the "host" would then get translated to "/some/local/path" (or "\some\local\path" for Windows) for ongoing use.

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2 states

   This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.

So instead of the host being parsed for Internet Domains (DNS etc.), it is parsed (and mapped) as a Unix Domain to a local file.

The file after all is "registered" to the local system.

Would that work as a way forward?

Regards

Jon