Re: [core] coap discovery

Christian Amsüss <christian@amsuess.com> Wed, 18 August 2021 08:35 UTC

Return-Path: <christian@amsuess.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 271BE3A0045 for <core@ietfa.amsl.com>; Wed, 18 Aug 2021 01:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50gcltCzC7mh for <core@ietfa.amsl.com>; Wed, 18 Aug 2021 01:35:40 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B623A003D for <core@ietf.org>; Wed, 18 Aug 2021 01:35:38 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0D8AE40104; Wed, 18 Aug 2021 10:35:35 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 739B0D0; Wed, 18 Aug 2021 10:35:33 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8d88:bd61:7974:fcd3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2E5DE101; Wed, 18 Aug 2021 10:35:33 +0200 (CEST)
Received: (nullmailer pid 3946651 invoked by uid 1000); Wed, 18 Aug 2021 08:35:32 -0000
Date: Wed, 18 Aug 2021 10:35:32 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Peter van der Stok <stokcons@bbhmail.nl>, core@ietf.org
Message-ID: <YRzGVDTtox6nnvgv@hephaistos.amsuess.com>
References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <YRuwIjlxDtfygpq/@hephaistos.amsuess.com> <8819.1629217674@localhost> <YRvvrdUIms4EHc+a@hephaistos.amsuess.com> <562.1629251270@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZshKLSG0maazKPch"
Content-Disposition: inline
In-Reply-To: <562.1629251270@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9KgLb2Yj5CY3dUYmEYbd7QszjIk>
Subject: Re: [core] coap discovery
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Aug 2021 08:35:44 -0000

Ok, then I misunderstood; next attempt. Would it look roughly like this,
then?

+-----------+-------------+---------+----------------------+
| IP header | UDP header  | CBORUDP | DTLS containing CoAP |
+-----------+-------------+---------+----------------------+

where CBORUDP is some self-delimited prefix in which the proxy encodes
the pledge's address (probably opaque to the register), and by itself
doesn't care what precisely is encapsulated in it.

In that case, I'd advertise it either as

    <cborudp://[ip]:port>;rt=cborudp

which just announces that there is some service of that kind without
saying what can be done with it (although a more precise rel or rt may
say that), or as

    <coaps+cborudp://[ip]:port/j>;rt=some...join

which'd indicate that coaps can be transported through that and that
there is a /j resource available. This'd help the proxy to advertise an
own `<coaps://[fe80::...]/j>;rt=some..join` resource which it doesn't on
its own control, but still provides for in its reverse proxy capacity.
(Given that resource is probably not discovered, that may be of little
use).

For me, either would work; announcing a <coaps://[ip]:port/j> would IMO
be misleading if no requests really arrive there through CoAP on DTLS
directly on UDP.

BR
c

-- 
Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)