Re: [JDEV] ICQ and AIM

[qbradley@csc.UVic.CA]

I think this is much more complicated than is currently intended.  I
currently use ICQ but I want to move to Jabber.  it is VITAL to me that
people receiving messages from me see them come from ME and not some
jabber transport.

So, I start Jabber, where I am coatl@my.server.org.  In my login packet, I
configure my Jabber client to also send my ICQ number and password.  My
server has been configured with an ICQ transport.  This transport logs
into ICQ using my number and password.  If I send a message to an ICQ
address the above transport simply forwards it on my behalf,
transparently, so from ICQ's point of view, it came from my ICQ number,
but there was no code in my client for this.  My client just sent a jabber
message.  The transport forwarded for me.  Later my ICQ buddies send me a
message to my ICQ nick.  Because the servers transport is logged in as me,
it gets my message.  It then bundles up the message to look like a Jabber
message, and sends it back to my client.  My client sees a jabber message.

So in short, to talk to ICQ users, you yourself need an ICQ number.
However, you do NOT need to have an ICQ client, and the Jabber client
doesn't need to know ANYTHING about ICQ, at all.

Quetzalcoatl Bradley
qbradley@csc.uvic.ca

On Thu, 14 Jan 1999, jswink@softcom.net wrote:

> Jeff McBride wrote:
> > 
> > Ok, something has kind of occurred to me that I just took for granted at
> > first...
> > 
> > I don't understand at all how you plan on being able to communicate back
> > and forth with ICQ and AIM people. Unless, you are saying that in order to
> > do that, jabber users must also have ICQ and AIM IDs....
> 
> Essentially they do.  But the transport should do it without their
> intervention.
> 
> Here's my take on an ICQ transport.
> 
> Suppose a jabber user adds 3 or 4 ICQ users to their roster.  The
> jabber transport has to have a unique ICQ UIN to handle that.  The
> ICQ server, sufficiently convinced that the jabber ICQ transport
> is a client, will send online status info, messages etc. to the
> transport, who, associating this UIN with a jabber user on that
> server, will forward them to the jabber server etc.
> 
> 
>  Jabber    Jabber    Jabber   ICQ                    ICQ
>  users   transport   server   transport             server
> 
>  +-----+  +------+  +-----+  +-----------------+  +--------+
>  | Joe |--|      |  |     |  | ICQ     Joe=789 |--|        |--123
>  +-----+  |      |  |     |  |                 |  |        |
>           |      |--|     |--|                 |  |        |--234
>  +-----+  |      |  |     |  |                 |  |        |
>  | Bob |--|      |  |     |  |         Bob=790 |--|        |--345
>  +-----+  |      |  |     |  |                 |  |        |
>           |      |  |     |  |                 |  |        |--456
>  +-----+  |      |  |     |  |                 |  |        |
>  | Jim |--|      |  |     |  |                 |  |        |--567
>  +-----+  +------+  +-----+  +-----------------+  +--------+
>           
> 
> Joe and Bob have a few ICQ users in their Jabber rosters.
> The ICQ transport has to have an ICQ UIN for each of them to
> properly route info to and from the ICQ server.
> 
> This allows for two-way communication, essentially transparent
> to users.  Granted the ICQ transport is a wee bit complex,
> being required to establish a new ICQ account when Jim
> decides to add ICQ user 456 to his roster.  It has to have
> its own data files, though if it's done well, it need not
> seem different from any other transport, as far as the
> Jabber server is concerned.
> 
> Joshua Swink
> jswink@softcom.net
> 

Quetzalcoatl Bradley
qbradley@csc.uvic.ca