Subject: Re: [Enum] General question on Enumservices

From: "Lupton, Ronan" <[email-masked]>
Date: Sat, 25 Feb 2006 00:12:16 -0000

Mike your correct!

Bell v. Net. Debate 2.0

If more people would bother to think outside the box we would not have to
entertain such trivia.

Regards,

R.

-----Original Message-----
From: Michael Hammer (mhammer)
To: Tony Rutkowski; Stastny Richard; [email-masked]
Sent: Fri Feb 24 23:57:48 2006
Subject: RE: [Enum] General question on Enumservices

In the end, which number/name is the index (business card) to the others
is arbitrary.

The choice of E.164 number is an artifact of the fact that phones have
keypads (0-9, #, *) and most of the world uses phones, while access to
computers is not as universal.

Beyond that, the main concern is to have an address associated with a
protocol (need that clue) that can be used to further the
communications.

Mike

> -----Original Message-----
> From: Tony Rutkowski [mailto:[email-masked]] 
> Sent: Friday, February 24, 2006 5:47 PM
> To: Stastny Richard; [email-masked]
> Subject: Re: [Enum] General question on Enumservices
> 
> Hi Richard,
> 
> >2. USER ENUM is for the End User = Customer The service is providing 
> >him a domain in ENUM He is willing to pay for this only if 
> it gives him 
> >some value the more value (more potential use) he gets out 
> of it, the 
> >more he is willing to use it AND in addition the user is pointing in 
> >ENUM again to services. So the more services he may point to, the 
> >better for service providers
> 
> All of this is nice in theory.  However, it's apparent that 
> the nature of the services being provided as well as the 
> interactions among multiple kinds of providers of services 
> associated with a single number is significantly more complex 
> for both the user and providers involved, as well as subject 
> to all kinds of authentications as part of the associated
> administrative processes.   Someone will bear those costs
> and it's not clear who will want to get left "holding the 
> bag" for some flat rate, and be unable to charge for 
> supplementary services.  So the cost model remains unclear.
> 
> Additionally, all the nations of the world add substantial 
> regulatory, justice, and security burdens on top of this 
> identifier system that get more complex and extensive by the 
> day.  (Check out today's FCC delegation of number
> pooling to the State Commissions.)   At last check, these
> burdens include:  number portability, priority access, 
> roaming, directory assistance, callerid, disability 
> assistance, language preference, personal emergency 
> (E112/911), law enforcement assistance (including data 
> retention in many countries), public emergency alerts, 
> donotcall, intercarrier compensation, service provider specification.
> 
> ENUM is cool.  However, the administrative challenges and 
> sorting out of the associated burdens and costs is non-trivial.
> 
> --tony 
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: "Stastny Richard" <[email-masked]>
Date: Sun, 26 Feb 2006 00:36:40 +0100

>I agree many of these parameters could be included in a vcard and indeed
>should but I dont see why we should restrict individual application
>submissions.

>But as usual I could be wrong.

Of course you are wong ;-)
I already wanted to answer your previous e-mail

I never said I wanted to restrict individual applications;
especially because they bring forward potential use cases

I just wanted a discussion if some of the may be covered also
by other means

Richard
PS: Maybe we finally found a new killer application for (End) User ENUM
to make Tony happy
BYO personal Enumservice ;-)

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: So 26.02.2006 00:03
An: Stastny Richard
Cc: Mark Hewitt; [email-masked]
Betreff: Re: [Enum] General question on Enumservices

Stastny Richard wrote:
>> So let's think about how ENUM can support vCard rather than devise an
>> entirely new protocol, service, and technology.
> 
> There seems to be a slight misunderstanding
> 
> I did not propose anything like that
> 
> On the contrary, IMHO some of the new proposed Enumservices
> could be replaced by using vcard

Well a reminder that the vcard draft we reviewed in Vancouver is a WG
item we have not as yet seen another version. Minutes attached. I
certainly thought this was a "good idea" tm.

I agree many of these parameters could be included in a vcard and indeed
should but I dont see why we should restrict individual application
submissions.

But as usual I could be wrong.

IANA Registration for ENUMservice vCard  10-Min
===============================================

        Author(s)       : A. Mayrhofer, D. Lindner
        Filename        : draft-mayrhofer-enum-vcard-00.txt
        Pages           : 7
        Date            : 2005-10-5
       
  This memo registers the ENUMservice "vCard" using the URI schemes
http" and "https" according to the IANA ENUMservice registration process
described in RFC3671.  This ENUMservice is to be used to refer from an
ENUM domain name to the vCard of the entity using the  corresponding
E.164 number.

   Clients may use information gathered from those vCards before, during
or after inbound or outbound communication takes place.  For example, a
callee might be presented with the name and association of the caller
before he picks up the call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt

DISCUSSION:

ENUMservice for refering from phone numbers to URIs containing vCard.
Came from questions from service providers which wanted to publish.
Usage scenario: query for number, receive vCard URI, fetch vCard.

No subtypes defined right now, two URI schemes (http and https) proposed
now.

Feedback received about subtypes: Should subtypes reflect protocol?

Faltstrom (as WG member): Privacy constriants, and granularity
limits of HTTP. vCards could be synthesized based on authentication.
HTTP not optimal for detailed access constraints. A bit nervous that
usage of http is too quick. Recommend at least subtyping because good WP
systems should not use http, but could be started
with http now. Suggestion is to check HTTP, LDAP, IRIS

Shockey: Want to see granularity on access control as well.

Schiefner: Would like to see this a WG item, looking at moving that forward.

Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if
granularity is what people expect from publishing a vCard.

Jimmy ??: Suggestions to granularity on access controls could be out of
scope of the ENUM WG?

Mayrhofer: Could simply say "we make the reference, what behind this is
out of scope for ENUM".

Faltstrom: Clarification on privacy needed.

Baskin: Privacy needs to be highlighted each time. However, "ENUM" does
not the vCard, ENUM just returns a reference. It's done after the lookup.

Faltstrom: Agreed, need to be subtyped to differentiated.

??: There is a draft about vCard over WebDAV in the calendaring for
WebDAV. draft-debut-carddav?

Schwartz: Issues on identifying when using HTTP.

WG ACTION: Based on a hum of the WG, consensus for adopting this as WG item.

> 
> Richard
>
> ________________________________
>
> Von: Mark Hewitt [mailto:[email-masked]]
> Gesendet: Fr 24.02.2006 18:31
> An: Stastny Richard; [email-masked]
> Betreff: RE: [Enum] General question on Enumservices
>
>
>
> Richard;
>
> Good observation however consider for a moment that the structure of DNS is
> already well established and considered part of every basic IP device today.
> ENUM is simply a series of extensions for indexing more complex services
> than just the translation of an IP address to a name and the reverse.
>
> There are certainly more efficient protocols and technologies than the
> weighty IP protocol today - yet it is an accepted standard - DNS is the
> same.
>
> Some additional extensions of services now include "Identity Management" -
> allowing for a single logon to member services and sites.
>
> So let's think about how ENUM can support vCard rather than devise an
> entirely new protocol, service, and technology.
>
>
> _______________________________
>
>
>
> Mark S. Hewitt
> (813) 849-7821 Direct
>
>
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Friday, February 24, 2006 9:27 AM
> To: [email-masked]
> Subject: [Enum] General question on Enumservices
>
> Folks,
>
> I have a general question concerning Enumservices
>
> Considering the bunch of the different Enumservices
> popping up recently I ask myself if we are not overdoing it
>
> On one hand a lot of people seem to have very creative
> ideas on what kind information one may link to a
> communication identifier such as an E.164 number
>
> So we are back to the original idea of the electronic
> business card.
>
> Bernie mentioned in context with the IM service that
> one my put all is Yahoo, aol, icq, jabber etc ID into
> ENUM and somebody else may try to find out which is
> matching his service.
>
> If I add now to this the webpage, email, vcard, calendar,
> eventually the old idea we had in TS 102 172 with
> location (loc), and the public KEY (eh domainkey?), ...
>
> I see ENUM domains coming up with 20 and more entries.
>
> Most of this information could be put into vcard
>
> If not, we may consider one or two general pointers
> containing all the required information, e.g.
> publicinfo and privateinfo and define the template
>
> This would allow on one hand sceened access with policies
> and on the other hand more flexibility in data provisioning
>
> Thoughts?
>
> Richard
>
>

--

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: <[email-masked]>
Date: Sun, 26 Feb 2006 21:13:40 +0100

Dear Richard, dear colleagues,

After scanning the mail traffic generated in the last days in response to
Richard's "general question" I would like to comment on the issue of general
need for new Enumservices. In my opinion (at least) three groups of users have
to be differentiated with all of them possibly having different needs:

1. End Users maintaining their own User ENUM entries - typical usage scenarios
being end user VoIP, the electronic business card case or ENUM-enabled
applications (e.g. e-mail clients)

2. Providers maintaining their own Infrastructure ENUM entries - typical usage
scenarios being VoIP interconnection or number portability issues

3. Third party service providers creating new services relying on publicly
available data from both User and Infrastructure ENUM

Looking at these three groups one can imagine that the individual players can
have strongly differing needs with regard to the Enumservices available. The
introduction of a new Enumservice for each and every new idea, however, will
not work in terms of scalability, overall clarity and time-to-market. Instead
of introducing a huge pile of new Enumservices it could be a better way forward
to use generic Enumservices like the “vCard” or (my very own) “foaf” proposal.
Both follow the concept of opening a door to other identifiers and services
allowing e.g. RDF/XML parsers to retrieve information made available. Therefore
existing and upcoming identifiers (services) could easily be accessed with
Skype, flickr, del.icio.us, woo2do, 43things, writely, plazes, openomy,
CalendarHub or RSS blog feeds being just a few examples. Any comments on this?

Best regards, Kurt.

P.S.: Don't slap me too hard as this is my first posting. ;-)

>
> Von: "Stastny Richard"
> Datum: 2006/02/26 So AM 12:36:40 CET
> An: "Richard Shockey"
> Cc: [email-masked], Mark Hewitt
> or
> ;

---

From: <[email-masked]>
Date: Mon, 27 Feb 2006 8:19:57 +0100

Sorry for the strange formatting of my previous mail - hope this works better now.

After scanning the mail traffic generated in the last days in response to Richard's "general question" I would like to comment on the issue of general need for new Enumservices. In my opinion (at least) three groups of users have to be differentiated with all of them possibly having different needs: 

1. End Users maintaining their own User ENUM entries - typical usage scenarios being end user VoIP, the electronic business card case or ENUM-enabled applications (e.g. e-mail clients) 

2. Providers maintaining their own Infrastructure ENUM entries - typical usage scenarios being VoIP interconnection or number portability issues 

3. Third party service providers creating new services relying on publicly available data from both User and Infrastructure ENUM 

Looking at these three groups one can imagine that the individual players can have strongly differing needs with regard to the Enumservices available. The introduction of a new Enumservice for each and every new idea, however, will not work in terms of scalability, overall clarity and time-to-market. Instead of introducing a huge pile of new Enumservices it could be a better way forward to use generic Enumservices like the “vCard” or (my very own) “foaf” proposal. Both follow the concept of opening a door to other identifiers and services allowing e.g. RDF/XML parsers to retrieve information made available. Therefore existing and upcoming identifiers (services) could easily be accessed with Skype, flickr, del.icio.us, woo2do, 43things, writely, plazes, openomy, CalendarHub or RSS blog feeds being just a few examples. Any comments on this? 

Best regards,       Kurt. 

> 
> Von: <[email-masked]>
> Datum: 2006/02/26 So PM 09:13:40 CET
> An: <[email-masked]>
> Betreff: Re: Re: [Enum] General question on Enumservices
> 
>

---

From: "James McEachern" <[email-masked]>
Date: Tue, 28 Feb 2006 22:38:07 -0500

Richard,
I fully understand that E.164 numbers are indispensable in the short term.  My question was whether the intent was to make E.164 numbers more, or less, important in the long term. 

Jim 

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 5:13 PM
To: McEachern, James [CAR:5N00:EXCH]; [email-masked]
Subject: Re: [Enum] General question on Enumservices

>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

---

From: "James McEachern" <[email-masked]>
Date: Tue, 28 Feb 2006 22:38:57 -0500

Richard,
You correctly point out that 

> ... there are two globally reckonized naming and addressing schemes for 
> communications. E.164 and the ICANN domain root.

> ENUM is the definitive mapping between the two.

Part of my earlier point was that ENUM may be the definitive mapping, but it is only a one way mapping, which effectively makes E.164 the definitive global addressing scheme.  Maybe I'm missing something here, but this still seems ironic for an IETF working group.

Jim

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 9:40 PM
To: Michael Hammer (mhammer)
Cc: [email-masked]; Stastny Richard; Scott Bradner; Tony Rutkowski
Subject: Re: [Enum] General question on Enumservices

> computers is not as universal.

and E.164 numbers are linguistically neutral. We cannot forget there are 
two globally reckonized naming and addressing schemes for 
communications. E.164 and the ICANN domain root.

ENUM is the definitive mapping between the two.

All others are private silo, such as most IM or P2P systems and skype. 
These have their place in the world.
> protocol (need that clue) that can be used to further the

I have to admit that some of this discussion over Enumservice 
registrations is mildly amusing to me. I too have vacillated between 
what is caller vs called party control of communications and I tried to 
touch on this in my security and privacy draft that I'm continuing to 
review.

I see no reason to restrict what Enumservices should be registered 
..this is what markets are for.  We will not decide what prevails.

 >> sorting out of the associated burdens and costs is non-trivial.

Tony .. you admitting that ENUM is 'cool' after all these years is high 
praise indeed. :-) Many of us remember when you thought otherwise.

Best wishes as always,

--