Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url)

From: [email-masked]
Date: Sun, 6 Jan 2002 19:35:05 EST

In a message dated 1/4/02 9:24:10 PM Eastern Standard Time, 
[email-masked] writes:

> The original motivation for the tel URL was not the same as its current 
>  usage. It was created to enable a PC with an internal fax/modem card to 
>  dial phone numbers when a URL is clicked. For example, when you click on 
>  tel:12345, your modem card would pick up and dial 12345. Since the URL 
>  is used directly to operate the modem, this is why things like pauses 
>  and post-dial digits were included.
>  
>  This usage is quite different from its usage to describe a telephony 
>  resource, which is how it is used in SIP.
>
I presume from your comments that you support a significant rewrite of RFC 
2806 and deletion of the things that were there to support PC/modem 
communication (like the AT command set I referred to) which would not be 
appropriate for specifying the destination telephone address.

Following are additional comments/thoughts on this subject:

Since the purpose is to define a telephony resource (a destination for a 
call), it would seem that there are three somewhat related uses for this url:

1. to represent the destination resource at the user interface for the human 
to enter/read
2. to represent the destination resource as seen by a user agent, for example 
in an A HREF html tag or the equivalent SIP user agent.
3. to represent the destination resource for inclusion in messages (e.g., in 
SIP)

In other signaling systems, the above would be distinct formats. In SIP, 
there is an assumption that these 3 uses must be the same format, as in HTTP, 
which has led to the difficulty with defining/understanding how to treat 
spaces and other things. It seems that, independent of whatever is done in 
SIP or in other protocols, the representation to the user should use exactly 
what is currently standardized in E.123. That is, the international number, 
which could include spaces, hyphens, or dots as visual separators or letters 
in place of numbers. When the tel: url is used internally (in an A HREF tag 
or in a signaling message), all visual separators would be removed and 
letters would be converted to the appropriate numbers.

There would need to be a specific decision on which of the procedure symbols 
defined in E.123 need to be included. My suggestions:

1. International prefix symbol - + used to indicate an international number 
(Note that this symbol is really defined in E.123 as indicating the need to 
dial an international prefix which is not included in the number since it 
depends on where one is dialing from. Here it is being used to indicate that 
an international number follows. This is pretty much the same in the end, but 
a slightly different definition.)
2. Parentheses - never used in an international number, but might be allowed 
in other numbers
3. Slash "/" to indicate multiple numbers - probably not allowed
4. ... to indicate in-dialing - actual uses of this are unknown
5. Tilde to indicate where another dial tone will occur - uses of this in 
real life as a part of the destination national or international number are 
unknown. It is defined in E.123 only as an indication to the human of where 
to expect another dial tone. It does not control signaling.

Representation of international numbers should be easy, since this is already 
defined in E.123. This results in a truely "uniform" resource locator.

If there is also a need to represent national numbers and private numbers, 
this causes difficulty in keeping them "uniform". Of course, E.123 defines 
the representation on printed material and includes the words "international" 
or "national" before the numbers, which the tel: url won't do. The absence of 
the "+" could mean national, however, the result is not "uniform" in the 
sense of being unique. Numbers from private number plans are much more of a 
problem since they are never unique.

Considering the three uses of the tel: url listed above: The representation 
at the user interface has a meaning only to that user. That is, the person 
understands the context of the number they enter or see. The representation 
within an A HREF html tag or equivalent has no knowledge of the context. 
Either it is unique (e.g., an international number) or the user agent must 
assume a context or determine it by other means. Within the signaling 
message, the context must be explicit. Here there is no reason to support 
national numbers, since they are just a subset of the international number. 
The user agent could always fill in the complete number. Private number plans 
must be supported, and some way to identify the context ("domain"?) is 
desired. I do not believe it should be a part of the tel: url, since the 
identification of the "domain" applies to other things besides the telephone 
number.

Since the purpose of the tel: url is to designate the destination resource, 
it should never include procedures for getting out of the originator's local 
environment. That is why dial tone detection and pauses, as used to control 
modems to get through the user's PBX, are not required.

Mike Pierce
Artel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Jan 2002 20:32:16 -0500

> appropriate for specifying the destination telephone address.

I was not supporting or not supporting anything, but merely making a 
statement of fact to help clarify.

> spaces and other things. 

No, there is no difficulty at all. Your beef seems to be with the URI 
concept in general, but issues like inclusion of spaces and other such 
things are well documented and understood within URIs. I would strongly 
oppose attempting to define three separate representations for the three 
things above.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 06 Jan 2002 21:00:44 -0500

> oppose attempting to define three separate representations for the three

One thing that makes tel URIs a bit different is this notion of visual
separators. I'm not really aware of other URI schemes that have the
notion of stripping certain "decorator" characters to arrive at a
canonical representation. Also, it is not clear to me that these have to
be in a URL. I don't see people putting tel URLs on a bus or business
card - everybody recognizes phone numbers just find without this. If the
tel URL is part of a web page, it's not visible to normal users that
don't watch the bottom status bar. Thus, something like

"Dial <a href="tel:+18005551212">(800) 555-1212</a> for directory
assistance."

is most likely and it doesn't matter that the URL itself doesn't support
() or spaces.

In any event, if we are to make progress on what is, after all, a fairly
small piece of the picture, I think we need to consider

- not breaking 2806 backwards-compatibility gratuitously.  This probably
precludes adding additional visual separators, unless people tell me
that implementations simply ignore punctuation until the first semicolon
(which would be a smart move...).

- describing features that are actually used. So far, a few people have
come forward indicating at least tepid support for phone-context and
maybe ISDN sub-addresses, so these are in the upcoming draft.

- removing features that might be interesting, but nobody seems to have
found a real-world use for. Various AT-style dial instructions and the
modem/fax URL schemes seem to fall into this category. If such a use is
identified in the future, both features can be added as separate drafts.
To make this possible for dial strings, I'll probably add wording that
anything after the first non-phonedigit character is to be ignored.
(This was in 2806, so this is not news:

   "If it is not supported, local entities MUST ignore everything in the
   dial string after the first <pause-character> and the user SHOULD be
   notified."

To repeat something I keep saying: eventually, we want to move things to
Draft Standard. Draft Standard requires two interoperable
implementations of every feature. Thus, this is the time to trim, not to
add.
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel