3 ms·

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 ca

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.

handsclean 3y ago
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 https://datatracker.ietf.org/doc/html/rfc8615#section-3. They just apparently have either granted or grandfathered in many exceptions.
- russellbeattie 3y ago
  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.
- mcpherrinm 3y ago
  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 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.

handsclean 3y ago

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 https://datatracker.ietf.org/doc/html/rfc8615#section-3. They just apparently have either granted or grandfathered in many exceptions.

russellbeattie 3y ago
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.
mcpherrinm 3y ago
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 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.