Subject: [apps-discuss] About the "tel:" URI

From: Stephan Bosch <[email-masked]>
Date: Wed, 04 Mar 2015 00:24:50 +0100

Hi,

I'm assuming this is the correct place to discuss this, since the iptel
WG is long concluded and I've seen some URI-related activity here recently.

I was testing my generic URI parser a bit and I encountered the "tel:"
URI in RFC 3966. I noticed the following ABNF rule in that RFC:

param-unreserved     = "[" / "]" / "/" / ":" / "&" / "+" / "$"

This describes part of the characters allowed unescaped in parameter
values of the "tel:" URI.

The generic URI specification in RFC 3986 states the following in
Section 3.2.2: "A host identified by an Internet Protocol literal
address, version 6 [RFC3513] or later, is distinguished by enclosing the
IP literal within square brackets ("[" and "]").  This is the only place
where square bracket characters are allowed in the URI syntax."

The generic URI ABNF in RFC 3986  matches that statement. Given the
param-unreserved ABNF rule stated above, the "tel:" URI would violate that.

Of course, RFC 3966 predates RFC 3986 and therefore the "tel:" URI would
conform to its predecessor. Section 12 of RFC 3966 states the following:
"The URI syntax now conforms to RFC 2396 [RFC2396]."

But does it? It don't think so. Section 2.4.3 of RFC 2396 states the
following:

"
Other characters are excluded because gateways and other transport
agents are known to sometimes modify such characters, or they are used
as delimiters.

unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
"

That is why the opaque_part ABNF rule in RFC 2396 does not allow a
literal "[" and "]" either, which is what the "tel:" URI body would need
to conform to.

I've seen no erratum or RFC that would address this issue. So, am I
missing something, or is this just an error that went unnoticed so far?

Regards,

Stephan.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 9 Mar 2015 05:32:22 +0000

On 3/3/15, 3:24 PM, "Stephan Bosch" <[email-masked]> wrote:

>3966

---

From: Larry Masinter <[email-masked]>
Date: Mon, 9 Mar 2015 05:32:20 +0000

This is a problem no one noticed before. RFC 3966 (‘tel’) allows [ ] in places where RFC 3986 (generic URI syntax) doesn’t.

If there were applications that used [ ] in parameters, then we could talk about changing 3986 and the “URL mess”, but I can’t seem to find any explanation of how one might use [] in parameters applied to a telephone number, so perhaps the conflict is moot. 

Larry

Is there any planned discussion of the URL/URI/IRI situation? No BOF, no discussion in the apps area working group agenda?

On 3/3/15, 3:24 PM, "Stephan Bosch" <[email-masked]> wrote:

>IP literul within square brackets ("[" and "]").  This is the only place
>_______________________________________________
>apps-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 09 Mar 2015 17:01:33 +0100

Hi Larry,

> This is a problem no one noticed before. RFC 3966 (‘tel’) allows [ ] in places where RFC 3986 (generic URI syntax) doesn’t.

Ok.

> If there were applications that used [ ] in parameters, then we could talk about changing 3986 and the “URL mess”, but I can’t seem to find any explanation of how one might use [] in parameters app…

If no applications depend on it, I'd propose prohibiting "[" and "]" in 
an erratum to RFC 3966 (or even a new RFC if that is what it takes); new 
tel URI parameters may be defined in the future and it should be made 
clear that those characters cannot used in parameters without escaping.

> Is there any planned discussion of the URL/URI/IRI situation? No BOF, no discussion in the apps area working group agenda?

Not that I've seen.

I did notice some past discussions about SIP URIs vs RFC 3986 in some 
IETF mailing list (can't remember which one). Those also violate RFC 
3986, because these allow IP6 literals with "[" and "]" inside an URI 
component that is not //authority. IAX URIs have similar issues.

Regards,

Stephan.