Message-ID: <B1949C387101D411A95100508B8B951323C9CC@OEFEG-MAIL>
From: "Stastny, Richard" <richard.stastny@oefeg.at>
To: "'Richard Shockey'" <rich.shockey@NeuStar.com>, "'Michael Mealling'"
 <michael@neonym.net>
Cc: Brandner Rudolf <Rudolf.Brandner@icn.siemens.de>, enum@ietf.org
Subject: RE: [Enum] Triggering ENUM Queries
Date: Fri, 31 May 2002 09:22:22 +0200
MIME-Version: 1.0
Content-Type: text/plain
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
Precedence: bulk

Rich wrote:

> Michael has a excellent point here that I have a lot of 
> trouble with ... Is 
> the DNS the appropriate mechanism to display all the user 
> preferences for 
> communication ... IMHO NO ... this is something I want to 
> have more control 
> over either in a directory that can authenticate who is 
> asking for the 
> information or SIP where a defined CPL that has the expression of my 
> preferences or other mechanism can be used to define or transfer the 
> session to something else.
> 
I think this is exactly one of the issues why we see nor progress here.
There are a lot of variants how you can use ENUM, the two extremes are:
1. put everything you want to be known in ENUM, ending up with a lot NAPTRs
2. put ONE pointer to a Personal User Agent (PUA), which controls your
complete communication (including screening, filtering, etc.)

Of course, for the group heading in the second direction, the whole
discussion on enumservices is somewhat ridiculous, they say (depending in
the multiservice they prefer), just put in sip, h323, pres, srs, uci, ....

And here we are again at the point: as long as we do not have these
multiservices PUAs in operation, we have to live with the multiple NAPTRs,
different URIs and services.

I my personal opinion, the future will be with the PUA type services, and
thats exactly the reason why I am also involved in UPT and UCI (Universal
Communications Identifier) (see 31-WP1 from lthis May SG2 or ETSI STF180).
And this is also the reason, why we requested the delegation og +87810 for
ENUM (which was approved in May SG2). With UPT, you terminate on the same
PUA regardless if you are using the GSTN with the UPT number or ENUM
pointing to a H323 or SIP-address.

There is also a clear path from ENUM via UPT to UCI (the numeric key of UCI
will be an E.164 numbers). But we all should keep one thing in mind: if
UPT/UCI is fully implemented as intended, you do not need (User) ENUM
anymore (maybe infrstructure ENUM). This means, that the window of
opportunity for ENUM is closing very fast.

Little remark: currently ITU SG2 is progressing more and faster with ENUM
then the IETF.
As far as the ITU is concerned, we can start with the trials in e164.arpa
now, as far as the IETF ENUM WG, we cannot, because there is not a single
enumservice defined.

> Exactly we need to see how all of this works but ultimately 
> it will be user 
> that has control over the e.164 number that  registers it 
> under e164.arpa 
> and my suspicion is that will be a minimalist set listed . Just MHO

Yes, if the services are available and compatible. Everybody now may have an
e-mail address, but where can I subcribe a full sip service? BTW, where can
a subscribe a sip service, where I am able to get a sip URI sip:user@host? 
  
> or another variation ...use LDAP
 
Yes, I have some ideas on the stack with LDAP (e.g. names, addresses, public
keys, etc.)
 
 
> On this BTW I really agree with this there is a lot of investment in 
> freephone numbers. On the SIP side I've almost considered 
> doing a ID on a 
> new SIP header for HTTP URI so that all the new SIP phones 
> with color LED's 
> can display the web page of the called party...useful for 
> Pizza Specials etc.
> 
I have seen this idea a long time ago (2-3 years?)in TIPHON for h323,
exactly for this purpose. I think it was from Nokia or Ericsson. I have no
idea what happend to this. Maybe you ask Melinda.

Regards
Richard


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum