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

When an experimental name escapes

01

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

RFC 6648 · § 1EXAMPLE
3 / 3
When an experimental name escapesA fictional rollout first sends X-Picnic-Mode between implementations that recognize that exact name. A renamed Picnic-Mode field then arrives at the old receiver, but interpretation stops because that receiver recognizes only the old name. The alternative compatibility implementation recognizes both names, retaining a legacy burden. Equal semantics is an explicit assumption for this example, not a rule allowing blind aliasing or an RFC-mandated migration.Fictional extension rolloutX-Picnic-ModePicnic-ModeCompatibility receiverRecognizes both spellingsOld name may persist indefinitelyExample assumes equal semantics
03
Carry a compatibility cost

A hypothetical compatibility implementation recognizes both spellings. That can retain the old name indefinitely. The picture assumes equal semantics for this example only; check real definitions before aliasing.

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

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

Terms in this drawing
Parameter
A named item of protocol data; this guide concerns textual names, not numeric code points.
Interoperability
The ability of different implementations to work together.
Migration
Moving a deployed feature to a different name or behavior while considering existing implementations.
Related RFCs and changes

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

KEY POINT

Changing a deployed name can change what older implementations recognize.

  • RFC6648 deprecates X- and similar status-marking constructs for newly defined textual parameter names, including new parameters in established application protocols.
  • Private, local and experimental parameters remain legitimate; the advice concerns naming, not a ban on experimentation.
  • An old name and a new name need not be interchangeable. Supporting both is a possible compatibility cost, not a universal migration requirement imposed by this RFC.
DETAILS

The arrows show a hypothetical extension rollout. This best-practice document does not define a new packet protocol or a Picnic-Mode field.

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 ↗