Summary

  • RFC 3969 reserved every SIP/SIPS URI-parameter name in both schemes to prevent one spelling from acquiring two meanings; the paired reservation did not prove that the parameter applied to both.
  • The document called its policy “Specification Required” while demanding a standards-track RFC. RFC 5727 later identified the contradiction and clarified the intended rule as Standards Action.

The most revealing sentence in RFC 3969 is an apparent paradox. Any parameter name was to be registered for both a SIP URI and a SIPS URI. Yet the document immediately warned that some parameters might not apply to one of those schemes. The same name would occupy two places, but only the defining specification could say where the mechanism actually worked.

The choice solved a namespace problem rather than a feature problem. If a name were protected only in SIP, another author might reuse it in SIPS with different semantics. A parser, log, provisioning system or human investigator would then see the same spelling and have to guess which meaning travelled with it. By reserving the name across both schemes, the registry denied that ambiguity before it became installed practice.

That boundary is easy to lose in a database export. A paired row can look like paired support. It is not. Reservation controls who may assign the name; applicability controls whether a defined behavior belongs in a particular scheme. Implementation support, policy authorization and a successful session sit farther downstream still.

Seven names exposed the design

RFC 3261 had allowed new SIP and SIPS URI parameters and values but had not created an IANA registry for them. RFC 3969 filled the gap in December 2004. Its initial table contained seven names: comp, lr, maddr, method, transport, ttl and user. comp pointed to RFC 3486; the others initially pointed to RFC 3261.

The row carried a name, a flag saying whether values came from a predefined set, and references. For a Yes flag, the registry did not pretend to contain the whole vocabulary. It sent implementers to every cited RFC. The live IANA SIP Parameters registry, for example, now cites both RFC 3261 and RFC 7118 for transport. The row is a maintained map to authority, not a self-sufficient grammar.

This is why the registry called registered names and values “reserved words.” A local parameter could exist, but it risked collision with a future public assignment. Registered text had to be used consistently with its defining RFC, and a private definition could not conflict with it. The registry had no vendor-extension tree: RFC 3427 had already warned that SIP extensions could add dangerous complexity or security damage, so the public path required RFC documentation.

The procedure protected independent implementations from accidental convergence on the same spelling. It did not certify that two products implemented the referenced behavior. Nor did it make SIPS merely “SIP plus a letter.” RFC 5630 later clarified SIPS handling and its security expectations; RFC 3263 described server location and transport selection. Those operational rules cannot be reconstructed from the registry's paired reservation alone.

A policy label disagreed with its own requirement

RFC 3969 also preserved a subtler historical fault. Section 4.2 used the RFC 2434 label “Specification Required.” The next sentence required the parameter to be defined by a standards-track RFC. Those are not interchangeable thresholds. Specification Required allows a permanent public specification plus expert review; Standards Action requires approval through the standards process.

Six years later, RFC 5727 named the conflict directly. It said the contradiction arose from misunderstanding the registration-policy categories and that the intended requirement was Standards Action. The current IANA page now displays Standards Action. RFC 8126, which later replaced the older policy vocabulary, helps explain why the distinction matters: registry policies allocate different decision rights, review burdens and documentary thresholds.

This correction is not evidence that the registry was unusable. It is evidence that governance has provenance. A current cell answers the current administrative question. The 2004 RFC answers what the original text said. RFC 5727 explains why the two differ. Removing any one of those layers produces a cleaner story and a less accurate one.

The maintained RFC Editor record, errata search and IETF Datatracker history provide distinct records of status, reported corrections and document history. None measures deployment. RFC 3986 supplies the general URI framework, while RFC 6648 later warned against using prefixes as shorthand for standards status. Together they reinforce the same discipline: spelling, assignment, applicability, maturity and observed behavior are different facts.

How to read one observed parameter

Start with the exact URI scheme and spelling. Locate the registry row as it existed at the relevant time. Follow every reference, not just the first one, and read the defining syntax, applicability and security sections. Then obtain implementation evidence: parser support, configuration, transaction behavior and the final result. A successful call cannot retroactively prove that a parameter mattered; an assigned name cannot prospectively prove that a system will understand it.

RFC 3969's paired reservation was therefore conservative engineering. It spent two namespace slots to preserve one meaning. The cost was a table that looked broader than actual applicability. The remedy was never to infer behavior from the table. It was to retain the chain from name, to scheme, to reference, to implementation, to outcome.

Sources