Should the plus in tel URIs be encoded?

Question

In a URI, spaces can be encoded as +. Since this is the case, should the leading plus be encoded when creating tel URIs with international prefix?

Which is better? Do both work in practice?

<a href="tel:+1234">Call me</a>
<a href="tel:%2B1234">Call me</a>

Interface

Answer 1

No.

From section 3 of RFC 3966 (The tel URI for Telephone Numbers):

If the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded.

You would only percent-encode a + if it’s part of a parameter value:

These characters ["+", ";", "=", and "?"] MUST be percent encoded if they appear in tel URI parameter values.

---

I’m not sure if the leading +, which indicates that it’s a global number, counts as delimiter, but the definition of a global number says:

Globally unique numbers are identified by the leading "+" character.

So it refers to +, not to something percent-encoded.

And also the examples make clear that it’s not supposed to be percent-encoded, e.g.:

tel:[phone]

---

Note that spaces in tel URIs (e.g., in parameter values) may not be encoded with a +. Using + instead of %20 for a space character is not something that may be done in any URI; it’s only possible in URIs whose URI scheme explicitly defines that.

Crwth

Answer 2

The tel: URI scheme doesn't have a provision for encoding spaces - see RFC 3966:

    5.1.1.  Separators in Phone Numbers

    ...

    even though ITU-T E.123 [E.123] recommends the use of space
       characters as visual separators in printed telephone numbers, "tel"
       URIs MUST NOT use spaces in visual separators to avoid excessive
       escaping.

The plus sign encodes a space specifically only in application/x-www-form-urlencoded (default content type for form submission - see W3C info re: forms). There's no valid way to encode a space in tel: URIs. See again RFC 3966 (page 5) for valid visual separators.

Hamel