|
Re: IM and Presence history
2006-11-28 20:08:05
Phillip,
you might want to look at the SIP design, which offers most of the
functionality you describe already. The notion of a common address
(prefixed to generate a URL by the communication scheme, be it sip:
or, more generically, pres: or im:) were part of the design, although
there is nothing but local administrative convention that can ensure
that this is true. Indeed, there was an expired I-D that described
this identity relationship in more detail.
The SIP identity work describes one mechanism to ensure reliable
identity assertions, even in the absence of S/MIME.
Henning
On Nov 28, 2006, at 11:27 AM, Hallam-Baker, Phillip wrote:
I think you add clarity, not confusion.
There is only one communication space. We should stop thinking
about an 'email address' and think about a 'user address' instead.
[I know that I have promised to deliver an architectural statement
on this, it is written and I am working to get it released]
We should have one architecture for communicating with
harald(_at_)alvestrand(_dot_)no regardless of the medium or the modality.
Mail, IM, video, audio.
Part of that architecture should be spam and bozo filtering.
Part of that architecture should be the ability to claim that
identity at any site by means of an authentication protocol.
Incidentally, it does need to be harald(_at_)alvestrand(_dot_)no and not
harald(_dot_)alvestrand(_at_)gmail(_dot_)com(_dot_) Google, Yahoo and co need to stop
trying to turn us into serfs by refusing to allow us to own our own
online identity. Stop trying to make a service sticky by making it
costly to switch providers.
The common architecture must resolve through the DNS. This may seem
an obvious statement but there are folk currently burning through a
few million a month of VC money trying to establish their own
namespace so the statement does need to be made.
Email servers are discovered through MX, SRV provides generalized
service discovery. A policy layer allows for meta-discovery, the
client can find out in one request the set of supported protocols.
If I want to send an email to harald(_at_)alvestrand(_dot_)no the client
resolves the mx record for alvestrand.no, and does an SMTP
transaction, the same rule should apply for IM, video, VOIP, etc. etc.
We also need a couple of lightweight protocols to add a little glue
to the system. These are not so much protocols as profiles of
existing work
First protocol is a means of discovering the authentication
services that are supported. So when Harald wants to log into an
arbitrary blog on the net to post a comment he does not need to
create an account at each one. (e.g. use SAML, WS-*)
Second protocol is a very constrained messaging format that allows
a contact message to be exchanged but nothing more. So when I meet
Harald at the IETF and we exchange cards I send him a contact
message saying 'This is Phill H-B, we met at the IETF, please add
me to your contacts'. (e.g. use SMTP)
Third protocol is a contacting protocol. I want to set up a voice
conversation with Harald. I type in his user address, my client
talks to his contacting protocol service. This handshake begins
with mutual authentication so that his client knows it's the real
Phill. Then it looks at the preferences that Harald has set up and
determines that Phill is allowed to make contact by voice or video
but only during business hours. My voice call is automatically
routed to his voicemail. (e.g. use SIP)
Fourth protocol is some form of Friend-of-a-friend exchange to
provide data to help drive the contacting protocol. So the
contacting protocol consults the FoaF network and discovers that I
am in the networks of six people in his network. (e.g. use RDF/FoaF)
The point here is not the protocols themselves, it's the glue that
matters. The protocols are essentially there but the glue is
missing and the glue is what makes all the difference.
Harald cannot afford the time to take telephone calls from every
random person he meets at the IETF, this will be particularly true
after we have turbocharged his communications capability and
effectively made his former email address serve as his telephone
number. So now he has the Paris Hilton problem of every crank in
the universe trying to call him. The traditional solution to this
is security through obscurity, hiding the contact address and only
giving it out to a restricted circle. The better solution is to
adopt the same strategy she uses to protect here physical security,
her home address is a matter of public record, she employs a
doorman to control access.
We can't implement the doorman function without close coupling
between all four of the protocols.
We are in the Google era of communications. Users demand more than
functionality. They want functionality without fuss, complexity or
adornment.
Just give us the right to own our names. The system I describe
requires a non-trivial investment on the part of the user. That has
to be my property, not held hostage by my ISP.
-----Original Message-----
From: Harald Alvestrand [mailto:harald(_at_)alvestrand(_dot_)no]
Sent: Tuesday, November 28, 2006 9:25 AM
To: John C Klensin; Dave Crocker
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: IM and Presence history
just to add to the confusion...
gmail will actually store the transcripts from your gtalk
sessions in your gmail inbox. Blurring the difference again....
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|