Re: IM and Presence history

[Dave Crocker]

Dave Crocker wrote:

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


Sorry.  The reference I gave was to the later specification that split the DNS 
SRV usage.


The original design seems to have been in:

   A Common Profile for Instant Messaging (CPIM)
   draft-ietf-impp-common-01
   November 2000

I've attached a copy, since I can't find one through a Google search and the 
historical reference is worth recording.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net



Network Working Group D. Crocker
Internet-DraftBrandenburg Consulting
Expires: April 1, 2001   A. Diacakis
 F. Mazzoldi
   Network Projects Inc.
  C. Huitema
   Microsoft Corporation
G. Klyne
Content Technologies
 M. Rose
Invisible Worlds
J. Rosenberg
   R. Sparks
 dynamicsoft
   H. Sugano
   Fujitsu Laboratories Ltd.
   November 2000


 A Common Profile for Instant Messaging (CPIM)
   draft-ietf-impp-common-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 1, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract


Crocker, et. al. Expires April 1, 2001  [Page 1]

Internet-DraftCPIM November 2000


   Semantics and data formats for common services of Instant Messaging
   and online Presence, independent of underlying transport
   infrastructure, are described. The CPIM profile meets the
   requirements specified in RFC 2779 using a minimalist approach
   allowing interoperation of a wide range of IM and Presence systems.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 A Note on The Examples . . . . . . . . . . . . . . . . . .  3
   2.  Abstract Messaging Service . . . . . . . . . . . . . . . .  4
   2.1 Overview of the Messaging Service  . . . . . . . . . . . .  4
   2.2 Identification of INSTANT INBOXes  . . . . . . . . . . . .  5
   2.2.1   Address Resolution . . . . . . . . . . . . . . . . . . . .  5
   2.2.1.1 Domain Name Lookup . . . . . . . . . . . . . . . . . . . .  5
   2.2.1.2 Processing SRV RRs . . . . . . . . . . . . . . . . . . . .  6
   2.2.1.3 Processing Multiple Addresses  . . . . . . . . . . . . . .  6
   2.3 Format of Instant Messages . . . . . . . . . . . . . . . .  7
   2.4 The Messaging Service  . . . . . . . . . . . . . . . . . .  8
   2.4.1   The Message Operation  . . . . . . . . . . . . . . . . . .  8
   2.4.2   Looping  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Abstract Presence Service  . . . . . . . . . . . . . . . . 10
   3.1 Overview of the Presence Service . . . . . . . . . . . . . 10
   3.2 Identification of PRESENTITIES . . . . . . . . . . . . . . 11
   3.3 Format of Presence Information . . . . . . . . . . . . . . 12
   3.4 The Presence Service . . . . . . . . . . . . . . . . . . . 13
   3.4.1   The Subscribe Operation  . . . . . . . . . . . . . . . . . 13
   3.4.2   The Notify Operation . . . . . . . . . . . . . . . . . . . 15
   3.4.3   The Unsubscribe Operation  . . . . . . . . . . . . . . . . 16
   4.  Security Considerations  . . . . . .

RE: IM and Presence history

[Hallam-Baker, Phillip]

I absolutely agree with Steve here, but I think that the problem here is too 
little integration, not too much. I don't think that this security through 
obscurity scales very well.

There needs to be a gatekeeper. If someone wants to schedule a call with me, 
fine, just drop me a note first so I can tell my system to accept it. Oh and if 
you want to send more than a few lines in the note you will have to be on the 
approvals list.

CEOs and Paris Hilton already have these security measures in place.


I think that a good technical bar to set here is that a 'one address' system 
must be secure enough against unwanted contact that Paris Hilton can use it and 
post the same contact address on her Web site as Britney Spears would use to 
contact her.

If you are known directly or a friend of a trusted friend you get in, otherwise 
you get a lower level of communication, the bottom rank being directed to the 
Paris Hilton fan club.


> -Original Message-
> From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 29, 2006 7:23 PM
> To: [EMAIL PROTECTED]
> Cc: Harald Alvestrand; ietf@ietf.org
> Subject: Re: IM and Presence history
> 
> On Wed, 29 Nov 2006 10:33:15 -0800
> Dave Crocker <[EMAIL PROTECTED]> wrote:
> 
> 
> > 
> >   The underlying specifications permit you to have different 
> > addresses, for different services.  They also permit you to have the
> > *same* address.
> > 
> 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
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Steven M. Bellovin]

On Wed, 29 Nov 2006 10:33:15 -0800
Dave Crocker <[EMAIL PROTECTED]> wrote:


> 
>   The underlying specifications permit you to have different
> addresses, for different services.  They also permit you to have the
> *same* address.
> 
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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Dave Crocker]

Henning,


Henning Schulzrinne wrote:
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, 



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

 
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
  Brandenburg InternetWorking
  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Henning Schulzrinne]

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 PROTECTED]" 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 PROTECTED] is only 
available for registration to the recipient of 
mailto:[EMAIL PROTECTED] 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/



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Dave Crocker]

Janet P Gunn wrote:

The original Ethernet? (not really "discontinuous", but quite a big leap)


I think that Ethernet, like the Web, are actually excellent COUNTER-examples. 
Ethernet is Alohanet with carrier-sense, collision-detect, exponential backoff. 
 And, of course, it runs over wire rather than radio.


IMO, Ethernet and the Web represent (high quality) incremental work that had 
discontiguous impact.


The major part of the incremental work was systems-level synthesis of just the 
right set of features, at the right time.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Dave Crocker]

Harald Alvestrand wrote:
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 PROTECTED] is provisioned from someone 
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 PROTECTED]" 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 PROTECTED] is only available for 
registration to the recipient of mailto:[EMAIL PROTECTED] 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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IM and Presence history

[Hallam-Baker, Phillip]

> From: Brian Rosen [mailto:[EMAIL PROTECTED] 

> > However, what this subthread demonstrates is that they were 
> > conceptually an incremental change, not a giant, discontinuous, 
> > intellectual leap.
> > 
> > I thought we all knew that.
> Oh, I agree, we knew that.   There are very, very few discontinuous
> intellectual leaps in our part of the universe.  It's hard to 
> name one that happened in the past decade or two.
> 
> Can we name any discontinuous intellectual leaps of late in 
> computer networking?  Now that I think about it, forget "of 
> late", have there EVER been any?

People not bits: The idea that computing is about the user, not the machine.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IM and Presence history

[Janet P Gunn]

"Brian Rosen" <[EMAIL PROTECTED]> wrote on 11/29/2006 08:16:35 AM:

> > However, what this subthread demonstrates is
> > that they were conceptually an incremental change, not a giant,
> > discontinuous, intellectual leap.
> >
> > I thought we all knew that.
> Oh, I agree, we knew that.   There are very, very few discontinuous
> intellectual leaps in our part of the universe.  It's hard to name one
that
> happened in the past decade or two.
>
> Can we name any discontinuous intellectual leaps of late in computer
> networking?  Now that I think about it, forget "of late", have there EVER
> been any?
>

Turing machine? (Computers, but not Networking)

The original Ethernet? (not really "discontinuous", but quite a big leap)

Janet
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Marshall Eubanks]

On Nov 29, 2006, at 8:16 AM, Brian Rosen wrote:


However, what this subthread demonstrates is
that they were conceptually an incremental change, not a giant,
discontinuous, intellectual leap.

I thought we all knew that.

Oh, I agree, we knew that.   There are very, very few discontinuous
intellectual leaps in our part of the universe.  It's hard to name  
one that

happened in the past decade or two.

Can we name any discontinuous intellectual leaps of late in computer
networking?  Now that I think about it, forget "of late", have  
there EVER

been any?


circuit switching -> packet switching

Some people have never recovered.

Regards
Marshall




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IM and Presence history

[Brian Rosen]

> However, what this subthread demonstrates is
> that they were conceptually an incremental change, not a giant,
> discontinuous, intellectual leap.
> 
> I thought we all knew that.
Oh, I agree, we knew that.   There are very, very few discontinuous
intellectual leaps in our part of the universe.  It's hard to name one that
happened in the past decade or two.

Can we name any discontinuous intellectual leaps of late in computer
networking?  Now that I think about it, forget "of late", have there EVER
been any?


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[John C Klensin]

--On Tuesday, 28 November, 2006 22:48 +0100 Eliot Lear
<[EMAIL PROTECTED]> wrote:

> Brian Rosen wrote:
>> If you squint hard enough, everything has already been
>> invented.  Telegraph operators had a form of presence if you
>> squint hard enough.
>> 
>> Presence is a continuously updated 'display' of a set of
>> other people's status.  Finger didn't do that.  Yeah, you
>> COULD have used the mechanism to implement a form of
>> presence, but I don't remember anyone ever doing that, and if
>> they did, it didn't make anyone sit up and take notice like
>> the IM folk's buddy status systems did.
> 
> Mel Pleasant wrote a program for the DEC-20 called "watch",
> which was commonly used on many -20s at the time (this goes
> back to at least the early 80s).  You would provide a list of
> individuals you were interested in watching and the program
> would sit on top of your EXEC and occasionally burp out
> messages that So-And-So has just {logged
> {in|out}|attached|detached}.  At Rutgers we had a program that
> sat on the consoles beneath OPR that would spit out login and
> logout messages of anyone who had wheel.
> 
> Now if you combined Watch with Toggle, a program that let you
> blat a one line message to someone (it also TREPLACEd the
> EXEC) you had many of the same IM features you have today (no
> graphical smileys, bold or italic facing, or direct file
> transfers).

And there were versions of either finger or whois servers
(probably both) that had "continuous" options.  I would still
claim that today's presence models are a significant change,
especially when they are adapted in a distributed
independently-operated server environment and that real-time
messaging is not.  However, what this subthread demonstrates is
that they were conceptually an incremental change, not a giant,
discontinuous, intellectual leap.   

I thought we all knew that.

   john



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Harald Alvestrand]

Simon Leinen wrote:

Hallam-Baker, Phillip writes:
  

Incidentally, it does need to be [EMAIL PROTECTED] and not
[EMAIL PROTECTED] 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.
  
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 PROTECTED] is provisioned from someone 
who's got no relationship at all to my mail and web services.


Harald


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Henning Schulzrinne]

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




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Eliot Lear]

Brian Rosen wrote:

If you squint hard enough, everything has already been invented.  Telegraph
operators had a form of presence if you squint hard enough.

Presence is a continuously updated 'display' of a set of other people's
status.  Finger didn't do that.  Yeah, you COULD have used the mechanism to
implement a form of presence, but I don't remember anyone ever doing that,
and if they did, it didn't make anyone sit up and take notice like the IM
folk's buddy status systems did.


Mel Pleasant wrote a program for the DEC-20 called "watch", which was 
commonly used on many -20s at the time (this goes back to at least the 
early 80s).  You would provide a list of individuals you were interested 
in watching and the program would sit on top of your EXEC and 
occasionally burp out messages that So-And-So has just {logged 
{in|out}|attached|detached}.  At Rutgers we had a program that sat on 
the consoles beneath OPR that would spit out login and logout messages 
of anyone who had wheel.


Now if you combined Watch with Toggle, a program that let you blat a one 
line message to someone (it also TREPLACEd the EXEC) you had many of the 
same IM features you have today (no graphical smileys, bold or italic 
facing, or direct file transfers).


Eliot

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Simon Leinen]

Hallam-Baker, Phillip writes:
> Incidentally, it does need to be [EMAIL PROTECTED] and not
> [EMAIL PROTECTED] 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.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IM and Presence history

[Brian Rosen]

If you squint hard enough, everything has already been invented.  Telegraph
operators had a form of presence if you squint hard enough.

Presence is a continuously updated 'display' of a set of other people's
status.  Finger didn't do that.  Yeah, you COULD have used the mechanism to
implement a form of presence, but I don't remember anyone ever doing that,
and if they did, it didn't make anyone sit up and take notice like the IM
folk's buddy status systems did.  They invented presence, as we know it, and
of course it's not entirely new, but then again, little else is.

Finger had antecedents in various time sharing systems versions of "who is
logged in" mechanisms.  They in turn had predecessors in various user id
logging mechanisms on batch systems.  I recall being able to determine who
was in the CMU Comp Center by looking at a fairly often posted list of batch
runs made for the 1108, and the G20 graphics systems certainly had
mechanisms to know who was on the other displays way before I got there.

Sending real time messages to users logged in is almost as old.  The G20
graphics systems had such facilities.  Every time sharing system did, and of
course, the telegraph operators had a similar facility.  They aren't IM.

Brian

> -Original Message-
> From: Dave Crocker [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 28, 2006 11:01 AM
> To: John C Klensin
> Cc: ietf@ietf.org
> Subject: Re: IM and Presence history
> 
> 
> 
> John C Klensin wrote:
> > Yes.  I wanted to keep the note from becoming even longer, but...
> 
> ack.  figured that, but found myself compelled that the history lesson was
> useful for the record.
> 
> 
> >> If I came in through an arpanet dial-up at some random place
> >> on the net, and telneted to my home system, then the finger
> >> for that home system would show me as 'present'.  I am not
> >> seeing how today's presence systems are fudamentally different
> >> from that.
> >
> > Subjectively and from my perspective, the present systems
> > "feel", and sometimes actually are, much more distributed.  But,
> > yes, from the perspective you describe, we have advanced very
> > little in terms of basic functionality.
> 
> 
> I believe that none of the proprietary IMs is anything other than purely
> centralized.
> 
> Having to configure multiple IM accounts, to be able to talk to different
> people, doesn't feel at all 'distributed' to me, except in the bad sense
> of
> multiple, disconnected, centralized services.
> 
> d/
> 
> --
> 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Dave Crocker]

John C Klensin wrote:

Having to configure multiple IM accounts, ...>


No question about it.  I was thinking partially about Jabber,


Right.  Which was why I said "proprietary".  (Jabber, having been turned into 
XMPP, nicely dodges that qualifier...)




with interoperability between implementations and hosts,


From some recent experiences, it is looking as if it still needs to go through 
some implementation learning curve.  I suspect it's not a protocol issue, but 
I've seen some interoperability problems and would bet the issue was software 
maturity.



 and Skype with (at

least as I understand it) a fairly distributed architecture.  As to the rest,


oh.



I think there is another interesting story in the fact that multiprotocol
clients seem more effective and useful, and much more widely used and
deployed, for IM than their equivalents were for email.  Part of it is


Maybe.  I'm seeing enough oddities with the popular, multi-protocol IM client 
that I use to continue to believe that the combinatorials that are inherent with 
multiple, competing protocols make long-term viability a real question.


Back when I wrote email gatewaying software -- and it's design was with a 
canonical model that each service was mapped to/from --  I know that every time 
I added a new email service, I had to go into the core and make tweaks.  Or 
sometimes deeper changes.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[John C Klensin]

--On Tuesday, 28 November, 2006 08:01 -0800 Dave Crocker
<[EMAIL PROTECTED]> wrote:

>> Subjectively and from my perspective, the present systems
>> "feel", and sometimes actually are, much more distributed.
>> But, yes, from the perspective you describe, we have advanced
>> very little in terms of basic functionality.
> 
> I believe that none of the proprietary IMs is anything other
> than purely centralized.
> 
> Having to configure multiple IM accounts, to be able to talk
> to different people, doesn't feel at all 'distributed' to me,
> except in the bad sense of multiple, disconnected, centralized
> services.

No question about it.  I was thinking partially about Jabber,
with interoperability between implementations and hosts, and
Skype with (at least as I understand it) a fairly distributed
architecture.  As to the rest, I assume that, sooner or later,
we will the same thing we saw with email: as functions and
capabilities diverge, gateways (and multiprotocol clients)
deliver only least common denominator services and get less
capable, and, well,... Know anyone with a large installed base
of ccMail users these days?

I think there is another interesting story in the fact that
multiprotocol clients seem more effective and useful, and much
more widely used and deployed, for IM than their equivalents
were for email.  Part of it is certainly related to the fact
that the usual email model is not-very-smart-MUA->
smarter-Submission-server, while the IM one, at least in terms
of what the user sees, is client->client.

  john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IM and Presence history

[Hallam-Baker, Phillip]

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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Dave Crocker]

John C Klensin wrote:

Yes.  I wanted to keep the note from becoming even longer, but...


ack.  figured that, but found myself compelled that the history lesson was 
useful for the record.




If I came in through an arpanet dial-up at some random place
on the net, and telneted to my home system, then the finger
for that home system would show me as 'present'.  I am not
seeing how today's presence systems are fudamentally different
from that.


Subjectively and from my perspective, the present systems
"feel", and sometimes actually are, much more distributed.  But,
yes, from the perspective you describe, we have advanced very
little in terms of basic functionality.



I believe that none of the proprietary IMs is anything other than purely 
centralized.


Having to configure multiple IM accounts, to be able to talk to different 
people, doesn't feel at all 'distributed' to me, except in the bad sense of 
multiple, disconnected, centralized services.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[Harald Alvestrand]

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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IM and Presence history

[John C Klensin]

--On Monday, 27 November, 2006 11:07 -0800 Dave Crocker
<[EMAIL PROTECTED]> wrote:
 
> John C Klensin wrote:
>...
>> I would add an observation to Dave's about possibly different
>> sets of needs by reminding everyone that considerable IM
>> functionality (other than presence) isn't new.  We had
>> SEND/SOML/SAML from the beginning of SMTP, even though they
>> had,
> 
> Just to nit-pick, since Internet history has become an
> important topic:
> 
> By "beginning of SMTP" John actually means the mid-1970s, in
> the original Arpanet FTP-based mail service.
> 
> And since I think it was a particularly clever option, I'll
> note that one of the commands John cites was "deliver to the
> recipient's screen if they are logged in and deliver it to
> their mailbox if they aren't."

Yes.  I wanted to keep the note from becoming even longer, but
you are of course correct -- both on the substance and that
those things are important.

> Would be nice to have that in today's world, wouldn't it?

I think so.  And I'm getting interested in the difference
between IM-ish systems for which the model is "if they aren't
online, it is lost" and "they aren't online now, but your
message will be held and delivered when they are".

>> None of these supported a presence mechanism in the sense that
>> we understand it today.
> 
> There as a close approximation, as I recall, with the way the
> Finger mechanism was implemented at some sites.  You would
> Finger a particular username at a host and the returned
> information would tell you if they were logged in.

Indeed.  Or with, e.g., talk, one could try to set up a
connection and assume that failure meant "not present".  Both
are approximations, but so are today's presence mechanisms.

>>  As a result, one had to bind a user
>> identity to a target host in much the way SMTP does, rather
>> than having someone attach to the network at any point and
>> announce presence and, implicitly, location. 
> 
> Mumble.  I'd claim that the current presence mechanisms do the
> same thing that was done originally.
> 
> If I came in through an arpanet dial-up at some random place
> on the net, and telneted to my home system, then the finger
> for that home system would show me as 'present'.  I am not
> seeing how today's presence systems are fudamentally different
> from that.

Subjectively and from my perspective, the present systems
"feel", and sometimes actually are, much more distributed.  But,
yes, from the perspective you describe, we have advanced very
little in terms of basic functionality.

>>   It is arguably those
>> presence and mobility mechanisms and not IM itself that is the
>> recent development.  To the degree to which those mechanisms
>> are what caused IM to take off, perhaps that reinforces
>> Dave's view of different services serving different needs.
> 
> I think it was Graham Klyne who pointed out to me that IM and
> Internet Mail also do tradeoffs in reliability vs. timeliness.
> 
> An IM is not expected to survive a system crash, whereas an
> email is.  That leads to very different software development
> decisions, such as whether to incur the cost of a
> write-to-disk for every message.  In the aggregate, the cost
> difference can be huge.

Indeed.
john




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf