Can we encode the join-port in a CoRE LF "jp" attribute?

[EskoDijk]

This is an option to solve the same issue as for #85 and #87 , but done differently.

Here the proposal is to encode the join-port as a CoRE LF attribute such as "jp" in the LF response.

First the original example in the draft:

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

  RES: 2.05 Content
    Content-Format: 40 (application/link-format)
    Payload:
      <coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp

Second, the version using a "jp" attribute:

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

  RES: 2.05 Content
    Content-Format: 40 (application/link-format)
    Payload:
      <>;jp=8485;rt=brski.jp

This requires registering a new Link Format Target Attribute in the IANA registry here: https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#target-attributes

The parameter name could be even longer like "brjp" or so for "BRSKI Join Port", or "cjp" for "cBRSKI Join Port".
It could also be shorter like "p" with semantics of being a generic port hint for the resource for the case that the port number deviates from the default port. But such general case is tricky to get right for all usages, and competes with the standard method to designate the port of the resource, so better to avoid.

Note that the empty URI ("<>") is allowed in RFC 6690. The link is formally then pointing to the /.well-known/core resource, using 'coap' protocol, accessible via port 5683. So the link itself has no semantic meaning other than merely communicating the port value to the client. The IP address is communicated in by the CoAP response IPv6 datagram itself.

Any unsuspecting client that would try to use/resolve the link would end up at the resource /.well-known/core where it can't do much harm. (It's read-only.) And besides, such client would not recognize the type 'brski.jp' (rt) in the first place.