> RFC9031 uses 6tisch.arpa on the forward direction in Uri-Host.
Ok! This is also an interesting type of special hostname. In cBRSKI,
Uri-Host wouldn't be added to the request as we target the JP directly
with the CoAPS request as if it were the final server and not a proxy.
And unlike the 6TiSCH case the proxy can't inspect the CoAP request as
it is hidden in DTLS encryption.
In cBRSKI discovery the authority component that includes the host is in
a link in the CoRE Link Format document and it cannot be elided from there.
> I don't think foo.alt is going to fly...
It was exactly the purpose to not make a client fly off somewhere ;-)
Thinking about this: a ".alt" name might have some effect in a system
that uses a non-IETF-defined resolution mechanism in the "alt" namespace.
The domain ".invalid" is at least guaranteed to have non-resolvable
names. But I didn't like using such a name on purpose. (You may have the
same feel about "foo.alt")
> Since then I wonder why we didn't just leave Uri-Host option out.
> I think it's because we wanted to get out of .well-known, so Uri-Path
could
> be "j", ignoring RFC8820.
Uri-Host is included because RFC 9031 uses the CoAP (forward/explicit)
proxy mechanism which needs a target host definition, being the "host to
forward the request to".
The proxy resolves the hostname into an anycast IP address. Because this
final host is by design a 6TiSCH Registrar the client already knows it
supports the "j" resource.
But I think according to RFC 8820 this would still not be allowed though:
To avoid collisions, rigidity, and erroneous client assumptions,
Specifications MUST NOT define a
fixed prefix for their URI paths -- for example, "/myapp" -- unless
allowed by the scheme definition.
The scheme in this case is "coap" which doesn't define a specific
allowance for fixed URI paths outside of ".well-known". But in practice
it just works fine so I'm okay with that.
Esko
On 12-10-2025 20:28, Michael Richardson wrote:
Esko Dijk<[email protected]> wrote:
> An alternative to the string "::" would be a short hostname that's
guaranteed
> to be not resolved using the DNS, or using some local name
configuration, or
> other known methods.
uhm, okay.
> An even shorter version would be just "alt" for the hostname. Or
> "jp.brski.alt" if potential name clashes are a worry.
RFC9031 uses 6tisch.arpa on the forward direction in Uri-Host.
I don't think foo.alt is going to fly...
Since then I wonder why we didn't just leave Uri-Host option out.
I think it's because we wanted to get out of .well-known, so Uri-Path could
be "j", ignoring RFC8820.
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list [email protected]
To unsubscribe send an email [email protected]
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
