From enum-admin@ietf.org Mon Nov 1 00:14:13 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00034 for ; Mon, 1 Nov 1999 00:14:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA22440; Mon, 1 Nov 1999 00:14:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA22414 for ; Mon, 1 Nov 1999 00:14:04 -0500 (EST) Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00007 for ; Mon, 1 Nov 1999 00:14:03 -0500 (EST) Received: from john (d433-ps0-mel.alphalink.com.au [203.62.181.179]) by mail.alphalink.com.au (8.9.3/8.6.9) with SMTP id QAA28017 for ; Mon, 1 Nov 1999 16:13:47 +1100 Message-Id: <3.0.5.32.19991101161230.00809bc0@pop.alphalink.com.au> X-Sender: jperkins@pop.alphalink.com.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 01 Nov 1999 16:12:30 +1100 To: enum@ietf.org From: John Perkins Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Enum] proposal for a fax number - email address lookup Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Greetings. I have raised the proposal as outlined below, in the ieft-fax list, and was kindly referred to this list which I have now joined. It seems like it is within the goals of the group. I re-post my proposal below, and perhaps I may be advised to what extent the proposal may or may not be satisfied by the work of this group, and of any other comments. I had in mind a cgi sript type implementation but obviously a DNS based system is better. Pardon my ignorance (I looked for an achive but none was there). Could someone eloborate the following acronyms for me please? ENUM? MIB? BOF? Proposal -------- I would like to propose a universally accessible database or lookup procedure whereby individuals may validly and voluntarily nominate an email address to be associated with their fax telephone number. Database entries could be set up at a web site administered by a suitable authority or in conjuction with telephone companies. The email address would be for use as an alternative destination to the fax number under certain conditions. The email address would be retrieved by suitable URL reference which would include the phone number. The alternative email address could be used when for example the fax line was busy or unavailable, and would receive the fax as a TIFF attachment. The database facility would enable automatic contingency routing. The database may reside on a server accessed by cgi scripts or may take some other form compatible with the infrastructure. Background ---------- A large number of phone lines which are used as dial-up lines for Internet access are also used at other times for voice or fax traffic. There now exist schemes such as Internet call diversion whereby an incoming voice call to a PSTN number can be converted to an IP voice call in the event that the number is currenty busy with an IP connection. This requires that the user pre-register for the service with the telco and have certain software loaded and running in the event that a call is received. It may increasingly be the case that phone lines previously dedicated to fax may similarly be used for occasional dial-up Internet access. A scheme similar to Internet call diversion could be implemented whereby the dial-up subscriber installs suitable software to receive a real time fax, converted to IP by the telco. An easier alternative would be for the fax message to be encapsulated as a TIFF and forwarded by email. Various parties may wish to perform this service. The availbility of a universal database to facilitate this would be of benefit to consumers. vendors and (possibly) telcos alike. Security issues --------------- The possibility of mis-use may be the most serious implementation obstacle. Certain users may wish to partake of this service, in co-operation with their telco, in a such a way that the email address is not divulged. In that case they may have to pay for a service which may otherwise be free. (It is always a free call to find out if a number is busy). Some security would be afforded by operator fax receipt confirmation. After registration, the email address would not become operational before validation by the fax line owner. This could be done by the registation process sending a fax message to the desinated fax number containing a code which must be correctly entered into a confirmation message sent from the designated email address. -------------------------------------------------------- John Perkins Exfax Technologies Pty Ltd PO Box 6004 Melbourne Australia 3004 Tel +61 3 9534 5495 Fax +61 3 9534 8994 http://www.exfax.com -------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 2 13:11:04 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02012 for ; Tue, 2 Nov 1999 13:11:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA15050; Tue, 2 Nov 1999 13:10:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA15016 for ; Tue, 2 Nov 1999 13:10:25 -0500 (EST) Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01702 for ; Tue, 2 Nov 1999 13:10:24 -0500 (EST) Received: from scott.metatel.office (metatel.ne.mediaone.net [24.128.100.134]) by devonshire.cnchost.com id NAA29919; Tue, 2 Nov 1999 13:07:01 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Date: Tue, 2 Nov 1999 13:08:44 -0500 (EST) From: Scott Petrack X-Sender: scott.petrack@scott.metatel.office To: e164-to-ip@lserv.vocaltec.com, enum@ietf.org cc: sip@lists.research.bell-labs.com, confctrl@ISI.EDU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Enum] New ENUM WG and mailing list Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ENUM (tElephone NUmber Mapping) has been chartered by the IESG as a WG. The description is as follows: This working group will define a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g. URLs) which can be used to contact a resource associated with that number. The charter can be read at: http://www.ietf.org/html.charters/enum-charter.html A new ENUM mailing list has been set up, and is as of now the official mailing list of the ENUM WG. The address is enum@ietf.org; to subscribe, send mail to enum-request@ietf.org. The archive is at: ftp://ftp.ietf.org/ietf-mail-archive/enum/ The e164-to-ip list remains the place for more general discussion of things; the ENUM list is for the more restricted DNS-based work of ENUM. You will NOT automatically be transferred from the e164-to-ip list to the ENUM list, so please do this yourself. The first WG meeting is scheduled for Monday in Washington. For people who were not involved when the WG was formed, it may be helpful for me to state that this WG is restricted to a DNS-based solution. It is not that other solutions are not possible or interesting to the IETF -- they are. But THIS working group is chartered to find out the best possible DNS-based solution. It is certainly an important part of our work to discover the limitations of DNS-based solutions (should there be any ;-)). But solutions that are based on other architectures (IETF or otherwise) are not within our scope. We have lots of work to do, and very interesting work it is too. I am looking forward to it, and hope you are too. Scott _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 9 23:53:53 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02905 for ; Tue, 9 Nov 1999 23:53:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA00746; Tue, 9 Nov 1999 23:53:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA00713 for ; Tue, 9 Nov 1999 23:53:04 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02555 for ; Tue, 9 Nov 1999 23:53:12 -0500 (EST) Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhorj02712; Wed, 10 Nov 1999 04:57:26 GMT Received: from dynamicsoft.com (dhcp45-lt205.lt.ietf.innovationslab.net [130.128.45.205]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id XAA11374; Tue, 9 Nov 1999 23:53:12 -0500 (EST) Message-ID: <3828FAC3.E0B651BA@dynamicsoft.com> Date: Tue, 09 Nov 1999 23:55:31 -0500 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Steer CC: iptel@lists.research.bell-labs.com, enum@ietf.org References: <4.2.0.58.19991109224552.03c22170@10.173.17.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit This function is useful, but I'm not sure it needs to be in TRIP. The mapping from +1 603 to a name for that area code is not dynamic, nor different from provider to provider. One could actually have a global database, where you look up a phone prefix, and get out a textual name. Interestingly, enum was just chartered as a working group to look up a phone number in DNS, and get something out, where that something is generally a URL. But, it could be a piece of text. Also, does enum allow us to lookup just a phone prefix, not a complete number? I would presume so. (I'm ccing the enum list on this for comment) -Jonathan R. Jon Steer wrote: > > Currently, in the IP world, if I want to understand a route in > a human readable form, traceroute can use DNS to potentially > gather the names of the routers/domains along the route. > > For the E.164 address space, this isn't the case, without a > fixed, hand-generated database. > > I believe that there is an opportunity to provide some extended > "callerid" and management functionality if the originating LS includes > human readable text when advertising a route. > > For example, if the LS advertises the E.164 1603xxxx route, a textual > attribute > containing NewHampshire would enable the front ends of LS servers to gather > and display address spaces. > > jon > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 10 07:11:01 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28105 for ; Wed, 10 Nov 1999 07:11:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA19779; Wed, 10 Nov 1999 07:10:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA19748 for ; Wed, 10 Nov 1999 07:10:16 -0500 (EST) Received: from nuplanet.bitscout.com (gnatplanet.bitscout.com [198.137.170.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27875 for ; Wed, 10 Nov 1999 07:10:27 -0500 (EST) Received: from wrkplanet ([10.173.17.30]) by nuplanet.bitscout.com (2.0 Build 2144 (Berkeley 8.8.4)/8.8.4) with ESMTP id GAA00927; Wed, 10 Nov 1999 06:37:07 -0500 Message-Id: <4.2.0.58.19991110070756.039d4be0@10.173.17.1> X-Sender: jsteer@10.173.17.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 10 Nov 1999 07:10:16 -0500 To: Jonathan Rosenberg From: Jon Steer Cc: iptel@lists.research.bell-labs.com, enum@ietf.org In-Reply-To: <3828FAC3.E0B651BA@dynamicsoft.com> References: <4.2.0.58.19991109224552.03c22170@10.173.17.1> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_72169687==_.ALT" Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_72169687==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote: >This function is useful, but I'm not sure it needs to be in TRIP. The >mapping from +1 603 to a name for that area code is not dynamic, nor >different from provider to provider. But what is dynamic is an enterprise phone destination for example when a company buys a large block of 1603884 >One could actually have a global >database, where you look up a phone prefix, and get out a textual name. Those exist already, however, they cannot be dynamically added to when new blocks of numbers are allocated (i.e. new area codes or new large enterprise blocks of numbers). >Interestingly, enum was just chartered as a working group to look up a >phone number in DNS, and get something out, where that something is >generally a URL. But, it could be a piece of text. > >Also, does enum allow us to lookup just a phone prefix, not a complete >number? I would presume so. > >(I'm ccing the enum list on this for comment) > >-Jonathan R. > >Jon Steer wrote: > > > > Currently, in the IP world, if I want to understand a route in > > a human readable form, traceroute can use DNS to potentially > > gather the names of the routers/domains along the route. > > > > For the E.164 address space, this isn't the case, without a > > fixed, hand-generated database. > > > > I believe that there is an opportunity to provide some extended > > "callerid" and management functionality if the originating LS includes > > human readable text when advertising a route. > > > > For example, if the LS advertises the E.164 1603xxxx route, a textual > > attribute > > containing NewHampshire would enable the front ends of LS servers to > gather > > and display address spaces. > > > > jon > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > >-- >Jonathan D. Rosenberg 200 Executive Drive >Chief Scientist Suite 120 >dynamicsoft West Orange, NJ 07052 >jdrosen@dynamicsoft.com FAX: (732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > >--------- >This message came from the IETF IPTEL Working Group Mailing List. --=====================_72169687==_.ALT Content-Type: text/html; charset="us-ascii" At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote:
This function is useful, but I'm not sure it needs to be in TRIP. The
mapping from +1 603 to a name for that area code is not dynamic, nor
different from provider to provider.


But what is dynamic is an enterprise phone destination
for example when a company buys a large block of 1603884


One could actually have a global
database, where you look up a phone prefix, and get out a textual name.

Those exist already, however, they cannot be dynamically added to
when new blocks of numbers are allocated (i.e. new area codes or
new large enterprise blocks of numbers).


Interestingly, enum was just chartered as a working group to look up a
phone number in DNS, and get something out, where that something is
generally a URL. But, it could be a piece of text.

Also, does enum allow us to lookup just a phone prefix, not a complete
number? I would presume so.

(I'm ccing the enum list on this for comment)

-Jonathan R.

Jon Steer wrote:
>
> Currently, in the IP world, if I want to understand a route in
> a human readable form, traceroute can use DNS to potentially
> gather the names of the routers/domains along the route.
>
> For the E.164 address space, this isn't the case, without a
> fixed, hand-generated database.
>
> I believe that there is an opportunity to provide some extended
> "callerid" and management functionality if the originating LS includes
>   human readable text when advertising a route.
>
>   For example, if the LS advertises the E.164 1603xxxx route, a textual
> attribute
>   containing NewHampshire would enable the front ends of LS servers to gather
>   and display address spaces.
>
>   jon
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen        PHONE: (732) 741-7244
http://www.dynamicsoft.com

---------
This message came from the IETF IPTEL Working Group Mailing List.
--=====================_72169687==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 10 10:16:34 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25952 for ; Wed, 10 Nov 1999 10:16:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA25011; Wed, 10 Nov 1999 10:14:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24974 for ; Wed, 10 Nov 1999 10:14:27 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24834 for ; Wed, 10 Nov 1999 10:14:35 -0500 (EST) Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhosz18204; Wed, 10 Nov 1999 15:18:49 GMT Received: from dynamicsoft.com (dhcp22-fh199.fh.ietf.innovationslab.net [130.128.22.199]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id KAA11852; Wed, 10 Nov 1999 10:14:33 -0500 (EST) Message-ID: <38298C68.C008F7E4@dynamicsoft.com> Date: Wed, 10 Nov 1999 10:16:56 -0500 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Steer CC: iptel@lists.research.bell-labs.com, enum@ietf.org References: <4.2.0.58.19991109224552.03c22170@10.173.17.1> <4.2.0.58.19991110070756.039d4be0@10.173.17.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Jon Steer wrote: > > At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote: > > > This function is useful, but I'm not sure it needs to be in TRIP. > > The > > mapping from +1 603 to a name for that area code is not dynamic, nor > > different from provider to provider. > > But what is dynamic is an enterprise phone destination > for example when a company buys a large block of 1603884 Perhaps dynamic is not the right word. I agree something like that needs to be covered. The difference is that if company foo buys 1603884, this number is mapped to foo for everyone that asks. TRIP is great at distributing information with parameters that are different for different peers. What you want to do can be done using a global (with updates) directory service, which is exactly what enum is. > > > One could actually have a global > > database, where you look up a phone prefix, and get out a textual > > name. > > Those exist already, however, they cannot be dynamically added to > when new blocks of numbers are allocated (i.e. new area codes or > new large enterprise blocks of numbers). Whilst the enum group won't address how updates take place, certainly the database itself won't be useful if it can't be updated. DNS can certainly be updated; the timescales of the updates we need for this service are doable using administrative updates, as opposed to real time protocol based updates. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 10 12:33:13 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02338 for ; Wed, 10 Nov 1999 12:33:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00359; Wed, 10 Nov 1999 12:32:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00326 for ; Wed, 10 Nov 1999 12:32:35 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02080 for ; Wed, 10 Nov 1999 12:32:43 -0500 (EST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Wed, 10 Nov 1999 11:32:25 -0600 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id V5BRGQX0; Wed, 10 Nov 1999 12:32:22 -0500 Received: from msquire (extranet-139-116.corpeast.baynetworks.com [132.245.139.116]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WMJAFMZ8; Wed, 10 Nov 1999 12:32:18 -0500 Message-Id: <3.0.32.19991110122843.00af79b0@zbl6c008.corpeast.baynetworks.com> X-Sender: msquire@zbl6c008.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 10 Nov 1999 12:28:43 -0500 To: Jonathan Rosenberg , Jon Steer From: "Matt Squire" Cc: iptel@lists.research.bell-labs.com, enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org One problem that arises when you think about putting this type of information into TRIP is that TRIP is **not** global. What I mean is that the TRIP framework specifically indicates that TRIP is used within confederations, and that not all confederations are interconnected. What you seem to need is a global directory that is shared among all providers - this is not TRIP. It would definitely be useful, but I don't think it fits here. - Matt _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 10 16:29:06 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23169 for ; Wed, 10 Nov 1999 16:29:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07628; Wed, 10 Nov 1999 16:27:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07597 for ; Wed, 10 Nov 1999 16:27:29 -0500 (EST) Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22398 for ; Wed, 10 Nov 1999 16:27:36 -0500 (EST) Received: from glock (dallas-nt-89.cisco.com [171.68.37.89]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id NAA09684; Wed, 10 Nov 1999 13:27:00 -0800 (PST) Message-ID: <01e401bf2bc2$52fe23a0$592544ab@cisco.com> From: "Stephen Sprunk" To: "Jonathan Rosenberg" , "Jon Steer" Cc: , References: <4.2.0.58.19991109224552.03c22170@10.173.17.1> <4.2.0.58.19991110070756.039d4be0@10.173.17.1> Date: Wed, 10 Nov 1999 15:26:18 -0600 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DB_01BF2B8F.EF9B18E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01DB_01BF2B8F.EF9B18E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The purchase of a block of phone numbers is generally static in that it = doesn't change on a real-time basis; generally blocks of numbers will = stay with their owners for months to years. The actual line assignments = can be delegated to the current owner by the telco. This is the = timeframe and hierarchy that DNS (and therefore enum) is perfect for. = Also, TRIP (and BGP) is based on business relationships, administrative = policy, and reachability. This doesn't apply to a E.164<->entity = mapping. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: NSA, Network Consulting Engineer=20 :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Pager: 800-365-4578 / 800-901-6078 C I S C O S Y S T E M S Email: ssprunk@cisco.com ----- Original Message -----=20 From: Jon Steer=20 To: Jonathan Rosenberg=20 Cc: iptel@lists.research.bell-labs.com ; enum@ietf.org=20 Sent: Wednesday, November 10, 1999 6:10 Subject: Re: Human readable Route descriptors At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote: This function is useful, but I'm not sure it needs to be in TRIP. = The mapping from +1 603 to a name for that area code is not dynamic, nor different from provider to provider.=20 But what is dynamic is an enterprise phone destination for example when a company buys a large block of 1603884 One could actually have a global database, where you look up a phone prefix, and get out a textual = name. Those exist already, however, they cannot be dynamically added to when new blocks of numbers are allocated (i.e. new area codes or new large enterprise blocks of numbers). Interestingly, enum was just chartered as a working group to look up = a phone number in DNS, and get something out, where that something is generally a URL. But, it could be a piece of text. Also, does enum allow us to lookup just a phone prefix, not a = complete number? I would presume so. (I'm ccing the enum list on this for comment) -Jonathan R. Jon Steer wrote: >=20 > Currently, in the IP world, if I want to understand a route in > a human readable form, traceroute can use DNS to potentially > gather the names of the routers/domains along the route. >=20 > For the E.164 address space, this isn't the case, without a > fixed, hand-generated database. >=20 > I believe that there is an opportunity to provide some extended > "callerid" and management functionality if the originating LS = includes > human readable text when advertising a route. >=20 > For example, if the LS advertises the E.164 1603xxxx route, a = textual > attribute > containing NewHampshire would enable the front ends of LS = servers to gather > and display address spaces. >=20 > jon >=20 > --------- > This message came from the IETF IPTEL Working Group Mailing List. --=20 Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120=20 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. ------=_NextPart_000_01DB_01BF2B8F.EF9B18E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The purchase of a block of phone numbers is generally static in = that it=20 doesn't change on a real-time basis; generally blocks of numbers will = stay with=20 their owners for months to years.  The actual line = assignments can be=20 delegated to the current owner by the telco.  This is the = timeframe=20 and hierarchy that DNS (and therefore enum) is perfect for.  Also, = TRIP=20 (and BGP) is based on business relationships, administrative policy, and = reachability.  This doesn't apply to a E.164<->entity = mapping.
 
S
 
    =20 |         =20 |         Stephen Sprunk, K5SSS, = CCIE=20 #3723
    = :|:       =20 :|:        NSA, Network Consulting = Engineer=20
   :|||:     =20 :|||:       14875 Landmark Blvd #400; = Dallas,=20 TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 /=20 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com
----- Original Message -----
From:=20 Jon = Steer=20
To: Jonathan=20 Rosenberg
Cc: iptel@lists.research.bell-labs= .com=20 ; enum@ietf.org
Sent: Wednesday, November 10, = 1999=20 6:10
Subject: Re: Human readable = Route=20 descriptors

At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg = wrote:
This function is useful, but I'm not = sure it=20 needs to be in TRIP. The
mapping from +1 603 to a name for that = area code=20 is not dynamic, nor
different from provider to provider.=20


But what is dynamic is an enterprise phone=20 destination
for example when a company buys a large block of=20 1603884


One could actually have a = global
database,=20 where you look up a phone prefix, and get out a textual=20 name.

Those exist already, however, they cannot be = dynamically=20 added to
when new blocks of numbers are allocated (i.e. new area = codes=20 or
new large enterprise blocks of numbers).


Interestingly, enum was just chartered = as a=20 working group to look up a
phone number in DNS, and get something = out,=20 where that something is
generally a URL. But, it could be a piece = of=20 text.

Also, does enum allow us to lookup just a phone prefix, = not a=20 complete
number? I would presume so.

(I'm ccing the enum = list on=20 this for comment)

-Jonathan R.

Jon Steer = wrote:
>=20
> Currently, in the IP world, if I want to understand a route = in
> a human readable form, traceroute can use DNS to=20 potentially
> gather the names of the routers/domains along = the=20 route.
>
> For the E.164 address space, this isn't the = case,=20 without a
> fixed, hand-generated database.
>
> I = believe=20 that there is an opportunity to provide some extended
> = "callerid" and=20 management functionality if the originating LS = includes
>  =20 human readable text when advertising a route.
> =
>  =20 For example, if the LS advertises the E.164 1603xxxx route, a=20 textual
> attribute
>   containing = NewHampshire would=20 enable the front ends of LS servers to gather
>   = and=20 display address spaces.
>
>   jon
> =
>=20 ---------
> This message came from the IETF IPTEL Working = Group=20 Mailing List.

--
Jonathan D.=20 = Rosenberg          &nbs= p;           =20 200 Executive Drive
Chief=20 = Scientist          &nbs= p;            = ;     =20 Suite 120=20 =
dynamicsoft         &nbs= p;            = ;          =20 West Orange, NJ=20 = 07052
jdrosen@dynamicsoft.com       = ;            =  =20 FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen   &= nbsp;   =20 PHONE: (732) 741-7244
http://www.dynamicsoft.com

---------
Thi= s=20 message came from the IETF IPTEL Working Group Mailing=20 List.
------=_NextPart_000_01DB_01BF2B8F.EF9B18E0-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 10 17:11:51 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14134 for ; Wed, 10 Nov 1999 17:11:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA09057; Wed, 10 Nov 1999 17:10:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA09021 for ; Wed, 10 Nov 1999 17:10:55 -0500 (EST) Received: from nuplanet.bitscout.com (gnatplanet.bitscout.com [198.137.170.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13748 for ; Wed, 10 Nov 1999 17:11:02 -0500 (EST) Received: from wrkplanet ([10.173.17.30]) by nuplanet.bitscout.com (2.0 Build 2144 (Berkeley 8.8.4)/8.8.4) with ESMTP id QAA01009; Wed, 10 Nov 1999 16:37:37 -0500 Message-Id: <4.2.0.58.19991110170009.03a3df00@10.173.17.1> X-Sender: jsteer@10.173.17.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 10 Nov 1999 17:10:48 -0500 To: "Stephen Sprunk" , "Jonathan Rosenberg" From: Jon Steer Cc: , In-Reply-To: <01e401bf2bc2$52fe23a0$592544ab@cisco.com> References: <4.2.0.58.19991109224552.03c22170@10.173.17.1> <4.2.0.58.19991110070756.039d4be0@10.173.17.1> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_108203156==_.ALT" Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_108203156==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:26 PM 11/10/99 -0600, Stephen Sprunk wrote: >The purchase of a block of phone numbers is generally static in that it >doesn't change on a real-time basis; generally blocks of numbers will stay >with their owners for months to years. Hopefully, one of the things that IP telephony brings is the ability to define new services one that might require dynamic addresses. > The actual line assignments can be delegated to the current owner by the > telco. This presumes that all E.164 addresses that TRIP advertises are RBOC telco visible and not a private numbering system perhaps implemented by an ISP. > This is the timeframe and hierarchy that DNS (and therefore enum) is > perfect for. Also, TRIP (and BGP) is based on business relationships, > administrative policy, and reachability. This doesn't apply to a > E.164<->entity mapping. I keep sensing that the implied model here is that only large blocks of numbers are represented by routes. BGP scales down to very small subnets (like 4 address subnets), I'm not sure why Trip isn't going to . For example, I pay my ISP to allow me to setup a dynamic route to handle a weekly videoconference. I'm paying my ISP by bandwidth, not by line. I want the ISP to route my calls to my video unit. When I call outwards from my dynamic video endpoint, it would be nice to deliver the human readable callerid to the other end. >>----- Original Message ----- >>From: Jon Steer >>To: Jonathan Rosenberg >>Cc: >>iptel@lists.research.bell-labs. >>com ; enum@ietf.org >>Sent: Wednesday, November 10, 1999 6:10 >>Subject: Re: Human readable Route descriptors >> >>At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote: >>>This function is useful, but I'm not sure it needs to be in TRIP. The >>>mapping from +1 603 to a name for that area code is not dynamic, nor >>>different from provider to provider. >> >> >>But what is dynamic is an enterprise phone destination >>for example when a company buys a large block of 1603884 >> >> >>>One could actually have a global >>>database, where you look up a phone prefix, and get out a textual name. >> >>Those exist already, however, they cannot be dynamically added to >>when new blocks of numbers are allocated (i.e. new area codes or >>new large enterprise blocks of numbers). >> >> >>>Interestingly, enum was just chartered as a working group to look up a >>>phone number in DNS, and get something out, where that something is >>>generally a URL. But, it could be a piece of text. >>> >>>Also, does enum allow us to lookup just a phone prefix, not a complete >>>number? I would presume so. >>> >>>(I'm ccing the enum list on this for comment) >>> >>>-Jonathan R. >>> >>>Jon Steer wrote: >>> > >>> > Currently, in the IP world, if I want to understand a route in >>> > a human readable form, traceroute can use DNS to potentially >>> > gather the names of the routers/domains along the route. >>> > >>> > For the E.164 address space, this isn't the case, without a >>> > fixed, hand-generated database. >>> > >>> > I believe that there is an opportunity to provide some extended >>> > "callerid" and management functionality if the originating LS includes >>> > human readable text when advertising a route. >>> > >>> > For example, if the LS advertises the E.164 1603xxxx route, a textual >>> > attribute >>> > containing NewHampshire would enable the front ends of LS servers >>> to gather >>> > and display address spaces. >>> > >>> > jon >>> > >>> > --------- >>> > This message came from the IETF IPTEL Working Group Mailing List. >>> >>>-- >>>Jonathan D. Rosenberg 200 Executive Drive >>>Chief Scientist Suite 120 >>>dynamicsoft West Orange, NJ 07052 >>>jdrosen@dynamicsoft.com FAX: (732) 741-4778 >>>http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >>>http://www.dynamicsoft.com >>> >>>--------- >>>This message came from the IETF IPTEL Working Group Mailing List. --=====================_108203156==_.ALT Content-Type: text/html; charset="us-ascii" At 03:26 PM 11/10/99 -0600, Stephen Sprunk wrote:
The purchase of a block of phone numbers is generally static in that it doesn't change on a real-time basis; generally blocks of numbers will stay with their owners for months to years.

 Hopefully, one of the things that IP telephony brings is the ability to define new services one that might
 require dynamic addresses.

 The actual line assignments can be delegated to the current owner by the telco.

This presumes that all E.164 addresses that TRIP advertises are RBOC telco visible and not
a private numbering system perhaps implemented by an ISP.


 This is the timeframe and hierarchy that DNS (and therefore enum) is perfect for.  Also, TRIP (and BGP) is based on business relationships, administrative policy, and reachability.  This doesn't apply to a E.164<->entity mapping.


I keep sensing that the implied model here is that only large blocks of numbers are represented by routes. BGP scales
down to very small subnets (like 4 address subnets), I'm not sure why Trip isn't going to .


For example, I pay my ISP to allow me to setup a dynamic route to handle a weekly videoconference. I'm paying
my ISP by bandwidth, not by line.  I want the ISP to route my calls to my video unit.

When I call outwards from my dynamic video endpoint, it would be nice to deliver the human readable
callerid to the other end.

----- Original Message -----
From: Jon Steer
To: Jonathan Rosenberg
Cc: iptel@lists.research.bell-labs.com ; enum@ietf.org
Sent: Wednesday, November 10, 1999 6:10
Subject: Re: Human readable Route descriptors

At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote:
This function is useful, but I'm not sure it needs to be in TRIP. The
mapping from +1 603 to a name for that area code is not dynamic, nor
different from provider to provider.


But what is dynamic is an enterprise phone destination
for example when a company buys a large block of 1603884


One could actually have a global
database, where you look up a phone prefix, and get out a textual name.

Those exist already, however, they cannot be dynamically added to
when new blocks of numbers are allocated (i.e. new area codes or
new large enterprise blocks of numbers).


Interestingly, enum was just chartered as a working group to look up a
phone number in DNS, and get something out, where that something is
generally a URL. But, it could be a piece of text.

Also, does enum allow us to lookup just a phone prefix, not a complete
number? I would presume so.

(I'm ccing the enum list on this for comment)

-Jonathan R.

Jon Steer wrote:
>
> Currently, in the IP world, if I want to understand a route in
> a human readable form, traceroute can use DNS to potentially
> gather the names of the routers/domains along the route.
>
> For the E.164 address space, this isn't the case, without a
> fixed, hand-generated database.
>
> I believe that there is an opportunity to provide some extended
> "callerid" and management functionality if the originating LS includes
>   human readable text when advertising a route.
>
>   For example, if the LS advertises the E.164 1603xxxx route, a textual
> attribute
>   containing NewHampshire would enable the front ends of LS servers to gather
>   and display address spaces.
>
>   jon
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen       PHONE: (732) 741-7244
http://www.dynamicsoft.com

---------
This message came from the IETF IPTEL Working Group Mailing List.
--=====================_108203156==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 11 12:13:19 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04567 for ; Thu, 11 Nov 1999 12:13:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19937; Thu, 11 Nov 1999 12:11:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19903 for ; Thu, 11 Nov 1999 12:11:01 -0500 (EST) Received: from terra.eng.fore.com ([169.144.155.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03395 for ; Thu, 11 Nov 1999 12:11:10 -0500 (EST) Received: by TERRA with Internet Mail Service (5.5.2232.9) id ; Thu, 11 Nov 1999 12:12:49 -0500 Message-ID: <21565C751365D211BB2D0060089624CC1D3BF5@TERRA> From: Brian Rosen To: Jonathan Rosenberg , Jon Steer Cc: enum@ietf.org Date: Thu, 11 Nov 1999 12:12:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org An interesting issue is that there is a proposal in enum to turn +1 603 884 2235 to a DNS entry that looks something like: 5.3.2.2.4.8.8.3.0.6.1.enum.int Observe that if I reserve the block +1 603 884 2000-2500, that a query of any number in the block using the above scheme will work. However, what if I query: 2.4.8.8.3.0.6.1.enum.int What do I get? Foo owns +1 603 884-2000, but does not own +1 603 884-2667. The problem is that dns is heirarchical, but using a subdomain per digit doesn't capture what happens. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, November 10, 1999 10:17 AM > To: Jon Steer > Cc: iptel@lists.research.bell-labs.com; enum@ietf.org > Subject: Re: Human readable Route descriptors > > > > > Jon Steer wrote: > > > > At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote: > > > > > This function is useful, but I'm not sure it needs to be in TRIP. > > > The > > > mapping from +1 603 to a name for that area code is not > dynamic, nor > > > different from provider to provider. > > > > But what is dynamic is an enterprise phone destination > > for example when a company buys a large block of 1603884 > > Perhaps dynamic is not the right word. I agree something like > that needs > to be covered. The difference is that if company foo buys > 1603884, this > number is mapped to foo for everyone that asks. TRIP is great at > distributing information with parameters that are different for > different peers. What you want to do can be done using a global (with > updates) directory service, which is exactly what enum is. > > > > > > > > One could actually have a global > > > database, where you look up a phone prefix, and get out a textual > > > name. > > > > Those exist already, however, they cannot be dynamically added to > > when new blocks of numbers are allocated (i.e. new area codes or > > new large enterprise blocks of numbers). > > Whilst the enum group won't address how updates take place, certainly > the database itself won't be useful if it can't be updated. DNS can > certainly be updated; the timescales of the updates we need for this > service are doable using administrative updates, as opposed > to real time > protocol based updates. > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 11 14:28:03 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16646 for ; Thu, 11 Nov 1999 14:28:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA24762; Thu, 11 Nov 1999 14:27:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA24728 for ; Thu, 11 Nov 1999 14:27:17 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16347 for ; Thu, 11 Nov 1999 14:27:27 -0500 (EST) Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhoxi14855; Thu, 11 Nov 1999 19:31:38 GMT Received: from dynamicsoft.com (dhcp45-lt205.lt.ietf.innovationslab.net [130.128.45.205]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id OAA28298; Thu, 11 Nov 1999 14:27:08 -0500 (EST) Message-ID: <382B1917.588FCD07@dynamicsoft.com> Date: Thu, 11 Nov 1999 14:29:27 -0500 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Steer CC: Stephen Sprunk , iptel@lists.research.bell-labs.com, enum@ietf.org References: <4.2.0.58.19991109224552.03c22170@10.173.17.1> <4.2.0.58.19991110070756.039d4be0@10.173.17.1> <4.2.0.58.19991110170009.03a3df00@10.173.17.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Human readable Route descriptors Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Jon Steer wrote: > > At 03:26 PM 11/10/99 -0600, Stephen Sprunk wrote: > > > The purchase of a block of phone numbers is generally static in that > > it doesn't change on a real-time basis; generally blocks of numbers > > will stay with their owners for months to years. > > Hopefully, one of the things that IP telephony brings is the ability > to define new services one that might > require dynamic addresses. > > > The actual line assignments can be delegated to the current owner > > by the telco. > > This presumes that all E.164 addresses that TRIP advertises are RBOC > telco visible and not > a private numbering system perhaps implemented by an ISP. My understanding is that the enum mechanism is not restricted to public e.164 numbers. By using prefixes other than e164.in, one could look up private numbers as well. > For example, I pay my ISP to allow me to setup a dynamic route to > handle a weekly videoconference. I'm paying > my ISP by bandwidth, not by line. I want the ISP to route my calls to > my video unit. > > When I call outwards from my dynamic video endpoint, it would be nice > to deliver the human readable > callerid to the other end. The mechanism, even if in TRIP, wouldn't get you caller ID. SIP itself as a call establishment protocol provides this. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 11 15:25:08 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13971 for ; Thu, 11 Nov 1999 15:25:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA26629; Thu, 11 Nov 1999 15:20:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA26598 for ; Thu, 11 Nov 1999 15:20:57 -0500 (EST) Received: from alpha.mcit.com (omzrelay01.mcit.com [199.249.19.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09043 for ; Thu, 11 Nov 1999 15:14:40 -0500 (EST) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FL100MHERW20B@firewall.mcit.com> for enum@ietf.org; Thu, 11 Nov 1999 19:09:38 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id TAA13925; Thu, 11 Nov 1999 19:04:56 +0000 (GMT) Received: from dwillispc4 ([166.37.185.128]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19991111190937.IGLD10632@dwillispc4>; Thu, 11 Nov 1999 19:09:37 +0000 Date: Thu, 11 Nov 1999 13:12:02 -0600 From: Dean Willis Subject: [ENUM] Dynamics -- was RE: Human readable Route descriptors In-reply-to: <4.2.0.58.19991110170009.03a3df00@10.173.17.1> To: iptel@lists.research.bell-labs.com, enum@ietf.org Message-id: <000501bf2c78$a2a0ad40$9f168082@fh.ietf.innovationslab.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Jon Steer wrote ------ At 03:26 PM 11/10/99 -0600, Stephen Sprunk wrote: The purchase of a block of phone numbers is generally static in that it doesn't change on a real-time basis; generally blocks of numbers will stay with their owners for months to years. Hopefully, one of the things that IP telephony brings is the ability to define new services one that might require dynamic addresses. -------- Clearly the relatioship between a phone number and an IP Address can be dynamic. Part of my initial adverse reaction to ENUM is my belief that the association of IP addresses to phone numbers is an exceptionally dynamic relationship, and that this relationship could not be adequately expressed in a relatively static and cached DNS. However, ENUM does appear to have the potential to resolve a phone number into a dynamic registrar instead of an IP address. This resolution could also be indirected at one or more levels in order to provide number portability between carriers, I think. Whether ENUM can address the privacy requirements of LNP is another issue. For example -- (all names and numbers fictitious) I as a phone user might rent a phone number from a carrier, perhaps 13045551212 from BPI (Big Phone Inc). The NANP NS delegates to the 304 area NS, which delegates exchange 555 to the SBC NS. The SBC NS might contain a record pointing .1212 towards sip:3045551212@sip.bpi.net;user=phone. As part of my rental fee for the phone number, SBC allows me to either use sip.sbc.net as a registrar, or to provision contacts into it using a web interface. In the simplest mode, assume I use the registration services. When I turn my phone on, it sends a SIP REGISTER to sip.bpi.net on behalf of 3045551212 listing the phone's current IP address as a Contact:. Calls from the GSTN to my phone resolve in the following way: The call enters the GSTN as a sequence of dialed digits. The carrier switching system follows the standard PSTN routing to the nearest BPI switch registered as handling my exchange (30555). BPI hands the call to an IP gateway. The gateway does a DNS lookup on 3045551212, which resolves to 3045551212@sip.bpi.net. The GW then sends an INVITE to sip.bpi.net and is proxied or redirected to my phone. Note that nobody ever looked in the TRIP routes to resolve the call. In the event that I place a call to the PSTN, 19153627878, things happen in a very different fashion. In this sequence, my phone does a DNS lookup on the dialed number. Perhaps it does not resolve (It's not an IP or LNP registered phone number). My phone then sends an INVITE to sip.bpi.net with a request-URI of tel:9153627878, perhaps with some sort of scope specifier. Next sip.bpi.net consults its TRIP routing table to find one or more egress gateways and either proxies or redirects my call. Alternative: My phone could be configured to always send my calls to my outgoung proxy sip.bpi.net. In this case, it sends the INVITE tel:9153627878. The proxy does a DNS lookup, finds that the name does not resolve, consults TRIP, and proxies or forwards the call. These scenarios work pretty well. But, I haven't been able to figure out a scenario for local number portability from within DNS -- theoretcially, one of the ENUM possibilities. Anybody want to tackle that? I'm concerned that LNP is more like NAT than it is a 302: redirect . . . -- Dean _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 11 16:05:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04825 for ; Thu, 11 Nov 1999 16:05:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA28780; Thu, 11 Nov 1999 16:04:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA28746 for ; Thu, 11 Nov 1999 16:04:50 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04469 for ; Thu, 11 Nov 1999 16:05:00 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 11 Nov 1999 15:03:52 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 11 Nov 1999 15:03:48 -0600 Message-ID: From: "Jeff Hinchey" To: Jon Steer Cc: iptel , enum Subject: RE: [Enum] Re: Human readable Route descriptors Date: Thu, 11 Nov 1999 15:03:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF2C88.3F449C7E" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF2C88.3F449C7E Content-Type: text/plain; charset="windows-1252" -----Original Message----- From: Jon Steer [mailto:jsteer@bitscout.com] Sent: Wednesday, November 10, 1999 5:11 PM To: Stephen Sprunk; Jonathan Rosenberg Cc: iptel; enum Subject: [Enum] Re: Human readable Route descriptors [jh] text deleted This presumes that all E.164 addresses that TRIP advertises are RBOC telco visible and not a private numbering system perhaps implemented by an ISP. [jh] For clarification purposes, E.164 defines the global public number plan. It does not encompass private number plans/numbers. A given number is unique within E.164 but could also be used in one more private number plans. If TRIP is to support resolution of private numbers in addition to public numbers, then the DNS hierarchy must include a top level number plan key. For example: 7.0.0.8.3.6.7.3.1.6.1.e164.enum.int 7.0.0.8.3.9.3.acme.enum.int ------_=_NextPart_001_01BF2C88.3F449C7E Content-Type: text/html; charset="windows-1252"
-----Original Message-----
From: Jon Steer [mailto:jsteer@bitscout.com]
Sent: Wednesday, November 10, 1999 5:11 PM
To: Stephen Sprunk; Jonathan Rosenberg
Cc: iptel; enum
Subject: [Enum] Re: Human readable Route descriptors


[jh] text deleted
 
This presumes that all E.164 addresses that TRIP advertises are RBOC telco visible and not
a private numbering system perhaps implemented by an ISP.

[jh] For clarification purposes, E.164 defines the global public number plan. It does not encompass private number plans/numbers. A given number is unique within E.164 but could also be used in one more private number plans. If TRIP is to support resolution of private numbers in addition to public numbers, then the DNS hierarchy must include a top level number plan key.
 
For example:
 
7.0.0.8.3.6.7.3.1.6.1.e164.enum.int
 
7.0.0.8.3.9.3.acme.enum.int  
------_=_NextPart_001_01BF2C88.3F449C7E-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 11 16:58:12 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00399 for ; Thu, 11 Nov 1999 16:58:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA02034; Thu, 11 Nov 1999 16:57:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA02002 for ; Thu, 11 Nov 1999 16:57:31 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00108 for ; Thu, 11 Nov 1999 16:57:39 -0500 (EST) From: Melinda.Shore@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id XAA02466; Thu, 11 Nov 1999 23:57:40 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA12518; Thu, 11 Nov 1999 23:57:40 +0200 (EET) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Thu, 11 Nov 1999 23:57:39 +0200 Message-ID: To: iptel@lists.research.bell-labs.com, enum@ietf.org Subject: RE: [ENUM] Dynamics -- was RE: Human readable Route descriptors Date: Thu, 11 Nov 1999 23:57:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > However, ENUM does appear to have the potential to resolve a > phone number into a dynamic registrar instead of an IP address. Yes, you'd pretty much have to do this (return the called party's gatekeeper address) with H.323, anyway, if you have any hope whatsoever of calling someone behind a NAT or RSIP server. I'm in the process of writing an I-D on this topic. Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 W State St Ithaca, NY 14850 +1 607 273 0724 x81 (work) +1 607 227 4096 (mobile) +1 607 275 3610 (fax) Melinda.Shore@nokia.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 12 09:10:51 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07117 for ; Fri, 12 Nov 1999 09:10:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA08063; Fri, 12 Nov 1999 09:09:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA08032 for ; Fri, 12 Nov 1999 09:09:29 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06808 for ; Fri, 12 Nov 1999 09:09:40 -0500 (EST) Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhpae19086; Fri, 12 Nov 1999 14:14:01 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id JAA00247; Fri, 12 Nov 1999 09:09:40 -0500 (EST) Message-ID: <382C203D.47F123A2@dynamicsoft.com> Date: Fri, 12 Nov 1999 09:12:13 -0500 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: iptel@lists.research.bell-labs.com, enum@ietf.org Subject: Re: [ENUM] Dynamics -- was RE: Human readable Route descriptors References: <000501bf2c78$a2a0ad40$9f168082@fh.ietf.innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > However, ENUM does appear to have the potential to resolve a phone number > into a dynamic registrar instead of an IP address. I agree completely that this is a very reasonable way to do it, and not inconsistent at all with what Scott is saying. > For example -- (all names and numbers fictitious) I as a phone user might > rent a phone number from a carrier, perhaps 13045551212 from BPI (Big Phone > Inc). The NANP NS delegates to the 304 area NS, which delegates exchange 555 > to the SBC NS. The SBC NS might contain a record pointing .1212 towards > sip:3045551212@sip.bpi.net;user=phone. As part of my rental fee for the > phone number, SBC allows me to either use sip.sbc.net as a registrar, or to > provision contacts into it using a web interface. In the simplest mode, > assume I use the registration services. When I turn my phone on, it sends a > SIP REGISTER to sip.bpi.net on behalf of 3045551212 listing the phone's > current IP address as a Contact:. > > Calls from the GSTN to my phone resolve in the following way: The call > enters the GSTN as a sequence of dialed digits. The carrier switching system > follows the standard PSTN routing to the nearest BPI switch registered as > handling my exchange (30555). BPI hands the call to an IP gateway. The > gateway does a DNS lookup on 3045551212, which resolves to > 3045551212@sip.bpi.net. The GW then sends an INVITE to sip.bpi.net and is > proxied or redirected to my phone. Note that nobody ever looked in the TRIP > routes to resolve the call. > > In the event that I place a call to the PSTN, 19153627878, things happen in > a very different fashion. > > In this sequence, my phone does a DNS lookup on the dialed number. Perhaps > it does not resolve (It's not an IP or LNP registered phone number). My > phone then sends an INVITE to sip.bpi.net with a request-URI of > tel:9153627878, perhaps with some sort of scope specifier. Next sip.bpi.net > consults its TRIP routing table to find one or more egress gateways and > either proxies or redirects my call. > > Alternative: > My phone could be configured to always send my calls to my outgoung proxy > sip.bpi.net. In this case, it sends the INVITE tel:9153627878. The proxy > does a DNS lookup, finds that the name does not resolve, consults TRIP, and > proxies or forwards the call. The original and alternative appear to be the same, but otherwise I agree. This example is nice in that it illustrates the different uses of TRIP and enum. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 12 10:57:43 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11194 for ; Fri, 12 Nov 1999 10:57:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA10653; Fri, 12 Nov 1999 10:54:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA10621 for ; Fri, 12 Nov 1999 10:54:23 -0500 (EST) Received: from omzrelay02.mcit.com (omzrelay02.mcit.com [199.249.19.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09873 for ; Fri, 12 Nov 1999 10:54:33 -0500 (EST) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #38417) with ESMTP id <0FL300KAJDB0TX@firewall.mcit.com> for enum@ietf.org; Fri, 12 Nov 1999 15:49:49 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id PAA12150; Fri, 12 Nov 1999 15:45:06 +0000 (GMT) Received: from dwillispc4 ([166.37.184.51]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19991112154947.PRAW15494@dwillispc4>; Fri, 12 Nov 1999 15:49:47 +0000 Date: Fri, 12 Nov 1999 09:52:11 -0600 From: Dean Willis Subject: RE: [ENUM] Dynamics -- was RE: Human readable Route descriptors In-reply-to: <382C203D.47F123A2@dynamicsoft.com> To: IETF Enum , IETF IPTEL , Jonathan Rosenberg Message-id: <002601bf2d25$e2023aa0$9f168082@fh.ietf.innovationslab.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wote: > Dean Willsi wrote: > > In this sequence, my phone does a DNS lookup on the dialed > number. Perhaps > > it does not resolve (It's not an IP or LNP registered phone number). My > > phone then sends an INVITE to sip.bpi.net with a request-URI of > > tel:9153627878, perhaps with some sort of scope specifier. Next > sip.bpi.net > > consults its TRIP routing table to find one or more egress gateways and > > either proxies or redirects my call. > > > > Alternative: > > My phone could be configured to always send my calls to my > outgoung proxy > > sip.bpi.net. In this case, it sends the INVITE tel:9153627878. The proxy > > does a DNS lookup, finds that the name does not resolve, > consults TRIP, and > > proxies or forwards the call. > > The original and alternative appear to be the same, but otherwise I > agree. This example is nice in that it illustrates the different uses of > TRIP and enum. The difference is whether my phone begins with an attempt to do DNS resolution on the called party or goes directly to a SIP proxy. Rather like the sendmail models of direct SMTP delivery to the destination or reliance on a smarter host. The change to call flow occurs when the called number DOES resolve in DNS and the phone sends the INVITE directly to the resolved destination rather than to the calling party's proxy. It has implications for proxy-mediated QoS ala DCS, carrier ability to provide pen-register trace functions, and probably other stuff I haven't thought of yet. There might be some interesting interaction in that the choice of egress gateway might resolve differently, perhaps falling into a different carrier's TRIP path. Of course these are configuration and operations issues, but it's nice to understand the impact of protocol on operations, no? -- Dean _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 12 13:31:04 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19576 for ; Fri, 12 Nov 1999 13:30:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA15109; Fri, 12 Nov 1999 13:30:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA15056 for ; Fri, 12 Nov 1999 13:30:02 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19231 for ; Fri, 12 Nov 1999 13:30:13 -0500 (EST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 12 Nov 1999 12:13:49 -0600 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WXAYFXCA; Fri, 12 Nov 1999 10:13:44 -0800 Received: from msquire (extranet-139-227.corpeast.baynetworks.com [132.245.139.227]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WMJAFTKW; Fri, 12 Nov 1999 13:13:42 -0500 Message-Id: <3.0.32.19991112131007.00b32180@zbl6c008.corpeast.baynetworks.com> X-Sender: msquire@zbl6c008.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Nov 1999 13:10:12 -0500 To: Brian Rosen From: "Matt Squire" Subject: Re: [Enum] RE: Human readable Route descriptors Cc: enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:12 PM 11/11/99 -0500, Brian Rosen wrote: >An interesting issue is that there is a proposal in enum to turn >+1 603 884 2235 to a DNS entry that looks something like: >5.3.2.2.4.8.8.3.0.6.1.enum.int > >Observe that if I reserve the block +1 603 884 2000-2500, >that a query of any number in the block using the above >scheme will work. > >However, what if I query: >2.4.8.8.3.0.6.1.enum.int > >What do I get? Foo owns +1 603 884-2000, but does not own >+1 603 884-2667. The problem is that dns is heirarchical, >but using a subdomain per digit doesn't capture what happens. > I'm not sure I understand the problem Brian. So foo owns/rents 1-603-884-2000 thru 1-603-884-2499. 4.2.4.8.8.3.0.6.1.e164.int => foo.com 3.2.4.8.8.3.0.6.1.e164.int => foo.com 2.2.4.8.8.3.0.6.1.e164.int => foo.com If +1-603-884-2 is not allocated by the owner of +1-603-884, then the query will fail and rightfully so. If it is allocated, then there should be a record (to someone other than foo). I guess I'm just missing your concern. The representation is a bit verbose, but I think it works. By verbose, I mean that if, say, the US govt allocated numbers in 3 digit chunks (area codes), it would have to have dummy entries like for the first and second digits of the chunk, ie 4.8.8.3.0.6.1.e164.int => someone (legit chunk) 8.8.3.0.6.1.e164.int => us.gov (dummy) 8.3.0.6.1.e164.int => us.gov (dummy) How the owner (in this case us.gov) decided to answer queries about such 'invalid' prefixes would be within its domain. Is that not ok? Or are you suggesting something like 884.603.1.enum.int where the domain strings represent the current e164 heirarchy (3 digit area codes in US, etc.)? This has the effect of placing the burden of knowing the e164 heirarchy on the user who queries, and that seems undersirable. What am I missing? - Matt _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 12 20:19:49 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24662 for ; Fri, 12 Nov 1999 20:19:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA25211; Fri, 12 Nov 1999 20:19:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA25181 for ; Fri, 12 Nov 1999 20:19:13 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24505 for ; Fri, 12 Nov 1999 20:19:25 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id TAA28450; Fri, 12 Nov 1999 19:19:26 -0600 (CST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id TAA02497; Fri, 12 Nov 1999 19:19:26 -0600 (CST)] Received: from starfish.cig.mot.com (kurrasch@starfish [136.182.3.19]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id TAA20513; Fri, 12 Nov 1999 19:19:25 -0600 (CST) Received: from localhost (kurrasch@localhost) by starfish.cig.mot.com (8.8.5/SCERG-1.12B) with ESMTP id TAA16010; Fri, 12 Nov 1999 19:19:24 -0600 (CST) Date: Fri, 12 Nov 1999 19:19:23 -0600 (CST) From: Peter Kurrasch X-Sender: kurrasch@starfish To: iptel@lists.research.bell-labs.com, enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Enum] E.164 mapping proposal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 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://:@:/ where represents you the *caller* and 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 kurrasch@cig.mot.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 12 20:34:44 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01724 for ; Fri, 12 Nov 1999 20:34:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA25522; Fri, 12 Nov 1999 20:34:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA25485 for ; Fri, 12 Nov 1999 20:33:59 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01480 for ; Fri, 12 Nov 1999 20:34:09 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA08027; Fri, 12 Nov 1999 20:34:10 -0500 (EST) Date: Fri, 12 Nov 1999 20:34:10 -0500 (EST) From: Scott Bradner Message-Id: <199911130134.UAA08027@newdev.harvard.edu> To: enum@ietf.org, iptel@lists.research.bell-labs.com, kurrasch@cig.mot.com Subject: [Enum] Re: E.164 mapping proposal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > tmar://:@:/ in case anyone wonders, the IESG does not support the use of cleartext passwords in IETF protocols Scott _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 13 00:30:30 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23398 for ; Sat, 13 Nov 1999 00:30:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA28830; Sat, 13 Nov 1999 00:29:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA28793 for ; Sat, 13 Nov 1999 00:29:46 -0500 (EST) Received: from mail.intekom.com (smtp.intekom.com [196.25.69.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23197 for ; Sat, 13 Nov 1999 00:29:57 -0500 (EST) Received: from cbs53-03-81.wc.saix.net ([155.239.135.81] helo=[192.168.1.3]) by mail.intekom.com with esmtp (Exim 3.03 #6) id 11mVjm-0007a0-00; Sat, 13 Nov 1999 07:28:35 +0200 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Sat, 13 Nov 1999 07:29:24 +0000 Subject: Re: [ENUM] Dynamics -- was RE: Human readable Route descriptors From: "Baron Victor von Maltzahn" To: Dean Willis , iptel@lists.research.bell-labs.com, enum@ietf.org Mime-version: 1.0 X-Priority: 1 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Thank you for your e-mail. I will come back to you as soon as possible. ---------- >From: Dean Willis >To: iptel@lists.research.bell-labs.com, enum@ietf.org >Subject: [ENUM] Dynamics -- was RE: Human readable Route descriptors >Date: Thu, 11 Nov, 1999, 19:12 > > > Jon Steer wrote > ------ > At 03:26 PM 11/10/99 -0600, Stephen Sprunk wrote: > > The purchase of a block of phone numbers is generally static > in that it doesn't change on a real-time basis; generally > blocks of numbers will stay with their owners for months to years. > > Hopefully, one of the things that IP telephony brings is the ability to > define new services one that might require dynamic addresses. > -------- > > Clearly the relatioship between a phone number and an IP Address can be > dynamic. > > Part of my initial adverse reaction to ENUM is my belief that the > association of IP addresses to phone numbers is an exceptionally dynamic > relationship, and that this relationship could not be adequately expressed > in a relatively static and cached DNS. > > However, ENUM does appear to have the potential to resolve a phone number > into a dynamic registrar instead of an IP address. This resolution could > also be indirected at one or more levels in order to provide number > portability between carriers, I think. Whether ENUM can address the privacy > requirements of LNP is another issue. > > For example -- (all names and numbers fictitious) I as a phone user might > rent a phone number from a carrier, perhaps 13045551212 from BPI (Big Phone > Inc). The NANP NS delegates to the 304 area NS, which delegates exchange 555 > to the SBC NS. The SBC NS might contain a record pointing .1212 towards > sip:3045551212@sip.bpi.net;user=phone. As part of my rental fee for the > phone number, SBC allows me to either use sip.sbc.net as a registrar, or to > provision contacts into it using a web interface. In the simplest mode, > assume I use the registration services. When I turn my phone on, it sends a > SIP REGISTER to sip.bpi.net on behalf of 3045551212 listing the phone's > current IP address as a Contact:. > > Calls from the GSTN to my phone resolve in the following way: The call > enters the GSTN as a sequence of dialed digits. The carrier switching system > follows the standard PSTN routing to the nearest BPI switch registered as > handling my exchange (30555). BPI hands the call to an IP gateway. The > gateway does a DNS lookup on 3045551212, which resolves to > 3045551212@sip.bpi.net. The GW then sends an INVITE to sip.bpi.net and is > proxied or redirected to my phone. Note that nobody ever looked in the TRIP > routes to resolve the call. > > In the event that I place a call to the PSTN, 19153627878, things happen in > a very different fashion. > > In this sequence, my phone does a DNS lookup on the dialed number. Perhaps > it does not resolve (It's not an IP or LNP registered phone number). My > phone then sends an INVITE to sip.bpi.net with a request-URI of > tel:9153627878, perhaps with some sort of scope specifier. Next sip.bpi.net > consults its TRIP routing table to find one or more egress gateways and > either proxies or redirects my call. > > Alternative: > My phone could be configured to always send my calls to my outgoung proxy > sip.bpi.net. In this case, it sends the INVITE tel:9153627878. The proxy > does a DNS lookup, finds that the name does not resolve, consults TRIP, and > proxies or forwards the call. > > These scenarios work pretty well. But, I haven't been able to figure out a > scenario for local number portability from within DNS -- theoretcially, one > of the ENUM possibilities. Anybody want to tackle that? I'm concerned that > LNP is more like NAT than it is a 302: redirect . . . > > -- > Dean > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 15 17:12:40 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09558 for ; Mon, 15 Nov 1999 17:12:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA28798; Mon, 15 Nov 1999 17:11:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA28766 for ; Mon, 15 Nov 1999 17:11:55 -0500 (EST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09381 for ; Mon, 15 Nov 1999 17:12:07 -0500 (EST) Received: from laptop (stl-mo14-47.ix.netcom.com [207.222.133.47]) by smtp7.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id RAA17373; Mon, 15 Nov 1999 17:10:59 -0500 (EST) Message-Id: <4.2.0.58.19991115160303.00a08300@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 15 Nov 1999 16:08:59 -0600 To: "Matt Squire" , Brian Rosen From: Richard Shockey Subject: Re: [Enum] RE: Human readable Route descriptors Cc: enum@ietf.org In-Reply-To: <3.0.32.19991112131007.00b32180@zbl6c008.corpeast.baynetwor ks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >within its domain. Is that not ok? > >Or are you suggesting something like > 884.603.1.enum.int >where the domain strings represent the current e164 heirarchy (3 digit area >codes in US, etc.)? This has the effect of placing the burden of knowing >the e164 heirarchy on the user who queries, and that seems undersirable. > >What am I missing? This is a very difficult problem and I'm not sure I like what this statement implies. IMHO any solution should attempt to avoid at all costs the necessity that user/client have prior knowledge of the 164 structure. Unfortunately the 164 structure has no "global order" to it that permits decoding the various elements based solely on the presentation of the digits. The hope is that a solution is sufficiently simple to permit embedding in multiple classes of devices scaling from "Internet Telephone", to PBX switch ..ultimately to carrier provided service models. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 22 05:48:51 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27139 for ; Mon, 22 Nov 1999 05:48:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA05107; Mon, 22 Nov 1999 05:45:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA05075 for ; Mon, 22 Nov 1999 05:45:32 -0500 (EST) Received: from post.netchina.com.cn ([202.94.1.48]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25638 for ; Mon, 22 Nov 1999 05:45:46 -0500 (EST) Received: (qmail 24535 invoked from network); 22 Nov 1999 10:47:30 -0000 Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227) by 202.94.1.48 with SMTP; 22 Nov 1999 10:47:30 -0000 Message-ID: <38391E67.8D1372CC@netchina.com.cn> Date: Mon, 22 Nov 1999 18:43:52 +0800 From: Robert Tan Reply-To: tjsh@netchina.com.cn Organization: Tan Junsheng X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] The title: Flash Bandwidth 1KHz to 100MHz Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit The title: Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter Dear Sir: This is my discussion article. The details: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc Sincerely, Robert Tan 11.22 Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter The Next Era Web of Multimedia Data-stream Transmission Solution of the Internet! By Robert Tan Update: 1999. 11. 22 For the many more format and definite of standard of digital film and video, digital audio and the other multimedia data stream of tomorrow, the existing network technology including the modern internet webs will be fabulous and difficult to transmit it for us. The Endpoint Congestion almost resistant our viewer area full of the entire world, We would need the straightway link of the multi-media data-stream in real-time for us. Would you like to get a lower cost & more effective digital signal channel in a wide-bandwidth or broadband hybrid coax cable system? For the FTTX, HFC networks, especially in the HFC networks with the 256QAM or 64VSB digital modulation technology systems, the SSB-ASK or the VSB-ASK technology transmission systems would be used normally. The Flash Bandwidth 1KHZ to 100MHz digital control a variable frequency bandwidth, it is high-performance anti-alias & reconstruction (FBW) filter, it will be able to provide a variable multiplex sub-frequency band in any broadband HFC system. With the FDM assistant digital carry system and SSB or VSB signal channel, a group of FBW filters will provide separate multi-frequency bands in spectrum without any cross talking and distortion by a large frequency range in a high-speed high- effective transmission system. In a FTTX or HFC web, this digital controlled signal channel would have a very large frequency spectrum changed dynamic range. For a large client group, such as the Broadband Cable Internet Access or HFC users, one of them would like to get a variable data speed according to the applications of his needed. It will provide a lot of digital control frequency bandwidth which is separated one another in HFC transmission system, and it will more effective for the "hot clients", such as the VOD video clients or the other high-code rate users and high-speed data stream user's applications. The FBW will improve the speed of the data stream, diminish the amount of the spare resource seizing of "Cool Clients", reduce the calculations of the DSP processor of the center web main switching system and the branch switching system. Reduce the CPU utilities of the applications in all of client communication adapter and its cost of produce is very important. The "Cool Clients" mains the IP telephone users or the other lower speed code rate audio applications. Anyway, the speed of the up-stream data and down-stream data speed could be changed to any value you needed, and the changing degree will be very smoothly and very simply in writing one or two bytes in the command system of communication web switcher. By the high-speed frequency variable characteristic, if the FBW filter were used in your FTTX or HFC switching system, the upward and downward data stream speed could be managed and attempted by your command system. So that, the transmission bandwidth will be able to adjusted to your needed in any time within one millionth second. The real-time will be very more improved and more effective on the communication main roads such as FTTX and HFC system, transmission controlling system will completely control the data stream in real-time. Dear Technology Research and Development Administrator: I am an electronic engineer in the field of Analog and Digital filters researching and designing. I had been a DSP engineer for ten years. My development field is electronic circuits -- digital and analog hardware designing and researching in applications of Digital Signal Processing. My works contains the frequency spectrum analysis, digital audio and digital video systems, noise spectrum controlling and processing, and the other military applications. I have researched and designed several kind of analog and digital anti-alias & reconstruction filters. A few years before, in my R&D works, I find the special frequency of the filters is usually fixed, it could be very difficult to change the cutoff frequency of the low-pass anti-alias & reconstruction filter. But the fixed filter could not suit the target of my technical applications. If we want to get several special frequency of the filters, we must to use several different fixed filters or instead of fixed filter with switching capacity filter or digital filter, such as IIR or FIR filter, and their frequency must be variable in order to change the analysis frequency. It is very important for the spectrum analysis system and the digital random real time vibrated controlling system. But, in this way, we must pay for digital IIR or FIR filter, it is very expensive in the price, take a large space for the DSP chips and its outside memory banks to install it. So, we would get into much troubles and complex questions from a simple problem. However, we have the switching capacity technologies, and the product of up to 8th order filters is a very normally used. But the switching capacity filter will have a high noise and low frequency range, and it has a non-exactly special frequency, generally. The special frequency of most of the switching capacity filters is from 1/95 to 1/105 times of its main switching clock and it is difficult to improve its accuracy. Actually, the switching capacity filter circuit is very difficult to adjust and use in applications. Anywise, its order is normally below 8th order, and the special frequency and bandwidth of the switching capacity filters is below to 50KHz, and the amplitude response is not exactly yet, the dynamic range of the amplitude is very low, normally, it is below the 48dB. Except of frequency range from 0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not usefully, it is normally being used in the speech processing circuit and the other lower frequency band processing systems. Attention, all of this analysis is not including the phase noise of the main switching clock and the noise of clock feed through yet. The others, it is difficult to get much more analysis frequency bands or special frequency points for the switching capacity filters, it is especially for the higher frequency band which is approached to the top frequency point. All of these characteristics of the switching capacity filters will restrict its applications in the area of modern digital communications. The others method of the filters designing is the contact-time analog filter .I have found some method. It could make many transfer functions. Such as the elliptical function, Chebyshev function and Butterworth function, but there is some interesting things here, it is that the same circuit frame could be built into many transfer functions, and it would have programmable (digital controlled) special frequency. Changing special frequency on line is available. It could get the very wide frequency range, very quickly to change the used band, and the digital controlled circuit is very directly and simply, the special frequency step is very smoothly (because the Frequency is controlled by long bit Digital multiplier). In that points, integrate the FBW filter circuit technology is very useful for the digital controlling and processing systems. Because of the Digital Controlling Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8 or 12 bits long Digital Multiplier and a few chips of high-speed amplifiers. The other, this filter technology is used with a few exactitude resistors and exactitude capacitors also. For example, an 8th order elliptical filter need 8chips of dual Digital Multiplier and several chips high bandwidth amplifiers, 8chips exactitude capacitors and several chips exactitude resisters. If it is possible, integrating all the Digital Multiplier and amplifiers into one chip or one plastic package (mixed circuit), place all the exactitude resistors and capacitors out of the package. It will be finest filter and very easy to used and could be re-designed agilely by the customers and the OEMs. The parameter of the filters is depending on the value of the resistors and the capacitors. Its value could be designed by the customs freely and calculated by constant functions directly, and that is very simply. And then, the FBW filters would be very usefully in the FTTX or HFC networks. For working with the 256QAM or 64VSB modulation technology and any narrow-band transmission technology systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV and VOD systems, it would compress the used frequency bandwidth in mostly extent. Because of the WAN systems in any nations will be depending on the "Tree structures" as the main road in the webs in the future. The frequency source is very expensive in this web, It would be welcomed in the Internet web digital information transmission, exchanging and switching technology area, DSP area and digital communications area, such as MAN and WAN coax cable webs or the FTTX system applications. Any way, the most of modern networking transmission mode is TDM. It is very suitable for the text material or media, because of it is a fixed media in size, and it is the fixed continue time in length and generation procedure. But the most of multimedia is not to be suitable with that. The data stream of voice and video will have no constant size to be forecasted has no constant procedure time. It is only have a constant and fixed bandwidth of media data stream. Because of your interesting points is onto the generations and the procedures of the video or audio information of thus material or the news, such as the high quality digital cinema, digital musicale and so on. Certainly, you could take the any multimedia information and any moving picture on you desktop through the Internet Web. It will be appeared the true alive world with you in any site you can go! So that, the only one of best way of the media data streams transmission and exchanging is the FDM mode with the SSB-ASK or VSB-ASK technology, it should be working with the QAM or VSB- ASK digital modulation technology in the future Internet webs. FBW filter would be used in most of switchers and routers, which is depending on the FDM technologies. For the cable TV systems STB (set top box), video & audio servers in Broadband Cable Internet Access, cable modems or the client-end adapters in the most of family users and the most of business cable users in the world will need a very great deal of broadband web transmission bandwidth. Because of that, in any modern home-electronic equipment, such as the Internet officers, shopping's and the VOD or the other broadband information electronics, its using method would be depending on the FDM switching technologies. So that, the "Online Home-Electronics" or the other Internet accessing products which is used in people's homes would be simply to operate and easy to use. And it must be depend on the simply low-layer hardware equipment and protocols of the webs, such as the VOD systems and the STB terminals in the Broadband Cable Internet Access or HFC networks. The FBW technology would provide us more applicable and useable method in the physics layer of the public HFC networks, its FDM applications in a broadband web get us in a lower building price, more effective than the other technology. Such as the Broadband Cable Internet Access webs, HFC networks, FTTX networks, and the other and the other WAN public broadband networks would have a very great applications of the FBW filters. The others, using a Flash-Band-width filter will help you get in to a fully data stream bandwidth management of any expensive data-link channels and the very expensive communication data stream bandwidth, such as the communication data-link of the satellite communication systems, and the ocean bottom communication systems. FBW filter will control the any leased data-stream bandwidth in dynamic mode within a very large frequency range, a large range of signal frequency bandwidth and data-stream speed in any time for a communication administration and operation system. It will change the bandwidth with you leased data stream very imminently within several microsecond, improve your expensive bandwidth of data-stream transmission channel, save your leased payment and money cost for any customers of digital communications and any Tele-communication operating and service company. It will hold any important transmission of data-stream in smoothly and take it freely. So, in this system, any interrupt of your communication data stream will be never. The Digital Control Flash Bandwidth Filter specifications: (1) General details: Frequency range: 0.1Hz--100MHz Useable frequency range: 0.1Hz--100MHz(at least) Special frequency step: 0.001Hz-1000KHz Transfer functions: Elliptical, Butterworth, Chebyshev, and Bassel function. And the others contacted-time filters. Available filter type: Low-pass filter, High-pass filter, Notch filter, Band-pass filter and All-pass filter. Noise Level: -160dB(max) (Only depend on the number of the used amplifiers.) Order range: 2nd--12th(Depend on the sensitivity of the transfer functions.) Filter switching time: Less than 300nS (Filter Setting time is 200nS) Useful Range: Anti-alias filters, Reconstruction filters. (2) Pass Band Specifications: Frequency selectable range: 100Hz--100MHz (Depend on the performance of the selected amplifiers) Special Frequency steps: 1Hz-1000KHz Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of the filter.) Ripple: 0.01--1.0dB (Only depend on the filter function and the passband ripple designed.) (3) Pass to Stop Band: Drop speed of Interim-band Cut-off: 180db/oct (8th order elliptical function with 0.05dB pass-band ripple) (4) Stop Band: Amplitude min drop: 120db(8th elliptical filter for example) Frequency range: 0.1Hz--100MHz (Depend on the amplifiers and the Digital Multiplier specifications) (5) Digital Control specifications: Digital component is used (8 bit, 10bit, 12bit, and 16bit is available). The special frequency is (N1/N2) * Frequency (ref). (The N1, N2 is the Digital component input byte, from 8bit to 16 bit.) The Frequency (ref) is form 10Hz to 10MHz. (This parameter is depends on one RC time constant.) High speed and voltage feedback high-bandwidth operation amplifiers are required. (6) Requirement: (The filter section of 8th order) Digital component: 8 chips (Selections depend on the frequency range) High-performance Amplifiers: 12 to 24 chips (Selections depend on the frequency) Capacitors or inductors: 8 chips (exactitude degree value is 1% to 0.1%) Resistors: 16-36 chips (exactitude degree value is 1% to 0.1%) (7) Group delay: Depend on the function of the filter designed, filter phase response designed, and the filter order. (8) Filter switching time: Less than 300nS (Filter Setting time is 200nS) The Comparisons of the 4 kinds active Filters For example: 8th order filter Switching Capacity Filter Digital Filter (FIR or IIR Filter) Traditional Fixed Analog Frequency Filter Digital controlling FBW filter Noise Level or (THD+N) Value: Highest -48db Lower -70db Very Low -160db Very Low -120db Filter Dynamic Range The Value: Little 50db Middle 70db Very Large 160db Large 100db Real-time active frequency The range of the value: Narrow 200Hz to 300KHz Wide 0.001Hz to 50KHz Very Wide 0.1Hz to 1MHz Very wide 0.001Hz to 100MHz The Outside in advance Anti-alias & Reconstruction assistant filter requirement The degree of assistant filter Quality Required 2nd to 4th order anti-alias & reconstruction assistant outside filter Required 4th to 6th order anti-alias & reconstruction assistant outside filter Not required. ---------- Not required ---------- The Precision of the special frequency: The ability of on-line changing the filter special frequency &Method Low. +/-3% Very easy (Changing the switching clock) High +/-3% Very difficult (Change a new programs and parameters ) Very high 0.1% Very difficult. (Changing the system time constant) Very high 0.1% Easy(Writing digital word to the filter control port) The complex degree of the filter system designing &The used space Simple Small Very complex Very large Simple Middle Middle Middle The price for produce a filter &The difficult degree of the applications Very low $10~50 Easy Very high $300~600 Difficult Low $30~90 Easy Middle $50~100 Middle Anti-alias & Reconstruction filter Performance: (1)Pass Band Ripple &Dynamic Range: (2)Stop Band Rejection (3)Interim Band Dropping Slope: Low Quality & Low Price. +/-0.2db 50db 55db 50db/oct Normal or High Quality & High price +/-0.01db 70db 70db 130db/oct Normal Quality & Low Price +/-0.01db 120db 120db 180db/oct High Quality & & Middle Price. +/-0.01db 110db 120db 180db/oct Online/offline Changing of highest/lowest special frequency rate & Range: &changing time: All available 1000 times 300Hz to 300KHz 10mS(Time of PLL tracking & locked) Offline available Not available Not available Not available (Reboot DSP & A/D system) Offline available 1000 times Not available Not available All available 100000 times 1KHz to 100MHz 160nS (TTL 2 bytes writing time) Filter online reconstruction setting time (The total time of filter frequency switched) 10mS Not available Not available 300nS Group delay and the phase response: Producer design only. Linear or Producer design only. Producer design only. Producer & User design is available. Equality data stream speed or comported speed of its TxDAC : &Butterworth 8th filter (Broadband channel HFC usable signal dynamic range is about 50dB): 4.8Kbps to 4.8Mbps (600SPS to 600KSPS) 8bit TxDAC Constant 400Kbps (50KSPS) 8bit TxDAC Constant 800Mbps (100MSPS) 8bit TxDAC 16Kbps to 1600Mbps (2KSPS to 200MSPS) 8bit TxDAC Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in SSB/VSB mode of technology (Data speed of Base Band): Carrier signal RF full-band tie up: Difficult to be used with the 256QAM and 64VSB. (High Level Phase Noise) 4.8Kbps(Min) 4.8Mbps(Max) 384Hz to 384KHz Difficult to be used in variable data-speed transmission or receiving system Difficult to be used in variable data-speed transmission or receiving system With 256QAM: 8Kbps(Min) 800Mbps (Max) With 64VSB: 12Kbps(Min) 1200Mbps (Max). 1.28KHz to 128MHz For the HFC Specialty signal TV Channel: 40dB Eb/N 6MHz Full-band 64VSB model @1KHz-6MHz Data-rate: With 64VSB: 9.375Kbps (Min) 56.25Mbps (Max) Contact Address: No.2 Buliding Room1007, Mudanyuan Beili, Haidian District Beijing P. R. China, Post Code: 100083 Name: Tan Junsheng (Robert Tan) Tele: 8610-82076834, 86-13701070213(Mobile) E-mail: Tjsh@netchina.com.cn or tanjun@hotmail.com Homepage: http://www.cnindex.net/~tjsh Details Remind: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 30 07:00:30 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06531 for ; Tue, 30 Nov 1999 07:00:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA24420; Tue, 30 Nov 1999 06:58:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA24390 for ; Tue, 30 Nov 1999 06:58:54 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05980; Tue, 30 Nov 1999 06:59:20 -0500 (EST) Message-Id: <199911301159.GAA05980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 30 Nov 1999 06:59:20 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-rqmts-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Requirements Author(s) : A. Brown Filename : draft-ietf-enum-rqmts-00.txt Pages : 4 Date : 29-Nov-99 This paper defines the requirements for a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g., URLs) which can be used to contact a resource associated with that number. There are many possible protocols that can be considered for a telephone number mapping service. The purpose of this document is to focus discussion on a DNS-based solution. The intention is to enumerate the expectations of such a solution and to clarify the scope. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-rqmts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-rqmts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991129130742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rqmts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rqmts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991129130742.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 30 12:07:23 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14777 for ; Tue, 30 Nov 1999 12:07:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA02772; Tue, 30 Nov 1999 11:55:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA02742 for ; Tue, 30 Nov 1999 11:55:50 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09316 for ; Tue, 30 Nov 1999 11:56:13 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp1.ntcom.nortel.net; Tue, 30 Nov 1999 11:55:37 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 Nov 1999 10:55:36 -0600 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B2B@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'enum@ietf.org'" Date: Tue, 30 Nov 1999 10:55:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3B53.B8527800" Subject: [Enum] ENUM Requirements Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF3B53.B8527800 Content-Type: text/plain; charset="iso-8859-1" The first draft of ENUM Requirements is now available on the ENUM charter page. Regards, Anne ------_=_NextPart_001_01BF3B53.B8527800 Content-Type: text/html; charset="iso-8859-1" ENUM Requirements

The first draft of ENUM Requirements is now available on the ENUM charter page.

Regards,
Anne

------_=_NextPart_001_01BF3B53.B8527800-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 30 15:09:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17671 for ; Tue, 30 Nov 1999 15:09:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA08107; Tue, 30 Nov 1999 15:08:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA08073 for ; Tue, 30 Nov 1999 15:08:44 -0500 (EST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17302 for ; Tue, 30 Nov 1999 15:09:08 -0500 (EST) Received: from laptop (stl-mo14-30.ix.netcom.com [207.222.133.30]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA30352; Tue, 30 Nov 1999 15:07:03 -0500 (EST) Message-Id: <4.2.0.58.19991130135416.00a14c70@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 30 Nov 1999 14:05:30 -0600 To: "Anne Brown" , "'enum@ietf.org'" From: Richard Shockey Subject: Re: [Enum] ENUM Requirements In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24919B2B@bcarua63.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:55 AM 11/30/1999 -0600, Anne Brown wrote: >The first draft of ENUM Requirements is now available on the ENUM charter >page. Some small questions or clarifications.. 3.2 Capabilities Retrieval.. I thought it was clear at the meeting that Capabilities retrieval WAS within scope either as adding information directly into a DNS response or a URL pointer to whatever RESCAP eventually comes up with. I still believe a Capabilities response will ultimately be essential here. Negotiation would clearly be out of scope. 3.17 Numbers Are 1 800 numbers or the UK version of toll free legitimate e164 numbers or is this national numbering plan specific. I agree these numbers are essential to resolve but what other classes of numbers must resolve as well... 900 ? Is it appropriate at this time to formally Require ENUM to coordinate efforts with ITU SG2 etc? I know they have not currently developed a formal Question on this matter ..but I suspect they will. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 30 15:30:09 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27825 for ; Tue, 30 Nov 1999 15:30:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA08598; Tue, 30 Nov 1999 15:29:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA08565 for ; Tue, 30 Nov 1999 15:29:02 -0500 (EST) Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27512 for ; Tue, 30 Nov 1999 15:29:25 -0500 (EST) From: Melinda.Shore@nokia.com Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id WAA28357; Tue, 30 Nov 1999 22:25:43 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 30 Nov 1999 14:25:31 -0600 Message-ID: To: rshockey@ix.netcom.com, arbrown@nortelnetworks.com, enum@ietf.org Subject: RE: [Enum] ENUM Requirements Date: Tue, 30 Nov 1999 14:25:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Are 1 800 numbers or the UK version of toll free legitimate > e164 numbers or is this national numbering plan specific. > I agree these numbers are essential to resolve but what > other classes of numbers must resolve as well... 900 ? Freephone numbers are not E.164 addresses, but I think it's pretty clear that the mechanism developed by enum will work just as well in other domains (say, nanpa.int). The problem, of course, is that applications would need to be able to determine whether a number exists within the E.164 domain or a national numbering plan domain. > Is it appropriate at this time to formally Require ENUM to coordinate > efforts with ITU SG2 etc? Require? I should think not. At any right, the only body I know of which now has a work item on E.164->IP address resolution is ETSI Project TIPHON. Eurescom has a very large telecoms database project, but I think that it's scoped somewhat differently. Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, NY 14850 +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) melinda.shore@nokia.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 30 16:12:57 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18950 for ; Tue, 30 Nov 1999 16:12:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA09701; Tue, 30 Nov 1999 16:11:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA09666 for ; Tue, 30 Nov 1999 16:11:40 -0500 (EST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18522 for ; Tue, 30 Nov 1999 16:12:04 -0500 (EST) Received: from laptop (stl-mo14-30.ix.netcom.com [207.222.133.30]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA12830; Tue, 30 Nov 1999 16:11:18 -0500 (EST) Message-Id: <4.2.0.58.19991130145648.00a28280@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 30 Nov 1999 15:09:45 -0600 To: Melinda.Shore@nokia.com, arbrown@nortelnetworks.com, enum@ietf.org From: Richard Shockey Subject: RE: [Enum] ENUM Requirements In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 02:25 PM 11/30/1999 -0600, Melinda.Shore@nokia.com wrote: > > Are 1 800 numbers or the UK version of toll free legitimate > > e164 numbers or is this national numbering plan specific. > > I agree these numbers are essential to resolve but what > > other classes of numbers must resolve as well... 900 ? > >Freephone numbers are not E.164 addresses, but I think >it's pretty clear that the mechanism developed by enum >will work just as well in other domains (say, nanpa.int). >The problem, of course, is that applications would need >to be able to determine whether a number exists >within the E.164 domain or a national numbering plan >domain. > I don't think this is a problem. Its clear to me now that specific national numbering plan features could be zoned specifically for that purpose in much the way you suggest if the zone .1 points to a specific delegation for .8.0.0. or .8.8.8 etc. What I was not clear of originally was that multiple digits could combined in this way. I think we all want to avoid clients having any prior knowledge of national plan specific features. > > Is it appropriate at this time to formally Require ENUM to coordinate > > efforts with ITU SG2 etc? > >Require? I should think not. At any right, the only >body I know of which now has a work item on E.164->IP >address resolution is ETSI Project TIPHON. Eurescom has >a very large telecoms database project, but I think >that it's scoped somewhat differently. You're right .. require is not the right word though I think this proposal will closely examined by IETF "sister" standards bodies. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 30 17:44:32 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04492 for ; Tue, 30 Nov 1999 17:44:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA11880; Tue, 30 Nov 1999 17:43:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA11846 for ; Tue, 30 Nov 1999 17:43:25 -0500 (EST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04150 for ; Tue, 30 Nov 1999 17:43:50 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA09662; Tue, 30 Nov 1999 17:43:15 -0500 (EST) Received: from seascape.research.telcordia.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id RAA05632; Tue, 30 Nov 1999 17:43:13 -0500 (EST) Message-Id: <4.1.19991130172933.009cf2a0@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 Nov 1999 17:39:44 -0500 To: Richard Shockey , Melinda.Shore@nokia.com, arbrown@nortelnetworks.com, enum@ietf.org From: Christian Huitema Subject: RE: [Enum] ENUM Requirements In-Reply-To: <4.2.0.58.19991130145648.00a28280@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 03:09 PM 11/30/99 -0600, Richard Shockey wrote: > [.. snip ..] >I think we all want to avoid clients having any prior knowledge of national >plan specific features. We debated this at length in DC, and we also debated it in previous instantiations of the BOF. Dial plans are here to stay, and it is very important to accomodate them. Joe User or Jane Average have no idea of what E.164 means. Frankly, how many times do you see phone numbers on business cards written with the explicit "+" convention, as in "+1 973 829 5555"? You are much more likely to see the number printed exactly as the person would have dialed it, using the local plan. And you may bet that these numbers would be the most likely input to any translation system. I think that the right architecture should assume that dial-plans, be they national or private, are mapped into specific subtrees of the DNS, and that the number resolution software is parametrized by the name of the "translation root." Then, we have to make sure that we can use the right technique, e.g. point *.0.0.dial-plan.fr to *.e164.int using DNS aliasing. The usage of an explicit parametrization of the subtree has another advantage. It allows for the user to choose between parallel mapping trees, thus allowing for competition between different mapping systems and avoiding the monopoly capture of a single root. -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum