Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t ?

From: BARNOLE Valerie FTRD/DAC/ISS <[email-masked]>
Date: Thu, 6 Jul 2000 14:12:34 +0200

Patrick, maybe I forgot to add the ":-)" after my sentence, you have to
excuse me. I did not intend to hurt anyone.

end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FTR&D/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

[email-masked]

-----Message d'origine-----
De: Patrik Fältström [mailto:[email-masked]]
Date: jeudi 6 juillet 2000 13:44
À: BARNOLE Valerie FTRD/DAC/ISS; Richard Shockey
Cc: ENUM List Group
Objet: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t
?

At 12.14 +0200 00-07-06, BARNOLE Valerie FTRD/DAC/ISS wrote:
>I do not have the Force
>to fight against IAB wills !

None of us has. If someone is unhappy with it, they should contact 
the IAB, not us. I.e. we have managed to NOT make this a wg issue, 
and I am happy for that.

   paf

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

---

From: "Lind, Steven D, ALCOO" <[email-masked]>
Date: Fri, 14 Jul 2000 15:18:18 -0400

Greg,

I sympathize with your frustration. I guess we (myself included) refer to
phone calls when talking about ENUM because it is the most pervasive
application that would make use of the process. I totally agree that there
are lots of other applications that could make use of ENUM.

Thanks for reminding us not to leave our heads in the sand too long. :-)

Steve

---------------------------------------------------------------
Steven D. Lind                   Tel: (973) 236-6787
AT&T                             Fax: (973) 236-6452  
180 Park Ave., Bldg. 2            e-mail: [email-masked]
Florham Park, NJ 07932        web: sdlind.ips.att.com         
---------------------------------------------------------------

> -----Original Message-----
> From:	Vaudreuil, Greg M (Greg) [SMTP:[email-masked]]
> Sent:	Friday, July 14, 2000 3:09 PM
> To:	[email-masked]; David P. Peek
> Cc:	Patrik Faltstrom; [email-masked]; [email-masked]
> Subject:	RE: [Enum] FW: Last Call or New Draft? - .arpa or
> .e;164.itu.in t  ?
> 
> 
> Aaarg.  Why do people continue to think ENUM is only about phone calls????
> 
> There are half-a-dozen ways to send a message using a telephone number....
> each completely different services, each of which may have alternatives.
> 
> There dozens of potential information services that may be provided behind
> a
> telephone number....
> 
> Not to restate the obvious, but phone number are useful!  As long as the
> telephone keypad is the primary user interface on the vast majority of
> legacy and NEW communications terminals, the number of messaging, calling,
> and information services so addressed will continue to expand.
> 
> Greg V.
> 
> 
> 
> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]]
> Sent: Friday, July 14, 2000 1:09 PM
> To: David P. Peek
> Cc: Patrik Fältström; [email-masked]; [email-masked]
> Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in
> t ?
> 
> 
> On Fri, Jul 14, 2000 at 11:39:20AM -0400, David P. Peek wrote:
> > With the way ENUM requirements are defined today the Fältström draft
> > supports these requirements by returning all the services based on a
> query.
> > 
> > I agree that there are scalability issues with this approach that is why
> the
> > http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt draft
> > supports 'application specific queries' which allows specific service
> > information to be retrieved separately based on a known service
> ("Service
> > Protocal") thereby limiting the amount of information returned solving
> the
> > scalability issue. (ie. sip.x.x.x.x.x.x.e164.arpa)
> 
> I've heard this several times but I've never seen a single example
> of anything that advertises more than a small handful of services.
> How many different ways are there to make a telephone call these days
> anyway?
> 
> -MM
> 
> -- 
> --------------------------------------------------------------------------
> --
> ----
> Michael Mealling	|      Vote Libertarian!       |
> www.rwhois.net/michael
> Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
> 14198821
> Network Solutions	|          www.lp.org          |
> [email-masked]
>

---

From: James Yu <[email-masked]>
Date: Fri, 14 Jul 2000 16:26:56 -0500

"roam" can be another one.  There can many others that emulate how E.164#s
are used in SS7 global title translation (GTT).  For example, today there
are GTTs that map "national" E.164 numbers to the point codes (and subsystem
number) of the Line Information Database (LIDB for calling card service or
third-party collect call service, etc.), the switch that serves a particular
E.164 number for message notification and automatic callbck service.  Those
can be changed to IP/URL if those nodes support IP in addition to SS7/C7.

James

> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Friday, July 14, 2000 4:39 PM
> To: Michael Mealling; Anne Brown
> Cc: [email-masked]'; David P. Peek; [email-masked];
> [email-masked]
> At 16.06 -0400 00-07-14, Michael Mealling wrote:
> >On Fri, Jul 14, 2000 at 03:11:58PM -0500, Anne Brown wrote:
> >  > We are, hopefully, providing information on more 
> services than just
> >  > telephone calls.  For example, voice messaging over the 
> Internet using
> >  > SMTP.
> >
> >Cool. Ok, that's one. I've seen some SIP stuff. That's two. Any more?
> 
> I guess that michaels point is that he and myself can not see any use 
> for more than a handfull of NAPTR RRs for each owner, because the 
> detailed resolution for example given a SIP URI should be handled 
> inside the SIP protocol itself.
> 
> So, what we ask for is some more explicit arguments about why this 
> will not scale than just those words.
> 
> Two people have said that this will not scale without being able to 
> query directly for the protocol, and we want to know why.
> 
> IF it doesn't scale, it would be much more natural to query for a 
> specific service, not protocol, but I want to save this discussion 
> until I understand what problem we are going to solve.
> 
>     paf
>

---

From: [email-masked]
Date: Fri, 14 Jul 2000 18:16:27 EDT

John,

Can you please elaborate on the scalability issues that you perceive being a 
potential problem or having ramifications?  To provide a more effective 
illustration, can you clarify both in the form of examples & in the 
broad-stroke sense, conceptually.

Steve

Internetworking Systems & Technology

In a message dated 7/14/00 3:18:45 AM Eastern Daylight Time, 
[email-masked] writes:

> [email-masked]