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

Keith,

I see the attempt to define a URL scheme for local phone numbers to be
analogous to the "file:" scheme. It has some attractiveness, but it's
been a real problem in terms of interoperability and consistent operation,
and in the end, we should seriously question whether "useful some time"
is a good idea.

However, I am basing my views on my limited experience with a variety
of workstation auto-dial facilities, e.g., for GSM telephones (Trio),
for Windows (the windows TAPI interfaces), and a few other odds and ends
that I've tried.

The telephone dialer systems based on Windows TAPI rely on having telephone
numbers in a globalized form, parsed into country code, city/area code, number,
and then using localization rules for "dialing from" to create the actual
dial string. So the "URL" contains parsed information, and then the access
method translates that into, for example, the credit card authorization
string, depending on where you are dialing from.

General, in fact, if you enter in a telephone number in relative form
(I type in a local number) the directory entry software actually defaults
the rest of the information (country code & city/area code) from the local
context before inserting the phone number into the directory.

In the case of a single service provider, like my cellphone connection,
numbers are generally allowed in a universal form.

I think this is a reasonable model for a useful "Uniform Resource Locator"
system.

If we want to have a way of designating a 'local' number to mean
'by means of the local dial context of the interpretation of the URL',
we might want to have a 'local' naming authority, in the same way
that we had for 'file://localhost/', e.g.,

  tel://local/4123

meaning "dial 4123 no matter where you're calling from".

One reason for separating 'tel', 'modem' and 'fax' into separate
schemes is that for some kinds of equipment, these are actually different
methods of dialing.

> In some sense and under some circumstances phone numbers are a hierarchy, 
> but the divisions of hierarchy are not always intended to be exposed, 
> they're not consistent from one place to another, and are subject 
> to change.  Furthermore, the mapping from a local phone number to
> a global number often involves a more complex operation than simply
> prepending some additional digits.

The important algorithm is really the inverse: how to map a global phone
into a local dial string, and, while complex, seems to be well implemented,
at least for the software I see built into Windows 95 OSR2 and NT. That's
because the proposal is that URLs should (almost?) always consist of
the global number, and the dial software should map global numbers into
local dial strings. I vaguely remember something like this for GlobalFax
for the Macintosh, too.

And the divisions of hierarchy seem to be fairly uniform, at least according
to the "how to make a telephone call" listings from AT&T, MCI, Sprint, WorldNet
systems: from another country, you dial the country code, the city code,
and the local number; for some countries there is no 'city code', so you
just dial the contry code and the number. From within the country, the
dialing instructions are generally more complex but localized to that
context and seems to be built into the software. Yes, there are hundreds
of countries and possibly tens of methods.

I admit to only trying to dial from Germany, France, Switzerland, Australia,
Japan in the recent past.

My Nokia/PCS (GSM) telephone seems to accept both local numbers and
global numbers, where global numbers are prefixed with "+", and local
numbers are interpreted in the context of the service provider's view
of where my telephone is. "*1" gets me service wherever I am (even when
roaming), but a local number without any prefix seems to get +1 415
even when roaming outside of the bay area; this leads me to believe that
it is operating as if numbers entered on the telephone are supplied as
relative to a "base" which is built into the telephone.


> So I see little value in trying to make phone numbers fit into
> the URI notion of hierarchy. 

If this weren't how current telephone dialing software for mobile
devices worked, I would agree with you, but it seems to be _more_
consistent with currently deployed technology, at least as I interpret
it.

It would be useful to get more input from those who would implement
dialing from telephone URLs, though, before we invent something they
wouldn't implement. I'm glad you're planning to bring more of them
into the review process.

Larry

Received on Monday, 29 June 1998 10:51:21 UTC