Subject: enum URI (was RE: [Enum] Opt-in principle for calling users and communications providers)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 3 Sep 2002 16:55:44 -0500

I think we know what at least one problem is: whether or not we need a new
ENUM URI scheme. If this discussion has been intended, as it seemed at the
outset, to illustrate that the distinction between 'carrier' and 'end-user'
ENUM (or however we cast it) somehow motivates the ENUM URI, I missed the
argument.

I for one continue to believe that the ENUM URI is unnecessary. ENUM takes
as its input a telephone number, not a URI, and ENUM tells you how to reach
resources associated with that number on the Internet. The number I dial
into an IP phone isn't a URI. The called party number field of an IAM that
arrives at a PSTN-IP gateway doesn't contain a URI. Nothing about a
telephone number tells you whether or not you should use ENUM (and by
extension, when to use an ENUM URI), or indeed anything about how it should
be handled on the Internet - telephone numbers are opaque. Hence in the
absence of ENUM you need a tel URL, which is used as a bucket into which you
dump raw telephone numbers that you don't know how to reach on the Internet.
Devices like the ones I describe above would use tel URLs when they are
unable to discover the URI of any Internet resource via an ENUM query for a
raw telephone number. 

Of course, nothing prevents a user from typing in a URI containing a
telephone number, for whatever reason. While one might choose to put a
telephone number as contact information on an Internet document (say a web
page, or an email sig), the idea of providing a telephone number in that
fashion which can be ONLY be used to perform an ENUM query really misses the
point of ENUM, I think. The ENUM URI in this case would be an opaque pointer
to a set of communications records, but this requirement could be fulfilled
by any number of existing URI schemes that have no bearing on telephone
numbers (I'm sure DDDS would allow this in any number of ways). In fact, why
do a query at all... you could just stick the communications records into
the document itself and do away with the middleman telephone number - but a
call arriving at a PSTN gateway does not have that option, it can only
express a telephone number. That's why ENUM is important and necessary. Why
broaden ENUM to encompass generic requirements that are already met by any
number of protocols, rather than focusing on the unique requirement ENUM was
designed to satisfy?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2002 3:08 AM
> To: Richard Shockey; Patrik Fältström; Clive D.W. Feather
> Cc: Lawrence Conroy; [email-masked]
> Subject: RE: [Enum] Opt-in principle for calling users and
> communications providers
> 
> 
> Hi Rich,
> 
> As we discussed this issue already, I think we both agree 
> that this problem is very complex and in general I think we 
> do not even know completely, what the problem is. And I see 
> also from these discussions, that there are many different 
> views and standpoints out there. So maybe we should take a 
> step back and define the problem first and then discuss about 
> solutions.
> 
> Anyway, one thing is obvious, if we want to 
> upgrade/migrate/replace the global public phone system, we 
> have to provide at least onother global and public phone 
> system and not a mess of private databases. This was BTW one 
> of the reasons, that IN was never really available for global 
> services. All IN systems where only available _privately_ in 
> operators networks or in some cases nationally, but never globally.
> 
> Rest of the comments inline
> Richard
> 
> PS: I am still waiting for your input related to SG2 on service codes.
> 
> Richard STASTNY
> OeFEG/Telekom Austria
> Box 147, A-1103 Vienna, Austria
> tel:+43 664 420 4100
> fax:+43 1 797 80 13
> mailto:[email-masked] 
> 
> > -----Original Message-----
> > From: Richard Shockey [mailto:[email-masked]] 
> > Sent: Monday, September 02, 2002 10:38 PM
> > To: Stastny Richard; Patrik Fältström; Clive D.W. Feather
> > Cc: Lawrence Conroy; [email-masked]
> > Subject: RE: [Enum] Opt-in principle for calling users and 
> > communications providers
> > 
> > 
> > 
> > Correct .. but this could start out as a private database 
> > exchange between 
> > cooperating service providers.  The problem statement you 
> > describe does not 
> > have to be a "end world hunger" solution in the beginning.  
> > You are correct 
> > that this has some similarities to the LNP problem. 
> > Cooperating service 
> > providers could exchange end point/GW data privately to 
> > provision local and 
> > non globally visable DNS servers using either end point URI's 
> > or as you 
> > suggest LDAP look up's etc. The exchange of data could occur 
> > by any number 
> > of means ..or as the N(2) problem occurs some arrangement 
> > could be made to 
> > aggrate the data and then redistribute it to service providers in a 
> > mutually acceptable manner which then updates the local 
> > non-visable DNS 
> > servers (aka the new new SCP's).
> > 
> > If TRIP were introduced internally to a SP network then the global 
> > advertisement for endpoint resolution could be single 
> > hostname. TRIP then 
> > could hide the actual location of GW within the service 
> > providers domain 
> > boundry.
> 
> I even would not go into so much detail at the beginning, the 
> first question is to give the originator a hint (pointer) 
> where to find the destination (network or GW or whatever) for 
> a given number. Thats what ENUM is for. The rest could then 
> be done in your way (or in another).
> 
> > 
> > >You could use e164.arpa ENUM for this, but the problem 
> starts, if you
> > >have, as you mentioned, a _public/globally visible AND a privately 
> > >provisioned IP endpoint/GW database_.
> > 
> > Using e164.arpa for this is IMHO not a good idea since I ( as 
> > a service 
> > provider) would not want to expose business relationships 
> > between service 
> > providers in global DNS tree, should such data be exchanged.  
> > This goes now 
> > to the heart of the convergence problem ... the Internet 
> > operates on a 
> > transit/peering model (aka bill and keep) while global TDM 
> > telephony relies 
> > on reciprocal compensation. The optimal transaction/business 
> > model in IP 
> > Telephony keeps OSS billing costs to a minimum.
> > 
> The current model in TDM (for normal calls) is cascading, 
> where the origination network bills the subscriber and 
> cascades the money to the following networks, up to the 
> destination network.
> Maybe this model has to change anyway: e.g. every user is 
> paying for what he is reponsible for.
> We have this discussion currently with MNP, because we have 
> no air-time and different charges to different mobile networks.
> 
> So the origination subscriber pays to reach the destination 
> network, but not the destination network itself. If he his 
> paying nothing to reach the destination network (or only the 
> access) fine. It is then up to the called user to pay to be 
> reached where he wants to be reached.
>   
> > 
> > I think you agree that there is much fruitful work to be done 
> > in this area. 
> > It is not clear to me at all how C5 elements will eventually 
> > discover that 
> > some endpoints can be reached over IP.
> > 
> > We could certainly whiteboard out a dozen or more ways to do 
> > this for both 
> > the C5 elements and the exchange of GW endpoint data 
> between SP's for 
> > hosted or network oriented services.
> > 
> > That's why standards are wonderful ...there are so many of them! :-)
>  
> Ok fine, where and when?
>  
> > >Only if the calling user subscribes an _ENUM Preselection_ 
> or does a
> > >call-by-call _selection_, user ENUM is queried first.
> > 
> > Actually I think this is a _called party Preselection_ If I 
> > register my 
> > number in ENUM I have essentially stated that it is MY 
> > preference to have 
> > the call terminated to me on IP where I can establish more 
> effective 
> > control..what the calling party want is irrelevant.
> 
> This is exactly what I said above: calling and called user 
> should control and eventually pay for what they are 
> responsible and what they can control.
> 
> If you look at the TIPHON model (see Pauls presentation at 
> the NGN-Summit in Brugge), you have an originating user 
> attached to an originating serving (access) network) who is 
> calling via his home network (signalling) hosting the PUA the 
> home network (PUA) of the called user. The called user may 
> also be attached to a serving destination network. Between 
> each of the four networks there may be additional transit 
> networks, the media could finally go directly from the orig 
> serving network to the dest serving network. What is payed 
> IMHO in the future is mainly the access on both sides (fixed, 
> ADSL, cable, GPRS, WLAN, etc.) and the hosting of the 
> Personal User Agents (PUA) on both sides.
> 
>  
> > This again goes back to the core issue we were dealing with 
> > in Yokohama 
> > ...where does call control reside.  I have taken the view 
> > that for privacy 
> > reasons and various others it is the called party that 
> actually is in 
> > control of the call session ..not the calling party. I choose 
> > not to expose 
> > any data in the global DNS except the absolute minimum necessary to 
> > establish a session between who is calling me and my 
> > endpoints. I delegate 
> > to my SIP proxy or other SRS/Presence server the control of 
> > how/when and by 
> > what manner I choose to be contacted.
> 
> The privacy issues are handled by the PUAs, and you should 
> consider that the calling party also have a PUA. In the UCI 
> approach finally the PUAs will negotiate.
> 
> > The opposite view ..is of course that the calling party wants 
> > control and 
> > want the maximum flexibility in selecting how and by what 
> > means the called 
> > party is contacted. This argues for what you and Ranali/Walter have 
> > proposed.  Both are legitimate technival views but I submit 
> > it is up to the 
> > end user to decide.
> 
> I think both sides have their share, as stated above.
> 
> Regards
> Richard
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum