Skip to main content

4.4. First Come First Served

4.4. First Come First Served

For the First Come First Served policy, assignments are made to anyone on a first come, first served basis. There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment. However, requests must include a minimal amount of clerical information, such as a point of contact (including an email address, and sometimes a postal address) and a brief description of how the value will be used. Additional information specific to the type of value requested may also need to be provided, as defined by the namespace. For numbers, IANA generally assigns the next in-sequence unallocated value, but other values may be requested and assigned if an extenuating circumstance exists. With names, specific text strings can usually be requested.

When creating a new registry with First Come First Served as the registration policy, in addition to the contact person field or reference, the registry should contain a field for change controller. Having a change controller for each entry for these types of registrations makes authorization of future modifications more clear. See Section 2.3.

It is important that changes to the registration of a First Come First Served code point retain compatibility with the current usage of that code point, so changes need to be made with care. The change controller should not, in most cases, be requesting incompatible changes nor repurposing a registered code point. See also Sections 9.4 and 9.5.

A working group or any other entity that is developing a protocol based on a First Come First Served code point has to be extremely careful that the protocol retains wire compatibility with current use of the code point. Once that is no longer true, the new work needs to change to a different code point (and register that use at the appropriate time).

It is also important to understand that First Come First Served really has no filtering. Essentially, any well-formed request is accepted.

Examples:

  • SASL mechanism names [RFC4422]
  • LDAP Protocol Mechanisms and LDAP Syntax [RFC4520]