[core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14)

[Carsten Bormann <[e-mail]>]

> On 2022-09-08, at 16:06, Marco Tiloca <marco.tiloca=[e-mail]> wrote:
> 
> Please go to the notes [3] and add topics you would like to discuss to the agenda.

I added the below.

This is a question that is somewhat trivial in nature, but for which we haven’t really found a satisfactory answer yet.
We don’t want to be the ones that are holding up the join proxy document, so it would be good if we could agree we will tolerate this small amount of architecture-bending or if we could find a non-bending way to indicate this information in the RD (and /.well-known/core in general).

Grüße, Carsten


### Resource Directory: Use for non-resource discovery

draft-ietf-anima-constrained-join-proxy registers two new rt= values, brski.jp and brski.rjp.
The description makes clear that these are not really used to mark web resources, but "links" that will be used to provide parameters to some protocol operation.

    The join-port of the Join Proxy is discovered by sending a GET
    request to "/.well-known/core" including a resource type (rt)
    parameter with the value "brski.jp" [RFC6690].  Upon success, the
    return payload will contain the join-port.

...

    The stateless Join Proxy can discover the join-port of the Registrar
    by sending a GET request to "/.well-known/core" including a resource
    type (rt) parameter with the value "brski.rjp" [RFC6690].  Upon
    success, the return payload will contain the join-port of the
    Registrar.

     REQ: GET /.well-known/core?rt=brski.rjp

     RES: 2.05 Content
     <coaps+jpy://[IP_address]:join-port>;rt=brski.rjp

Generally, enabling the RD (and /.well-known/core in general) to supply this information is highly desirable.  However, it is not clear that this should be done via something that could be called "fake resources".