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