Re: [core] coap discovery

Peter van der Stok <stokcons@bbhmail.nl> Wed, 18 August 2021 08:51 UTC

Return-Path: <stokcons@bbhmail.nl>
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 0A60B3A081F for <core@ietfa.amsl.com>; Wed, 18 Aug 2021 01:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl
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 NzSfiiCCToVe for <core@ietfa.amsl.com>; Wed, 18 Aug 2021 01:51:15 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379433A081C for <core@ietf.org>; Wed, 18 Aug 2021 01:51:14 -0700 (PDT)
Received: from omf03.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 8ADF520BE7; Wed, 18 Aug 2021 08:51:11 +0000 (UTC)
Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA id 3EF2C13D93; Wed, 18 Aug 2021 08:51:11 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 18 Aug 2021 10:51:10 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: =?UTF-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, core@ietf.org
Reply-To: stokcons@bbhmail.nl
In-Reply-To: <YRzGVDTtox6nnvgv@hephaistos.amsuess.com>
References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <YRuwIjlxDtfygpq/@hephaistos.amsuess.com> <8819.1629217674@localhost> <YRvvrdUIms4EHc+a@hephaistos.amsuess.com> <562.1629251270@localhost> <YRzGVDTtox6nnvgv@hephaistos.amsuess.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <01c960e06e38c3588c8d3a94e2d14cf3@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
Organization: vanderstok consultancy
Content-Type: multipart/alternative; boundary="=_6a90e9e9d67d996453b8539a7c961986"
X-Stat-Signature: p7uso9idbx6i7pfwsc98pwewoycb3hhw
X-Rspamd-Server: rspamout03
X-Rspamd-Queue-Id: 3EF2C13D93
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Session-ID: U2FsdGVkX1+DzRhD7M/XA24vijtDIcNT4EA1FQo7DAU=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=F4VwHbc0cG+RMvOEJm2dwb254N/x8AeEiZBd3x7Xn8U=; b=XtrA+j6wiNEcSKgTE8ik+GbzjA5yob2VE/IGeI2h1i+ARnc9T+jcFCrkGXm2AcsMC8Ry1dEa4RvTx8zWGjlSnP2uHdkvLEig31o+KdVoC3bNXsprxqERq+S+UBl3i5NYDSVt+rnE8urHF54EihTVnBnLiysxvoz460Byt7pFsN0=
X-HE-Tag: 1629276671-344711
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nxk_X1kpkYTG7JovcmiM2kuOvsM>
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:51:21 -0000

HI Christian,

very close indeed.

I would prefer:

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

for advertizing /j in another context as well.

My worries concern the impact on coap and the effort needed to 
standardize coaps+cborudp, remembering former efforts
concerning tcp and coap.

Peter

Christian Amsüss schreef op 2021-08-18 10:35:

> 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