Register a precise name and a specification
02An application name is one nonempty URI path segment. Registration connects that name to stable rules and avoids collisions.
Assume expert advice and the required process complete for this fictional example. Registration does not promise that any particular server implements the resource.
Source for this drawing: RFC 8615 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- IANA
- Internet Assigned Numbers Authority: maintains the relevant public registries.
- Specification Required
- Registration procedure involving a published specification and designated expert review.
- Provisional
- A registry status that can change or be removed under the RFC’s expert/community rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A recognizable path spelling alone is neither registration nor a complete application protocol.
- Applications minting new well-known URIs MUST register them. Registered names MUST conform to RFC 3986 segment-nz: a nonempty sequence of pchar values, with no literal slash. This is broader than just letters, and is not an arbitrary multi-segment path.
- Application names SHOULD be precise; generic-term squatting is discouraged. A registration at least references a specification defining the obtained format, associated media types and usable URI schemes. If schemes are not specified, http and https are assumed.
- Registration information includes URI suffix, change controller, specification document(s) and status; related information is optional. The procedure is Specification Required, on expert advice. Experts consider Section 3 conformance, specification availability/stability and security.
- Standards Track RFC and other open-standard values are permanent. Other values can be permanent when experts find them in use after community consultation; otherwise provisional is appropriate. Experts can remove unused provisional entries or promote them after consultation. Third-party registration of widely deployed names is possible, but still needs a specification and expert determination.
This is a hypothetical design review, not a registration submission or actual expert approval. picnic/info fails the single-name requirement because it contains a slash. picnic-info is syntactically suitable but needs the remaining specification and registration process. Additional path components may be defined by a registration; that does not allow slash in the registered name itself.
Read the RFC section ↗