This repository's issues list manages requests to add and change entries in the well-known URI IANA registry. Please note our contribution terms.

Your Expert is currently @mnot.

To request registration of a new well-known URI (or a change to an existing one), you can:

• File an issue (preferred), or
• Send e-mail to the mailing list.

See RFC 8615 for more information about well-known URIs; in particular, the requirements for registration.

Once approved, your request will be incorporated into the IANA registry, whereupon it will be officially registered.

Per RFC 8615, "Registered names for a specific application SHOULD be correspondingly precise; "squatting" on generic terms is not encouraged." Therefore, a request to register a common name that has not seen broad community discussion and support is likely to be responded to with a recommendation to either choose a more specific name (e.g., with a prefix identifying the registering organisation) or to engage in a community discussion first.

For example, a request to register a single English word, either bare or with a suffix (such as communicate.txt) is likely to be rejected. Likewise, terms that are related to upcoming or potential standardisation activity may be reserved for community use.

Likewise, if a name with a suffix is already registered, requests for conflicting uses with different suffixes may be rejected to avoid confusion. For example, if foo.txt is registered, a request to register foo.json for a different and clashing use may be rejected.

Values defined by standards-defined specifications will have a status of "permanent"; most others will have a status of "provisional." See the guidance for details. Note that we use this list to determine what is a recognised standards organisation.

As per IANA guidelines, values that are no longer in use should be marked as "obsoleted", and those whose use is not recommended should have a status of "deprecated".

This registry requires a stable reference for a specification document. Publication by a recognised open standards body is preferred; however, publication by established Open Source projects (i.e., those that demonstrate a community that's commited to ongoing support), community and commercial organisations are also accepted, provided that they have a reasonable plan to promote specification stability.

Specifications that are hosted on single-purpose Web sites or GitHub repositories are not eligible for registration unless they demonstrate significant deployment and/or community buy-in. In particular, single-owner GitHub repositories are not suitable specification references.

The specification document must define the registered value as a well-known URI. Requests to register terms specified for other purposes will be rejected.

Generally, a registration request should be made when your document is mature enough for wide review. Registration is not a way to propose something for standardisation; we strongly recommend engaging with a broader community (e.g., through the IETF DISPATCH process or the W3C Incubation process before registration.

If your reference is an Internet-Draft, the normal time to request registration is around the same time you request other reviews; e.g., Working Group Last Call or IETF Last Call. If you are unsure about your use of well-known URIs, request registration earlier. Note that if you do not request registration here, IANA will do so as part of their process.

If your reference is in another standards body, a provisional registration can be made before the document is finalised, becoming permanent once it is published (if appropriate).

If your reference is from an Open Source project, community or commerical group, a request can be made once your document becomes public, but anticipatory requests are discouraged, and may be refused or delayed.