Re: telephone URLs, comments on draft-antti-telephony-url-04

Vaha-Sipila Antti (
Fri, 26 Jun 1998 14:17:27 +0200

Message-Id: <>
From: "Vaha-Sipila Antti (NMP)" <>
To: "'EXT Larry Masinter'" <>
Cc: URI distribution list <uri@Bunyip.Com>,
Date: Fri, 26 Jun 1998 14:17:27 +0200
Subject: RE: telephone URLs, comments on draft-antti-telephony-url-04


(I am not sure whether this mail gets to URI mailing list since this
address has not subscribed it - if it doesn't, could someone please
forward it there? Thanks.)

You asked some valid questions, some of which have been addressed
earlier. I tried to dig into my archives of past mail and quote people
that have sent me mail, but unfortunately I haven't saved every piece of

L. Masinter:
> I suggest removing "local-phone-number". In the case of
> the fax specifications, there was always an 'offramp' to which
> the phone number was being made local, but in the case of the URL,
> there is no context.

This is true. Unfortunately, not all phone numbers are accessible using
a global numbering scheme. Such a case might be a freephone number which
is only accessible from a certain country; numbers under a company PBX;
network specific numbers (my mobile phone operator uses a three-number
code to access my voice mailbox), etc.

The concept of local numbers has been thought to be important by several
individuals, and I presume that this is not a minor issue when thinking
about telephone operators and their possible value-added services.

You mention later that it could be possible to support local phone
numbers with "post-dial" sequence, but this is not true since the
purpose of "post-dial" is to guide the user agent to send a string of
numbers to the telephone line using DTMF or pulse dialing. We cannot
presume that all user agents which require local numbering use DTMF or
pulse dialing to set up the call. Also, in my opinion, this would only
be a way to dodge this problem with an even worse solution.

What I would like to see would be some kind of meta-information in the
document in which the URL is found. This meta-information, in machine
readable (and parseable) form would describe the context in which the
URLs would be interpreted. How to include meta-information in web
documents in general is fortunately outside the scope of this document.

L. Masinter:
> A URL is a Uniform Resource Locator, and "uniform" means that a
> URL should identify the same resource no matter where it is accessed.

Yes, but doesn't the "locator" mean that information about the method of
getting to that location should also be present? URNs (uniform resource
names) are used it does not matter where the resource is accessed. Or
have I mixed up the terminology?

L. Masinter:
> If there is some context that is missing, then relative URL forms
> are used, with the base supplying the rest of the form.
> so that you would write 
>   phone://358/55/1234567;postd=pp22
> instead of
>   phone:+358-55-1234567;postd=pp22
> This is consistent with the URI generic syntax.

However, in this case, there might not be a "base" at all, since phone
numbers may indeed be dialable only from inside a certain network or a
branch exchange. Again, consider the special access number I have for my
voice mailbox: whenever I dial XXX from my mobile, I get there, but I
cannot do that from another phone, not even from another network than my
home network, no matter what I dialled.

In other words, phone numbers do not translate well into a hierarchical
structure. draft-fielding-uri-syntax-03.txt talks about an "authority
component" prefixed by "//", so that "authority component is typically
defined by an Internet-based server or a scheme-specific registry of
naming authorities". Most normal phone numbers have this structure
(their country code and operator/area prefixes are logical components).
However, a lot of phone numbers do not have these components, even if
they are not "local" numbers (in the sense that emergency numbers are
the same in a lot of countries, so they are effectively "local" for half
of the world).

This would then imply that support for local phone numbers should be
abandoned altogether, but this would remove much of the applicability
and the dreaded "market potential" from these URLs.

> I would like to (re)consider whether separate schemes for
> 'tel', 'fax' and 'modem' should be used, rather than having
> the 'call style' be a parameter, if such is necessary.
> The URL uniformly locates the resource, and doesn't need to
> specify the service that is to be obtained at that resource.

HTTP and FTP URLs both locate a resource - a file. Implicitly they also
specify which kind of connection has to be made to retrieve that file
(which protocol to use). Supposing that the resource is a
telecommunications equipment, this is directly analogous: the URL scheme
describes which type of call has to be made to get access to the
telecommunications equipment. (In some telephone networks, there are
really different "types" of calls, so it is not only the choice of
hardware which is used by the user agent to call out.)

If the URL does not have any information about whether the remote
resource is a telephone, a fax machine, or a modem, the URL is almost
unusable since it has no practical use. (Autodetection of the B
subscriber does not work if the underlying network needs to know the
call type when setting up the call.)

If there is a "call style" parameter, the resulting URL syntax might
become truly horrible, not easily memorizable, and prone to errors. The
original proposal (draft-antti-telephony-url-00.txt) tried to do just
this, and the general response was that separate URL schemes would be

L. Aronsson put it very nicely (when referring to -00.txt, which had a
call-type parameter):
> My general reaction to your proposal is that it is too complicated.
> If anything, I would like to cut away parts and options that will be
> seldom needed, and that only serve to confuse the user.  The user that
> I envision is a corporate webmaster or a teenager that wants to put
> telephone and fax numbers on a web page.  Their understanding of
> telephone technology is barely enough to write their numbers on a
> business card.  For an URL scheme to work, the syntax needs to be as
> simple as possible.

The same issue is addressed in draft-fielding-uri-syntax-03.txt:
> A URI often needs to be remembered by people, and it is easier
> for people to remember a URI when it consists of meaningful
> components.

"tel" and "fax" are often found in business cards; humans tend to write
down telephhone numbers using that notation. In this respect, this would
be in alignment with the "easy to remember" requirement.

Some other things that should have kept in mind:

IETF-FAX already published an RFC which specifies a format for phone
numbers. This syntax was almost directly copied to
draft-antti-telephony-url, since it was thought that it would be a
*good* thing to have a *single* syntax for phone numbers, whether they
are in mail addresses or URLs.

E.123, which is an ITU-T recommendation for phone numbers, uses the
"normal" notation. Splitting the phone numbers to a relative URL based
on their components is against the well-known practice of how people
write phone numbers, and since phone numbers have been around a bit
longer than URLs (almost a century?), in my opinion we should definitely
have "legacy support" here.

Also, I have been told that there already exist implementations for the
"tel" URL scheme, using the "normal" numbering system.

Phone numbers (in their international form) are unambiguous, and one
would need information on country codes and area prefixes if he would
like to create a hierarchical URL based on an E.123 style phone number.
The creator of the URL will potentially have to know all country codes
and area prefixes inside that country to be successfully able to write
down the URL. However, when someone is using a phone number to dial out,
he needs to know the local country and area codes in any case, even if
the URL was hierarchic.

Hopefully this answered some of your questions.

Best regards,


-- - Personal:
Replying to a mailing list? Cc: me.
Opinions are mine, not of my employer.