Summary

  • RFC 3968 created the IANA registry that RFC 3261 had omitted, binding a SIP header-field parameter to its field, its name, a predefined-value flag and the RFCs that defined its meaning.
  • Registration reduced accidental namespace collisions and established documentary provenance. It did not prove endpoint support, runtime understanding, successful negotiation, authorization, secure behavior or call outcome.

In a protocol trace, a registered name looks reassuring. It is spelled correctly. A public registry contains it. An RFC is attached. Those observations are useful, but they answer a narrower question than operators often ask. They show that a community recorded a binding between a token and a documented purpose. They do not show that this particular endpoint knows the binding or performed the documented behavior.

RFC 3968, published in December 2004, began with an administrative omission. RFC 3261 allowed extensions to define new SIP header-field parameters and parameter values, but it had not created an IANA registry for them. RFC 3968 supplied that missing coordination layer and populated it with the parameters already defined in SIP and related specifications.

The repair mattered because a textual namespace can fail quietly. Two independent implementers may select the same short word for dissimilar features. Messages remain syntactically plausible while each side reads a different meaning into the token. RFC 3968 required a registration to identify the header field, the parameter name, whether the parameter accepted a predefined set of values, and the RFC or RFCs containing the definition. The declared goals were interoperability between independent implementations and prevention of accidental namespace collisions.

That is a governance achievement, not a capability advertisement.

A name was unique only inside its field

RFC 3968 did not create one flat global dictionary. It allowed the same parameter name to appear in different header fields. What it forbade was two parameters with the same name in the same header field. The identity of a registry entry was therefore contextual: header field plus parameter name, followed by the defining references.

This distinction changes how evidence should be stored. A log that retains only q, algorithm, tag or expires has thrown away part of the identifier. q under Accept is not automatically the same registered object as q under Contact or Security-Client. A search result that matches a bare parameter spelling can be factually correct and still point to the wrong semantic object.

Registered entries became reserved words. Implementations had to use them consistently with their defining RFCs, and private or locally defined parameters could not conflict with them. Yet RFC 3968 did not ban unregistered parameters. It warned that they were risky: a later RFC could register the same name for another purpose, leaving a private deployment with a collision that its earlier success had not prevented.

That warning separates observed function from durable authority. A private parameter may work today because both ends share local knowledge. Its working exchange proves local agreement at that moment, not a globally protected claim on the name. Conversely, registration establishes the public claim but says nothing about whether old software has learned it.

The row pointed to the definition; it was not the definition

Some parameters accepted arbitrary values within their grammar. Others accepted only predefined tokens. RFC 3968 marked the latter with a Yes column, but deliberately avoided creating a separate subregistry for every value set. Instead, it registered the values by reference. The row cited the original RFC and placed later RFCs that added values in double brackets.

An implementation could not treat the registry snapshot as a complete parser table. It had to follow every applicable reference and recover syntax, intended use, semantics and the valid value set. A copied table without its references lost the very authority that made the registration useful. A stale copy could also omit a later value while preserving the appearance of completeness.

The requirement for an RFC was therefore substantive. The specification had to explain syntax, purpose and semantics, and it had to discuss security. RFC 3968 used the IETF Consensus policy defined at the time by RFC 2434; the defining RFC did not have to be standards track. The later registry-policy framework in RFC 8126 describes a registration as an assignment of a value to a purpose within a namespace. That formulation remains useful: an assignment controls the public binding. It does not install code or authorize an action.

Negotiation happened in messages, not in IANA

SIP already had mechanisms for expressing some runtime extension support. RFC 3261 defined Supported, Require, Proxy-Require, Unsupported and response code 420. A user agent could advertise an option tag, demand that a peer understand an extension, or receive a refusal identifying unsupported requirements. Those messages were transaction evidence produced by endpoints.

The parameter registry produced a different kind of evidence. It established that a name had an attributable definition. It did not cause an endpoint to emit Supported, accept a Require, parse a parameter, apply a policy or complete a call. Even a support advertisement would remain narrower than an outcome: software can recognize a feature yet reject its use in a particular request or fail later for another reason.

RFC 3261 also required a server to ignore a header field it did not understand and continue processing, subject to fields necessary for the request. That rule made extensibility possible, but it makes packet survival ambiguous. A message passing through an endpoint does not prove that every unfamiliar field or parameter affected processing. Successful delivery can coexist with semantic indifference.

This is why the operator’s evidence chain needs several receipts: the registry entry, the defining RFC, endpoint capability, the exact transaction, observed handling and the final service result. None inherits the authority of the next.

Prefixes failed as lifecycle labels

The surrounding SIP change process reveals why RFC 3968 insisted on documentation. RFC 3427 described concern that new SIP features could damage security or greatly increase complexity. It created a supervised path for preliminary, private or proprietary P- header fields and tried to keep their limited scope visible in their names.

Experience did not preserve that boundary. RFC 5727 later recorded that popular P- headers escaped their intended closed environments. Once deployed widely, the prefix offered no plausible migration path to a general name. RFC 5727 deprecated the special process while continuing to point authors to RFC 3968 for parameter registrations.

RFC 6648 generalized the lesson beyond SIP. Implementations must not infer standardization or security solely from an X--style prefix or its absence. Spelling is a poor container for lifecycle, review status and trust. A durable system keeps those properties in explicit registry metadata and references.

The initial RFC 3968 table also showed why provenance mattered. Digest-related parameters drew on RFC 3310; event parameters on RFC 3265; private-network fields on RFC 3455; and security-agreement parameters on RFC 3329. The same table shape held entries with different mechanisms, deployment assumptions and security consequences. The row format unified discovery, not behavior.

The current registry is a living index

The IANA SIP Parameters registry now contains many separate registries: header fields, methods, response codes, option tags, URI parameters, header-field parameters and more. Its continued growth demonstrates the value of a stable coordination surface. It does not supply evidence that every listed mechanism is implemented everywhere—or implemented at all in a particular product.

The maintained RFC Editor record, errata search and IETF Datatracker establish publication status and recorded corrections. They do not measure deployment, interoperability rates or security outcomes. Those questions require different sources.

RFC 3968’s historical contribution was modest in form and large in consequence. It made textual extension claims attributable. A name could be located, scoped and traced to the document that defined it. The discipline lies in stopping there. Registration proves a recorded namespace binding; the endpoint must still prove what it knows and what it did.

Sources