Subject: Re: [Enum] General question on Enumservices

From: "Stastny Richard" <[email-masked]>
Date: Fri, 24 Feb 2006 23:13:00 +0100

Jim,

>I believe the original intent of ENUM was to facilitate the smooth transition from E.164 numbers to SIP URIs.  
 
This is not correct, historically.
Funny: originally the basic idea of ENUM was exactly where we are now:
The replacement of the business card
This was killed by SPAM and privacy sherriffs.
Then for some time it looked that the only feasable enumservice was SIP and only SIP
Some proposals from us got killed (remember vovi) and others had a very hard time (msg)
because it was said SIP is enough, because one may do anything by establishing
a sip session and negotiate the rest later. Eventually one may use Pres
(I never completely understood why one needs pres if you have sip (or IM),
but not video:sip, but I am not an AD.
Now we are round the full circle ;-)
 
My position here is somewhere in the middle. I have learned that
the original business card idea putting everything in the DNS is not so good,
but I also know you cannot do anything with SIP. The vcard approach makes sense,
and of course we need additional Enumservices such as email:mailto, because
not everybody has all services with one (sip) provider.
 
But we should be careful not to overdo it simple because it will get too complicated
for the end-user
 
>But with all these Enumservices, we may achieve exactly the opposite effect, by making E.164 numbers indispensable. 
>I assume this is not our intent.
 
Hmm, aren't they indispensible?

How many people can you reach via a SIP URI and how many with a phone number?
How many large voice providers give you a sip URI? 

And I still wonder how they will provide global connectivity
with SIP URIs (public user identities) in IMS

Richard

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

---

From: lconroy <[email-masked]>
Date: Sat, 25 Feb 2006 23:30:33 +0000

Hi Richard, Jim, Axel, folks,
  I speak as a co-author and thus having felt the pain with vovi and  
msg (and the rest).
It has indeed been a long and winding road. However... given where we  
are, telephone
numbers are "where it's at" for the vast majority of folk out there  
(for which read,
customers), so telephone numbers are convenient unless and until it  
proves impossible
to get approved registration in a single tree. I still believe that  
there is a place
for user ENUM, and that storing contacts in this way is useful to end  
users. It's just
taken somewhat longer than it should, in no small part due to intense  
discussion of
alternatives and baroque definitions of consumer protection  
requirements.

However, before Axel and the mob spend another 3 years grinding a  
Vcard:http Enumservice
through the system and experiencing yet more pain, perhaps we should  
look at what we have
already.

Yes - one could have a LOT of NAPTRs in a zone if one includes every  
possible way of
contacting the registrant. However, these do not have to be in the  
same domain/owner.

Non-Terminal NAPTRs are already "on the books:, and whilst  
understanding how they work
is fiercely difficult, they DO allow sets of contacts to be  
partitioned - that's what
they were designed to do. Thus it IS possible to include extra NAPTRs  
in other domains
and "point to" those with a Non-Terminal NAPTR or two.

In practice, how many contacts will people publish? - I doubt most  
people will have more
than 10 or 20, in which case partitioning into main and "auxiliary"  
sets is not hard at all.
It may take a year to develop a client to deal with Non-Terminal  
NAPTRs properly, but from
experience that has to be quicker than getting a Vcard Enumservice  
defined and approved
(even in ETSI, Richard :).

I also agree that the Vcard proposal still not quite removed from the  
drafts archive will
be fine for authenticated (i.e. private/protected) access to Vcard  
data. It's a different
use case. Personally, I would MUCH prefer it to have :http and :https  
sub-types, as a caller
may only be interested in a secured set of data (or conversely a  
"public/anonymous" set),
and so will process only :https or :http Vcard Enumservices.  
However... other than that
I think it's fine. Setting up secured connections to HTTPS servers  
will take time and
bandwidth, but for many users this is not going to be a problem. For  
those who don't want
to wait (or pay the GPRS roaming charges 8|, let's use Non-Terminal  
NAPTRs.

all the best,
   Lawrence

On 24 Feb 2006, at 22:13, Stastny Richard wrote:
> Jim,
>> I believe the original intent of ENUM was to facilitate the smooth  
>> transition from E.164 numbers to SIP URIs.
>
>> But with all these Enumservices, we may achieve exactly the  
>> opposite effect, by making E.164 numbers indispensable.