Subject: RE: IM and Presence history

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Nov 2006 08:27:12 -0800

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 [email-masked] 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 [email-masked] and not [email-masked]. 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 [email-masked] 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:[email-masked]] 
> Sent: Tuesday, November 28, 2006 9:25 AM
> To: John C Klensin; Dave Crocker
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: Simon Leinen <[email-masked]>
Date: Tue, 28 Nov 2006 20:32:19 +0100

Hallam-Baker, Phillip writes:
> Incidentally, it does need to be [email-masked] and not
> [email-masked]. 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. 
 
I don't know about Yahoo! and co., but Google has a
"bring-your-own-domain" version of some of its services, including
Gmail, see: http://www.google.com/a/ - which allows exactly that.

Disclaimer: This is in beta like so much of Google's stuff, and new
users have to be "approved" - worked instantly for me.  And I don't
have Google shares or something... just a happy user (I almost said
customer... it's easy to forget that Google's users aren't their
customers but their "merchandise" :-).  And my employer provides
DNS-related services.
-- 
Simon.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Nov 2006 22:04:26 -0500

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:

> 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  
> [email-masked] regardless of the medium or the modality.  
> Mail, IM, video, audio.
>
> Part of that architecture should be the ability to claim that  
> identity at any site by means of an authentication protocol.
>
>
> 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 [email-masked] 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 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.
>
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 29 Nov 2006 12:54:39 +0100

> customers but their "merchandise" :-).  And my employer provides
one nice thing about the schema/protocol being part of the naming scheme 
is that it does *not* tie me to a single provider for all services - my 
jabber service for [email-masked] is provisioned from someone 
who's got no relationship at all to my mail and web services.

                     Harald

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Nov 2006 10:33:15 -0800

> who's got no relationship at all to my mail and web services.

There is an architectural 'trick' here, that I suspect is the key for making 
thing homogenize in a way that is tractable:

      The underlying specifications permit you to have different addresses, for 
different services.  They also permit you to have the *same* address.

So the fact that your jabber and email and... (whatever) services all get data 
to you via "[email-masked]" is an administrative choice, not one imposed 
by some grand unifying architecture that needed to be designed perfectly from 
the start.

The only "architectural" rule needed for this is to recommend that folks base 
new adddressing on an existing scheme, to avoid collissions.  For example, an 
administrative rule that foo:[email-masked] is only available for 
registration to the recipient of mailto:[email-masked] is all that is 
needed to make this work.

(Anyone paying close attention will note that this introduces a problem with 
getting a foo: address that is not the same as the email address but is not 
assigned to anyone else. But what the heck, I'm not trying to design the whole 
thing right now...)

At any rate, this is a version of the "think globally, act locally" approach to 
architecture design that good Internet technical work did well.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Nov 2006 14:51:15 -0500

See 
http://www.softarmor.com/wgdb/docs/draft-schulzrinne-sipping-id-relationships-00.txt 
for an expired draft on this topic.

> There is an architectural 'trick' here, that I suspect is the key for 
> making thing homogenize in a way that is tractable:
> 
>      The underlying specifications permit you to have different 
> addresses, for different services.  They also permit you to have the 
> *same* address.
> 
> So the fact that your jabber and email and... (whatever) services all 
> get data to you via "[email-masked]" is an administrative choice, 
> not one imposed by some grand unifying architecture that needed to be 
> designed perfectly from the start.
> 
> The only "architectural" rule needed for this is to recommend that folks 
> base new adddressing on an existing scheme, to avoid collissions.  For 
> example, an administrative rule that foo:[email-masked] is only 
> available for registration to the recipient of 
> mailto:[email-masked] is all that is needed to make this work.
> 
> (Anyone paying close attention will note that this introduces a problem 
> with getting a foo: address that is not the same as the email address 
> but is not assigned to anyone else. But what the heck, I'm not trying to 
> design the whole thing right now...)
> 
> At any rate, this is a version of the "think globally, act locally" 
> approach to architecture design that good Internet technical work did well.
> 
> d/
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Nov 2006 16:20:12 -0800

Henning,

Henning Schulzrinne wrote:
> (prefixed to generate a URL by the communication scheme, be it sip: or, 
> more generically, pres: or im:) were part of the design, 

SIP obtained this design from previous work on IM and Presence:

<http://www1.ietf.org/mail-archive/web-old/ietf-announce-old/Current/msg21041.html> 
contains the announcement.

I can't seem to track down the original draft of draft-ietf-impp-srv-00, 
"Address Resolution for Instant Messaging and Presence" which provided the 
initial generalization.

d/
-- 

   Dave Crocker

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 29 Nov 2006 19:23:27 -0500

On Wed, 29 Nov 2006 10:33:15 -0800

> addresses, for different services.  They also permit you to have the
This is only a good idea if coupled with a powerful, easy-to-use
interface that restricts presence visibility.  Many more people have my
email address than my IM addresses; I'm also very careful about who
gets my mobile phone number.  Why?  Because IM communication and phone
calls interrupt me in a way that email does not.  In fact, I take
advantage of email to avoid giving out the other information
promiscuously -- I tell people who perceive an urgent need to reach me
to email page-smb at the appropriate domain; this address is translated
to both SMS and a direct email message.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb