Also, it could be a multicast query, right?
Yes, multicast CoAP discovery query, or unicast. The shown example was
link-local multicast but we also have site-local multicast for Registrar
discovery.
Unsecured unicast discovery is not used in the cBRSKI steps. The issue only
occurs if an unsecured discovery result needs to point to a secured (or a
different-scheme in general) resource.
So :: means, protocol specific thing? Or does it mean use the IP address in
the header of the reply?
It's not protocol-specific in any way - just formally defined as "unspecified".
Which we can give a specific meaning in scope of RFC 6690 link format documents; taking
"unspecified" in the link format document itself as meaning "the IP address that
sent the response containing the requested resource".
If we don't want this to generally hold (e.g. because we don't want to update
6690) - then it could be a cBRSKI protocol-specific thing, given that cBRSKI
doesn't require the client to go and parse the IP address from the link format
document.
If it's not forbidden, then it's allowed?
It's certainly allowed as a syntax - I guess I also wanted to do a quick check
if we could define this as a general rule for 6690 link format documents.
6690 defines already a way to compress the links by leaving out all of scheme,
host, port and only communicate the URI path.
E.g.
</b>;rt=brski
This would add also a way to compress by leaving out the IP address if it's
equal to the host IP address (inside the origin i.e. CoAP endpoint) that served
the link format response.
Esko
On 17-9-2025 19:44, Michael Richardson wrote:
Esko Dijk<[email protected]> wrote:
> 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 ~~~~
Also, it could be a multicast query, right?
So :: means, protocol specific thing? Or does it mean use the IP address in
the header of the reply?
> 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.
yes.
> 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
If it's not forbidden, then it's allowed?
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
