Stop at unknown requirements and missing consent
06Understanding a URI, forwarding it and attempting a call are different operations. Unknown mandatory parameters and missing user consent stop use.
In the selected offline fixture the receiver understands required parameters, understands any local context, and has explicit consent. Call setup may be handed off to its own dialing implementation; connection or reachability is not guaranteed.
Key idea: A usable identifier still needs understood requirements, local context when applicable, and explicit consent before calling.
Terms
- tel URI
- A Uniform Resource Identifier for a telephone number. tel names the telephone scheme; it is not an instruction to dial.
- Global number
- A number written with a leading + and its international country and national number.
- Local number / context
- A number meaningful within an identified scope, such as a private phone system. The context distinguishes otherwise identical local numbers.
Rules & examples
A usable identifier still needs understood requirements, local context when applicable, and explicit consent before calling.
- An implementation MUST NOT use a tel URI containing an unknown mandatory parameter. Mandatory extension names start with m-. An implementation MAY ignore an optional parameter for its own interpretation; that is not permission for a forwarder to delete or modify unknown optional parameters.
- Entities forwarding protocol requests containing tel URIs MUST NOT delete or modify optional parameters they do not understand. The fictional x-demo and m-demo names here are unregistered offline fixtures, not proposed deployed extensions.
- A client intending to call a local number MUST understand its phone-context and be able to place calls within it. Registration is not proof that an application understands an extension, that the number is owned by a trusted person, or that a call will connect.
- Web clients and similar tools MUST NOT place calls without explicit user consent. Calls may cost money or reveal caller information. HTML links SHOULD show the telephone number and SHOULD use global form on public pages (§8). The guide renders only inert text and illustrations, never actual tel links.
- RFC 5341 updates this publication by creating the tel URI parameter registry. New parameters and values MUST be registered with IANA and documented in an RFC or other permanent public specification. Its initial registry includes phone-context, ext and isub; it does not replace this entire URI scheme.
Fictional offline examples only: no dialer is opened and no call is placed. URI syntax does not verify number assignment, reachability, ownership or caller identity. Selected examples are not a complete telephone or SIP implementation.
Sources
New to this? Start hereA quick picture + helpful background
A number is not a dialing procedure
Think of a contact card: it names who to reach, while the phone system supplies the steps for making a connection. A tel URI similarly identifies a number; its context and parameters help interpret it but do not authorize a call or promise reachability. This is an analogy, not a telephone-routing algorithm.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RFC 5341 adds the IANA tel URI parameter registry and registration requirements. It updates RFC 3966 without obsoleting its telephone-number identifier scheme.
Read the updated RFC section ↗