Keep extensions, subaddresses and escapes separate
04A semicolon starts a parameter. Phone extensions and ISDN subaddresses are alternatives, and an escaped semicolon inside a value is not a new parameter.
In x-demo=a%3Bb, %3B represents a data semicolon. Splitting on literal semicolons first leaves one x-demo value; decoding it first would invent a second field.
Key idea: Split URI structure before interpreting escaped parameter data.
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.
- ISDN subaddress
- An Integrated Services Digital Network subaddress. It is distinct from a non-ISDN phone extension.
- Percent encoding
- A percent sign and two hexadecimal digits represent a data octet, such as %3B for a semicolon. Do not confuse escaped data with literal field delimiters.
Rules & examples
Split URI structure before interpreting escaped parameter data.
- The ext parameter identifies a non-ISDN phone extension. The isub parameter identifies an ISDN subaddress. At most one of ext and isub may appear in a tel URI; they MUST NOT be combined.
- Parameter names, phone-context, ext and isub MUST NOT appear more than once. If ext or isub is present it MUST come first, followed by phone-context when present, then other parameters in lexicographical order.
- Verified erratum 203 changes the isub value grammar from 1*uric to 1*paramchar. An unescaped semicolon is therefore not part of that subaddress value. Literal reserved +, ;, = and ? in parameter data MUST be percent encoded; delimiters themselves stay literal.
- The diagrams use explicitly fictional x-demo and z-demo parameters solely as offline syntax fixtures. They are not claimed as registered extensions. RFC 5341 §§3–4 requires registration and a public specification for new parameters or values; see chapter six.
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.