Well-Known URIs(iana.org)
iana.org
Well-Known URIs
https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
13 comments
IANA (not w3c) just maintains a directory of who uses them to avoid collisions.
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.
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.
Imagine this is a code library and I think it’ll become clear that while only uniqueness may be strictly necessary, inconsistent, undescriptive naming is harmful to API consumers, and to a lesser extent harmful to the implementers.
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.
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.
An IETF standard is only one of the ways to get an entry into the IANA registry.
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.
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.
I hadn't seen this before... At least it calls out how dangerous the .well-known directory could be. So that's good. /s
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.
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.
At least no one ever tried to register names with unusual punctuations [1]. `autoconfig/mail` is not registered FYI.
[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).
[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).
I had to double check if posh isn't some of 1st April RFC
I'm on your side here, this is quite chaotic. Let's define a new standard! (xkcd 927)
That doesn't apply to things that don't have a standard at all.
I wish people wouldn't bring it up every time the idea of standardization is mentioned.
I wish people wouldn't bring it up every time the idea of standardization is mentioned.
Interesting, but I'm confused. Why does this list not include the `robots.txt` (rfc9309)?
I guess these uris are all under /.well-known/ path, which robots.yxt predates. I didn't know there are this kind of organized list of these.
Oh, well that makes sense. I couldn't connect the dot's as I haven't heard of most of these. Thanks!
[deleted]
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.
1. https://en.m.wikipedia.org/wiki/Well-known_URI