Subject: RE: [Enum] General question on Enumservices

From: "Mark Hewitt" <[email-masked]>
Date: Fri, 24 Feb 2006 12:31:11 -0500

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

-----Original Message-----
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

_______________________________________________
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: "Peter Williams" <[email-masked]>
Date: Sat, 25 Feb 2006 15:12:46 -0800

>From: "Mark Hewitt" <[email-masked]>
>To: "Stastny Richard" <[email-masked]>,<[email-masked]>
>Subject: RE: [Enum] General question on Enumservices
>Date: Fri, 24 Feb 2006 12:31:11 -0500
>
>Richard;
>

Hmmm.

[email-masked].  I think Ive seen that somewhere, before, on my 
"nicely converged" windowsmobile IP cellphone/PDA/sipclient!

I suppose IETF could add some value by leading the pack with an ENUM/SSO 
that obligates presentation of said id (an "ENUM-SENDER-ID enumservice") to 
detectably come (somehow) only from a (nationally-regulated) device that was 
provisioned with said E.164 name rights by a regulated carrier, or a SIP PBX 
falling ultimately under national regs. This would basically add a 
"national-regulation assurance" to the SSO scheme, such as passport - which 
is a valuable assurance, lets face in  to parties transacting business 
across an open network.

As we are talking only about design that make money for folks, its main 
problem is that the revenue derived from this value of this assurance is 
obtained by the passport SSO provider versus the core provider (the 
regulated carrier) , given the SSO broker can freely leverage/repurpose the 
assurance delivered by the phone companies regulated by public tarifs.

><< smime.p7s >>