Subject: [Enum] E.164 mapping proposal

From: Peter Kurrasch <[email-masked]>
Date: Fri, 12 Nov 1999 19:19:23 -0600 (CST)

An internet-draft that I've submitted (draft-kurrasch-tmar-00.txt) presents
a URL scheme that I feel is germane to the current discussions taking place
regarding E.164 mapping.  I realize the draft as-is does not present a DNS-
level solution, but I nonetheless felt I would bring the topic up in the
event that it spurs further discussions.

The gist of the I-D is to express your tele-media address as a URL whose
general syntax is:

   tmar://<user>:<password>@<host>:<port>/<path>

where <user> represents you the *caller* and <path> identifies the *callee*,
expressed as a directory-like tree or as an E.164 number.

For example (as taken from the I-D), suppose you want to contact the gift
shop in the observation deck (called the "Skydeck") on the top floor of the
Sears Tower in downtown Chicago.  You could express that location as:

  tmar://local-telco.com/IL/Chicago/Sears_Tower/Skydeck/gift_shop

As the call originator, you probably don't care what that phone number is--
you just want the call to go through.  From your perspective, then, the end
resolution doesn't matter.  That is, if the gift_shop is part of an IP
network, fine; if it's part of the PSTN using SS7-like signalling, that's
good too.  This is equivalent to DNS in that when you specify a host.domain
address, you probably don't care what the actual IP address is.  Rather,
"the network" takes care of it so that your connection is made.

Continuing this example, if you happen to know that the gift shop phone
number is +1-312-555-6789 (just as an example), you could still express that
within the URL:

  tmar://local-telco.com/+1-312-555-6789

In this case, the ultimate routing is still determined "by the network" and
may or may not have the same path as the directory-like tree form.  Note
that the URL scheme also allows you to not specify a host so that you could
even write the URL as:

  tmar:///IL/Chicago/Sears_Tower/Skydeck/gift_shop      --or--
  tmar:///+1-312-555-6789

The E.164 mapping is accomplished by comparing the URL's path fragment with
a lookup table.  For example, the table could indicate that all paths that
start with "+1-312-555-67" should be directed to 'chicago-telco.com' for
further resolution.  Similarly, all paths starting with "/IL/Chicago/"
could be directed to the same 'chicago-telco.com' host.

I'll admit I'm being a little bit vague here, but I'm more than happy to
elaborate as the interest develops.  Until then, I would like to point out
the following:

1.  The tmar: scheme is adapted from the http: (or even ftp:) scheme, as
opposed to SIP which is adapted from the e-mail notation.  Part of the
motivation for this approach was to support a directory lookup function in
addition to providing a built-in password protection/firewall facility.
(The way the firewall would work is that before contacting someone behind
the firewall, you'd have to prove that you are someone who *should* be
contacting that person.)

2.  By specifying the location as a directory-like tree, this scheme
partially alleviates the need for DTMF signalling.  Specifically, you
wouldn't necessarily *have* to listen to a "press 1 to speak to customer
service, press 2 to speak to ..." menuing system.  But I wouldn't be so bold
as to suggest that DTMF is irrelevant--just that it would serve a different
purpose in this environment.

3.  TMAR stands for Tele Media Address Resolution, which is meant to
encompass more than just simple voice calls--examples of which include not
only video conferencing but also broadcast transmissions such as tv and
radio.  As such, some of the I-D considerations may not apply to the iptel
or enum groups.

Thanks for your time!

-- 

Peter Kurrasch
[email-masked]

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Scott Bradner <[email-masked]>
Date: Fri, 12 Nov 1999 20:34:10 -0500 (EST)

> tmar://<user>:<password>@<host>:<port>/<path>

in case anyone wonders, the IESG does not support the use
of cleartext passwords in IETF protocols

Scott