Summary

  • IANA registration proves that a tel URI parameter name has coordinated ownership and points to a public specification; it does not prove a concrete value is valid, supported, trusted or operational.
  • Keep registry state, specification semantics, URI syntax, receiver capability, policy, routing, identity and service outcome as separate receipts.

A registry row solved the collision problem, not the call

An admission service receives a tel URI containing a registered parameter. Its validator finds the name in the IANA table and marks the request supported. The downstream gateway does not understand the parameter, the number is outside the expected context and no route is selected. Nothing about the IANA row was wrong. The control asked it to prove facts outside its jurisdiction.

RFC 5341 created the tel URI Parameters registry so extensions would not collide or acquire private meanings silently. A new parameter registration supplies a name, whether values are predefined, and a durable public specification. A new value for an existing parameter also needs a reference. This is namespace governance and semantic discovery.

The row is therefore a pointer, not an executable verdict. The referenced document carries grammar, comparison, mandatory handling, security considerations and operational meaning. A concrete URI must still satisfy those rules. The receiver must implement them. Local policy must accept their provenance. Signaling must find a path. The requested service must complete.

No value still carries meaning

RFC 5341 explains that No Value means either a flag parameter or a parameter without a predefined set of values. It does not mean “no semantics”. The live IANA table shows enumdi and npdi this way. Their presence is syntactically different from a name=value pair, but the references still define what presence asserts and how it affects processing.

Treating No Value as harmless decoration creates a control bypass. A parser may discard the flag before the layer that needs to evaluate it. Treating it as an automatically true operational fact creates the opposite error. A flag says that a sender asserted a condition under a specification. It does not authenticate the sender, prove freshness or certify the referenced network state.

Constrained has a complementary limit. It tells readers that a parameter accepts a predefined or constrained form. The table does not reproduce every allowed value and comparison rule. A registered parameter with a malformed value remains malformed. A current value may also be stale or inappropriate for the local context even when its syntax is legal.

The base URI identifies; it does not dial

RFC 3966 separates a telephone-number identifier from a dial string. A tel URI names a resource identified by a number. It does not describe the steps necessary to reach that number, imply dialing semantics or name one physical device. A local dialer or signaling protocol supplies prefixes, context and network action.

The URI also does not choose voice, fax or data, nor provide data-call connection parameters. Those facts are negotiated elsewhere. Adding a registered parameter cannot silently enlarge the base identifier into proof of media, device, caller or completed service.

Local numbers illustrate the chain. They require phone-context, which provides the scope within which the local number is meaningful. A syntactically present context does not prove that originator and recipient are configured consistently, that the number belongs to a claimed organisation or that a route exists. Scope declaration and operational agreement are adjacent but distinct.

Mandatory handling is a capability boundary

RFC 3966 requires an implementation that encounters an unknown mandatory parameter not to use the URI. Optional extensions can be ignored only according to their rules. This turns capability into a first-class receipt. The registry can say what a parameter is called and where its semantics live; it cannot say which deployed receiver implements it.

A conformance test should therefore record parameter recognition and version, value validation, mandatory/optional decision and final disposition. “Name found at IANA” is insufficient. So is “parser accepted the semicolon”. The consumer must demonstrate that it applied the referenced semantics rather than treating an unknown control as inert.

RFC 5341 also requires the base service to continue operating in the absence of extensions. That protects interoperability: a parameter can refine behavior without redefining the existence of the service. Systems that make every call depend on an extension have created a local product contract, not a fact established by the registry.

The live table is not frozen in 2008

RFC 5341 supplied an initial table. The current IANA registry is a living authority and now contains later additions such as premium-rate and verstat, alongside isub, ext, phone-context, portability parameters and trunk-group parameters. A system that hardcodes only the initial RFC table will misclassify later coordinated names as private or unknown.

The reverse mistake is to project today's row into old traffic. A capture from 2010 must be evaluated against the registry and specification state applicable then. Current registration proves current namespace allocation, not that every historical sender used the same semantics or that a contemporary receiver could understand it.

Versioned registry snapshots, retrieval time and reference fingerprints belong in audit evidence. Without them, “registered” has no date. A mutable coordination surface becomes a timeless claim.

Portability and trunk parameters remain assertions

RFC 4694 registered number-portability data including npdi, rn, rn-context, cic and cic-context. RFC 4904 registered tgrp and trunk-context. The registry ensures that these names point to their specifications. It does not prove that a routing number is current, a carrier identification code is authorized, a trunk exists or the next hop accepted it.

Similarly, an enumdi flag defined by RFC 4759 expresses processing history under that protocol. Registry presence does not prove that an ENUM dip really occurred or that its result remains valid. isub-encoding has a registered place, but the receiving implementation still needs compatible encoding support.

Operationally, each parameter requires provenance. Who supplied it? From which trusted boundary? Under what time and number context? Which receiver validated it? Which routing or signaling decision consumed it? Those receipts turn a registered vocabulary into accountable execution.

Sources and evidence boundary

The sources establish specifications, document history and the live IANA registry snapshot. They do not establish a current call, number owner, caller identity, product capability, deployment, route, price, verification result or service outcome.