RFC 6648 / START HERE
Names without X-, before the details
Deprecating the X- prefix in application protocols. X- historically meant experimental or extension; RFC6648 is Best Current Practice 178, not a protocol version.
A guide to choosing textual names for things such as mail fields, HTTP fields and other application-protocol parameters. A parameter is a named piece of data. The advice separates a name from its standardization status.
The idea in one picture
Choose a name
Read its definition
Keep compatibility
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Experimental names often become widely deployed. Renaming them later can break older implementations or force support for both names. Creators should choose meaningful names they believe are unused, and protocol designers should provide clear registration procedures.
A familiar example
Imagine a fictional X-Picnic-Mode field spreading between implementations. Renaming just one sender to Picnic-Mode can leave an old receiver unable to recognize it. RFC6648 does not require renaming existing fields, override protocol-specific naming requirements, or make a prefix a security signal.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- When an experimental name escapesA textual parameter is a named piece of protocol data, such as a mail or HTTP field. Historically X- or similar constructs such as x. marked a supposedly experimental or private name. RFC6648 explains how such names escape into public deployments and make a later rename expensive. The Picnic-Mode names here are fictional teaching examples, not registered fields.→
- A prefix is not evidenceAn 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.→
- Choose names and registration rulesParameter 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.→
- Scope and safe migrationThe naming advice is intentionally bounded. RFC6648 does not decide whether existing X- parameters must remain or migrate, override a protocol specification that requires that form, or cover numerical parameters. If old and new forms differ in behavior or security, treating them as identical can cause interoperability and security problems.→
This introduction explains RFC 6648 (2012). Read the original RFC ↗