Well-Known URIs
iana.org
iana.org
First, whoever decided on .well-known starting with a . (making it normally a hidden directory) was a complete moron. I don't care what the pedantic reasoning was, it was idiotic. It's publicly accessible, yet hidden from admins unless they're looking for it?? It's like a security leak waiting to happen.
Secondly, I don't think I've ever seen a more chaotic list of naming conventions in my life:
* Non-descriptive names or acronyms: coap, core, posh, ni, dots.
(You have to admire that last one in terms of just screwing with admins.)
* Multiple names with dashes: stun-key, reload-config, apple-app-site-association
* Multiple names without: nodeinfo, openpgpkey
* Multiple names with dots: com.apple.remotemanagement
(I love how Apple can't decide).
* Names with extensions: security.txt, ai-plugin.json, host-meta.json
* Names that have apparently optional extensions: host-meta
* Subdirectories: autoconfig/mail
It's complete anarchy. Does the W3C actually want anyone to maintain this chaos? It must be the least well thought out "specification" that's ever been inflicted on the world.
I wish people wouldn't bring it up every time the idea of standardization is mentioned.
As should be obvious from the collection, there’s nobody in charge here. You can just ask for whatever prefix you want. I guess in that way, I agree with you: it is nearly anarchy.
I personally think that’s fine. Why does it matter if the names aren’t consistent? The different protocols using well-known don’t have to talk to each other. Any individual program is likely to just care about one for whatever protocol it’s speaking. All that matters is they don’t overlap.
These are registrations, not documentation of independent usage, so yes, there’s somebody in charge, the IETF. They can enforce good naming, and do: https://datatracker.ietf.org/doc/html/rfc8615#section-3. They just apparently have either granted or grandfathered in many exceptions.
4.4. Hidden Capabilities
Applications using well-known locations should consider that some server administrators might be unaware of their existence (especially on operating systems that hide directories whose names begin with "."). This means that if an attacker has write access to the .well-known directory, they would be able to control its contents, possibly without the administrator realising it.
https://datatracker.ietf.org/doc/html/rfc8615#section-3.1
> Well-known URIs can be registered by third parties (including the expert(s)), if the expert(s) determine that an unregistered well-known URI is widely deployed and not likely to be registered in a timely manner otherwise. Such registrations still are subject to the requirements defined, including the need to reference a specification.
So if some non-IETF protocol starts using a .well-known path, it can get added to the IANA registry even if the protocol authors themselves don’t register it.
[1] RFC 8615 requires that all names should conform to RFC 3986 `segment-nz` production, which is virtually any plausible character minus slashes (the exact regexp is `([A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2})+` if you wonder).