Re: [core] coap discovery

[Peter van der Stok <[e-mail]>]

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