Choose names and registration rules
03Parameter creators and protocol designers have different jobs. Creators choose meaningful names they have reason to believe are unused, assuming their work might spread. Designers should make registration simple and allow names with either spelling. The example registry is hypothetical, not a real registration or an automatic standards approval.
Both Picnic-Mode and an already used X-Picnic-Mode can be eligible under the actual registry policy. Designers SHOULD NOT ban X- names from registration. An eligible application is not an approved standard.
Source for this drawing: RFC 6648 · Read RFC section 3 ↗
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
- Registry
- A maintained record of names or values and their definitions under an applicable registration procedure.
- Provisional
- A possible registry category when its governing rules provide one; not a category mandated for every protocol.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Prefer durable names and clear registration procedures over a status-coded prefix.
- Creators SHOULD assume their parameters might become standardized, public, commonly deployed or usable across implementations; they SHOULD employ meaningful, apparently unused names and SHOULD NOT add X- or similar constructs.
- Where the name space’s conventions allow it, a creator can incorporate an organization or primary domain name. This is not a universal namespace-ownership mechanism.
- New protocol designers SHOULD establish registries with potentially unlimited value spaces and simple, clear procedures; permanent and provisional registries are appropriate where useful.
- Designers SHOULD mandate registration of all non-private parameters regardless of spelling, and SHOULD NOT prohibit registration of names starting X-.
- Designers MUST NOT stipulate that X- means unstandardized or that its absence means standardized. Section6 does not itself change existing registration procedures.
SHOULD and SHOULD NOT are recommendations, not MUST and MUST NOT. Registration policy and technical review still govern the actual result.
Read the RFC section ↗