Here is one of the comments currently outstanding
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: Worley, Dale R (Dale) [mailto:dworley at avaya.com]
Sent: Monday, May 03, 2010 1:58 PM
To: Zehler, Peter; sipcore at ietf.org
Subject: RE: [sipcore] Review request: Dial String syntax for the "tel"
URI Scheme
________________________________________
From: sipcore-bounces at ietf.org [sipcore-bounces at ietf.org] On Behalf Of
Zehler, Peter [Peter.Zehler at xerox.com]
The draft title is "Dial String syntax for the "tel" URI Scheme" and it
can be retrieved from
<http://tools.ietf.org/html/draft-zehler-teldial-info-00>. It proposes
three "tel" URI schemes parameters that cover pre-dialing, post-dialing
and T.33 subaddressing. The post-dialing and T.33 subaddressing are
adopted from the now obsolete rfc2806 but updated for tfc3966 syntax.
Pre-dial was created to avoid obfuscation of the resource identified by
the URI. Rfc2806 allowed the pre-dial string to be included in the tel:
URI.
________________________________________
In regard to subaddressing, this is a good idea, since the subaddressed
destination is a descrete entity with a name that is unique within the
context of the E.164 number.
In regard to "dial strings", I think this is not a good idea. A "dial
string" is the specific routing from one location to one destination.
It isn't a name for the destination, and it really isn't a URL, as there
is the implication that a URL is globally valid. What you are
attempting to do is create a URL-like string which is the dialing
instructions to reach a particular destination from a particular origin
and which also makes explicit the E.164 address of the destination. It
has no portability at all.
Also, the commonest transformation that is applied to convert E.164
numbers to dial strings is the removal of the country and city codes
from the beginning of the E.164 number, and the draft has no mechanism
for specifying that.
I think a better approach would be to see if the context concept of RFC
3966 solves the problem, that is, the device which is acting on the tel
URI should be provisioned with an appropriate converstion table from
telephone numbers to dialing actions.
If you really need to transport a string of dialing instructions from
one element to another, it would be much safer to define a new
namespace. E.g., "dial:w9w01118005551212".
Dale
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.