A prefix is not evidence
02An implementation must read the applicable definition and rules. The presence or absence of X- does not establish standardization status, permission to process a field, or security. The comparison uses independent fictional names; it does not assert that the two names are equivalent.
The prefix-only shortcut to trusted processing stops. Determine permitted behavior and validate the actual input under the relevant protocol and application policy; neither spelling supplies trust.
Source for this drawing: RFC 6648 · Read RFC section 2 ↗
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
- Standardization status
- Whether and how an item is specified or registered, established by evidence rather than a name prefix.
- Automatic action
- For example, accepting, dropping or reclassifying a parameter solely because of its spelling.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
MUST NOT infer status or take automatic action solely from the prefix.
- Section2 says implementations MUST NOT assume a parameter’s status or take automatic action about it based solely on the presence or absence of X- or a similar construct.
- Section5 says implementations MUST NOT assume standardized parameters are secure and unstandardized ones insecure based solely on their names.
- This does not require accepting unknown fields. Apply the actual protocol definition, extension handling and validation rules.
No X- does not prove a standard, and X- does not prove a threat. A registry entry also is not a security certificate.
Read the RFC section ↗