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

From: "Vaha-Sipila Antti (NMP)" <[email-masked]>
Date: Fri, 26 Jun 1998 14:17:27 +0200

Hello,

(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
discussion.

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
preferable.

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,

Antti

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Jun 1998 12:25:55 -0400

Keith and I have been approached by several people, and proposals, which
try to do something with E.164 numbers on the Internet. We talk about
everything from creating a usable URL (various people in various contexts),
mappings from E.164 numbers to Internet Hostnames, and using E.164 numbers
as DNs in X.500 where extra information about the subscriber can be stored.
There is also a discussion started regarding IN signalling on the Internet.

Because of these discussions, Keith and I will set up a meeting in Chicago
where we can discuss all of these issues.

So, please take it easy, and be assured that the AD's do know about all of
these discussions, and will take appropriate actions.

     Patrik Fältström
     Area Director
     Applications Area

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 27 Jun 1998 01:39:47 -0700

>code to access my voice mailbox), etc.

You can do that with a notation for local-only within the URI.
You don't need a separate scheme for that.

>have I mixed up the terminology?

A locator means it can be used to locate a resource.  It does not mean
the string contains location information.  For example, the http URL
defines names according to the naming authority of a particular server.
This does not mean you need to access that server in order to retrieve
a representation of that resource.  All that is needed is for the resource
namespace to be defined such that the client can determine a mechanism
for locating the resource.

There is only one naming authority (partitioned into sub-authorities)
for the entire telephone namespace.  Therefore, it makes sense to only
have one URL scheme for phone names.  The action to take (fax, talk,
etc.) should be independent of the URI.

>structure.

On the contrary.  What you described is a phone number with a
null national/regional context.  So define a representation of such
and put it in place of the national/regional context.

Phone numbers are a hierarchical structure.  You can tell that by the
way they are abbreviated in context.

>(which protocol to use).

Sorry, but that is completely wrong.  This is explained in the introduction
to the URI syntax spec.

....Roy

---

From: Keith Moore <[email-masked]>
Date: Sat, 27 Jun 1998 16:50:59 -0400

> etc.) should be independent of the URI.

Ahem...

"There is only one naming authority (partitioned into sub-authorities)
for the entire Internet DNS namespace.  Therefore, it makes sense to
only have one URL scheme for DNS names.  The action to take (http GET, 
http POST, ftp RETR, ftp STOR, ftp LIST, ftp *, telnet, mailto, ...)
should be independent of the URI."

(cough)

> way they are abbreviated in context.

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.

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

Keith

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 27 Jun 1998 15:00:22 PDT

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.

> 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.

> 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

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 27 Jun 1998 17:06:41 PDT

If it isn't clear, I withdraw the suggestion to (re)consider
unifying the tel/modem/fax schemes, as the rationale is clear.
Perhaps it would be useful to include the rationale in the document,
namely: some subscriber networks require different call-setup,
so the access methods are different, the same phone number accesses
different resources if the call is voice, fax, or modem.

> and the dreaded "market potential" from these URLs.

phone://us/911
   From anywhere in the US, dial 911
phone://local/911
   From anywhere, dial 911
phone:///911
   From anywhere, dial 911

> be in alignment with the "easy to remember" requirement.

Yes, I agree. But people are used to "//" in URLs anyway, too.

> are in mail addresses or URLs.

But mail addresses include a RHS which is the context of interpretation
for the 'local phone' which doesn't exist for a URL.

Consider the mapping:

   fax://fax.xerox.com/1234  ==> mailto:fax=[email-masked]

i.e., a 'fax' URL is mapped to 'use Internet-Fax to send mail
to the email address'.

> have "legacy support" here.

I would support an equivalence, e.g.,

   fax:+1-650-812-4333   ==  fax://1/650/812-4333

The E.123 notation for telephone numbers isn't a century old, though, and
at least in my circles less commonly understood. That is, I've had
to explain the "+ country-code city-code number" notation to a number
of people who understood what a URL was but weren't familiar with the
international numbering plan.

> "tel" URL scheme, using the "normal" numbering system.

I've heard this rumor, but it would be good to see if we could find these
implementors and get them into the discussion.

> down the URL.

I don't understand this.

I've gotten a number of business cards from Europe recently, and either
the international notation is clear (e.g., the city code is in parens) or
else the number is local, and I have to figure out the dial code by looking
up the country code. Are you saying that people will hand out their
international telephone number without being clear about which part of
the telephone number is the country code? Or is it just the division between
city/region/area code and the rest of the number? I could easily imagine
making

 phone://41/1234567
dial-equivalent to
 phone://41/123/4567
e.g., the area/city code is entirely optional.

Something like this (sorry if the BNF is a little sloppy):

  url ==    [ "phone" | "fax" | "modem" ] ":"  number options
  number == hierarchical-number | global-number
  hierarchical-number = [ "//" country-code ] [ "/" area-code ] local-number
  global-number = "+"  country-code [punctuation] [area-code [punctuation]]
local-number
  local-number = digit *(digit|punctuation)
  country-code = +digit
  area-code = +digit

> However, when someone is using a phone number to dial out,
> the URL was hierarchic

I didn't understand this. I think you're saying that "hierarchic URLs don't
remove the need to know the local country & area code", which I don't contest,
but I don't understand the relevance.

---

From: Dan Connolly <[email-masked]>
Date: Fri, 26 Jun 1998 16:07:01 -0400

I go back and forth on this one
(whether to use hierarchical syntax
or the established social convention for
phone number notation). Currently, I agree
with Mr. Antti: the only time you could
exploit the relative addressing is if
somehow you referenced a nearby phone
in the context of another phone call;
meanwhile, the mnemonic and transcribability
benefit of the ITU notation is considerable.

But I suggest you make the rationale
behind this design decision explicit in
the draft, and note that it's an exception
to the guidelines[1]

[1] Guidelines for new URL Schemes
2.1.2 Compatibility with relative URLs
http://www.ics.uci.edu/pub/ietf/uri/draft-ietf-urlreg-guide-02.txt

Thanks for digging through your archive, by
the way. I think if a bit more rationale
goes in the draft, it will save you that trouble
in the future.

-- 
Dan Connolly
http://www.w3.org/People/Connolly/
phone:+44-22-76-79508 (room at CERN in Geneva, 21-26 Jun 1998)