Proposal for core-lf encoding of variations

[toerless]

Capturing discussion from Nov 14 BRSKI meeting.

Original proposal from Esko:

request: REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

reply: RES: 2.05 Content
coaps://[fe80::c78:e3c4:58a0:a4ad]:8485;rt=brski.jp;brv=”jose cms”

KNX might be using CORE-LF, so that might be a community to help validating CORE-LF work we do. M2M might also use CORE-LF.

There is prior work mapping DNS to CORE-LF and vice versa.
Mentioned in CORE WG if there was interest in generic mapping.
Might only want to do mapping from DNS-SD to CORE-LF, because that is most complex.

Problem: Encoding of TXT record of RFC6763. Aka: Lets not do a generic mapping unless another WG like CORE is interested. Generic mapping is more work.

May want to do priority/weight from DNS-SD... or not.. How important is it.

[toerless]

TBD: Open thread on anima replying to Esko's original mail from sep 5th, so that that email is also public knowledge.

[EskoDijk]

Note: "brv" in the proposal is a new CoRE Target Attribute that can be registered in the new IANA registry (https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#target-attributes) defined by the draft document (https://datatracker.ietf.org/doc/html/draft-ietf-core-target-attr).

It stands for "BRSKI Variations". This attribute can appear in any BRSKI related resources (we don't constrain it to particular BRSKI resources in the registration at the moment - that would be too limiting for no good reason). It tells the client which BRSKI variations are supported. It's also an efficient way to define support for multiple variations: if this 'brv' would not be used, there would be multiple lines needed that repeat the same protocol scheme / IPv6 address information for each variation.

Join proxies communicate supported variations, and also Registrars do this. (The Join proxy does not necessarily need to understand any or all of the variations. It can just copy brv value verbatim in its discovery response.)