Subject: RE: [Enum] Triggering ENUM Queries

From: "Stastny, Richard" <[email-masked]>
Date: Fri, 31 May 2002 09:22:22 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Fri, 31 May 2002 13:04:28 -0600

> different URIs and services.

I think this is the crux of the issue, e.g. ENUM will ultimately be used as a way of resolving an arbitrary E.164 number into associated PUA services, but the bootstrapping of ENUM may depend on more exposure of these services until the interfaces and protocols for PUA services are well defined and widespread.

This is why the schema matters, since the success of the bootstrap depends on the widespread use of a well-defined, well-understood service schema that doesn't have more than a dozen elements. I continue to assert that the basic intent of the inquiry should be the predominating factor in enumservice selection, e.g.:

- I want to talk to the entity behind this E.164 number
- I want to deposit a message for the entity behind this E.164 number
- I want to enter a chat session with the entity behind this E.164 number
- I want to use a share a collaborative application with the entity behind this E.164 number
- I want to go to the web site for the entity behind this E.164 number
- I want to see my options for communication with the entity behind this E.164 number
- I want to validate the identity of the entity behind this E.164 number

and eventually a wildly successful deployment might lead to:

- I want to post a micropayment to the entity behind this E.164 number
- I want to post an invoice to the entity behind this E.164 number
- I want to get location information for the entity behind this E.164 number (as a PSAP, for instance)

and even more interesting concepts where the intent is very different than communications and the transactions happen elsewhere but use the E.164 number as a means of identity resolution for entities human and machine, organized and grouped under a single entity like a corporation or government or just individual devices or an individual role for a single person. The point is that E.164 numbers are used for all of these purposes today but require active human participation to complete these transactions, so these scenarios aren't as far fetched so long as identity and policy systems are available to the participating entities.

Anyway, the point here is a simple request to stick to the definition of vertical that we started with

-or-

draw a different matrix and call the resulting scheme 'vertical scheme from matrix2' or something that clearly distinguishes it from the original vertical.

--Andy