On Thu, Oct 16, 2025 at 07:43:27PM +0200, Esko Dijk wrote: > Sounds like we should consider this direction. What about "me.arpa" ?
Sure. > It could be specifically defined as the sender (either hostname or IP > address, whatever is known) of the message that contains the hostname > "me.arpa" or "same.arpa". Right. > Additional benefits in cBRSKI context are: > 1. For sender of Link Format: not having to encode the IPv6 LL address in > UTF-8 format. > 2. For receiver: not having to, or accidentally trying to, parse the IPv6 LL > address from UTF-8 format. What's the deal mentioning UTF-8 ?as an additional challenge? > 3. Avoid duplicate information in two different encodings which might lead > to unexpected bugs (e.g. due to implementations using the different version > of the information). Example ? Hah! actual logical benefit: In specific environments there may not even be any actual domain names allocated. This includes RFC8994 networks (or proposed variations) and may equally apply to embedded IoT environments. (Isn't this also the reason for 6tisch.arpa ??) Still pondering if/what we might say about subdomains: e.g.: prefer-ipv6.me.arpa I guess we could say every app using this could specify their own subdomains with their intended reaction semantic to the client interpreting it. Cheers Toerless > Esko > > On 16-10-2025 19:05, Toerless Eckert wrote: > > Define/allocate "same.arpa" ? > > > > --- > > Semantic: May be used by any application where the recipient can deduce > > a prior hostname (or in the absence of the hostname an IP/IPv6 address) > > from the context in which it receives a URL with hostname "same.arpa". > > That hostname should then be used to connect to this URL. URL responders are > > assumed to recognize and accordingly react to a "same.arpa" URL. > > > > "same.arpa" can have arbitrary, application specific subdomain. > > --- > > > > The question really if in our use-case we will actually save significantly. > > If the only benefit is saving bytes on the wire, it's a bit underhwlming. > > The use of a generic hostname would be a lot more attractive if it would > > help to solve other problems too. > > > > Cheers > > Toerless > > > > > > On Mon, Oct 13, 2025 at 08:46:43PM +0200, Esko Dijk wrote: > > > > 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 protected] > > > -- > > > *IoTconsultancy.nl* | Email/Teams:[email protected] | +31 6 2385 > > > 8339 > > -- > *IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6 2385 > 8339 -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
