Hi CoRE,
In the recent spirit of removing unused bytes on the wire, I have the
below proposal for cases where CoRE Link Format is used for discovery.
cBRSKI and cBRSKI Join Proxy are example protocols that use this.
In some cases, an IPv6 address is necessarily included in a Link Format
response even though the protocol doesn't use the included address at all.
The proposal is that for such cases the IPv6 unspecified address (::)
can be used, which shortens the payload and reduces potential for errors.
An example discovery interaction from cBRSKI:
~~~~
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
~~~~
In this link-local discovery scenario, the responding entity (a Join
Proxy) includes its LL IPv6 address in the link even though the client
is not going to use it.
The client will use the IPv6 LL source address of the CoAP response to
send the next (CoAPS) packet to, on UDP port 8485. This is how the
protocol is currently specified.
It requires the IP layer or CoAP stack to be able to provide the IP
source address of a response to the higher layer, which is generally
available on embedded systems.
Knowing the client MUST follow this procedure for the resource, the
server could decide to not disclose the IPv6 address: i.e. leave it
unspecified in scope of the Link Format document.
RFC 4291 and RFC 4861 would allow such use of the unspecified address;
and per RFC 3986/6690 it yields a valid CoRE link.
The result is then shorter - 31 bytes for the payload instead of 53.
~~~~
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[::]:8485>;rt=brski.jp
~~~~
This also reduces the potential for ambiguity in implementations, e.g.
the behavior that some clients may parse the IP-literal to use it to
contact the Join Proxy while others may use the IPv6 source address of
the CoAP message.
If most client's don't parse the IP-literal then some error in the
IP-literal on the server side may go undetected.
Does this sound like a proper use of Link Format? It does seem to make
sense that we can suppress information that's already encoded in the
response CoAP UDP message, one of the core features of CoAP :)
Is there a need to formally Update RFC 6690 before starting to use this?
(To me it seems like a useful feature also in other scenarios.)
The formal semantics of the IPv6 unspecified address within a Link
Format document then could be "an IPv6 adress equal to the IPv6 address
in the link format resource's base URI". And similar for IPv4
unspecified address.
regards
Esko
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
