Visual RFC.
ALL RFCs / RFC 6648
Read the RFC ↗
RFC 6648 / Naming and interoperability

Scope and safe migration

04

The 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.

DIAGRAMRead RFC section 1 ↗
RFC 6648 · § 1EXAMPLE
4 / 4
Scope and safe migrationFour independent scope comparisons prevent an overbroad rewrite. Existing names may remain or migrate at their maintainers’ discretion. Governing protocol specifications that require X- are not overridden. Numeric extension code42 is outside RFC6648’s textual-name scope. Finally, a fictional old definition lacks a check required by a newer one, so the blind-alias path stops before incorrectly treating the old form as satisfying the new requirements. No actual vulnerable field or numeric allocation is asserted.Scope limits · independent examplesOld definitionCheck absentNew definitionCheck requiredblind aliasDifferent security propertiesCompare the actual definitions firstFictional example · not a deployed vulnerability
04
Do not alias unequal semantics

An old fictional form lacks a check that its newer definition requires. The blind-alias route stops before treating the old value as satisfying the new requirement. Compare definitions and security properties first.

Source for this drawing: RFC 6648 · Read RFC section 1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 8174 BCP 14 key words RFC 9110 HTTP

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Scope
The set of cases to which a recommendation or requirement applies.
Alias
Treating two names as interchangeable; safe only when the relevant semantics justify that treatment.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Do not turn a new-name recommendation into a blind rewrite of deployed data.

  • RFC6648 makes no recommendation whether existing X- parameters should stay or migrate; their creators or maintainers decide.
  • It does not override specifications that legislate X- use for a particular application protocol, such as the iCalendar x-name construct cited in Section1.
  • Numeric parameter values and their experimental/private-use ranges are outside this document’s scope.
  • AppendixB warns that standardized and older forms can have different behavior or security properties; implementations should not treat such forms as identical. This is not an instruction to blindly remove a prefix.
DETAILS

The security comparison is a fictional example of unequal semantics. It does not claim that a particular deployed field is vulnerable.

Read the RFC section ↗

All chapters in RFC 6648

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗