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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx and not harald.alvestrand@xxxxxxxxxx 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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx] > Sent: Tuesday, November 28, 2006 9:25 AM > To: John C Klensin; Dave Crocker > Cc: ietf@xxxxxxxx > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf