[JDEV] Jabber server in Java

Ragavan S jabber_dev at hotmail.com
Tue Jul 3 15:52:43 CDT 2001

>--- Bill Abbas <zsa at expertq.com> wrote:
> >
> > On Sunday 01 July 2001 11:04, you wrote:
> > >
> > > For example, there seems to be
> > > a built-in assumption that client's must trust their
> > > server (a situation that seems obviously ripe for
> > > exploitation)
> >
> > I do think it's an important feature for a server to be
> > able to read the messages that pass thru it.  E.g. if the
> > clients are used to provide in-field support or sales
> > assistance for a business, you need to be able to log what
> > your support rep told your customer.
>I like the debate.  :)  I should put in the caveat that this is a
>discussion of the "most secure" mode of the server.  Clients may relay
>these requirements as needed (not all messages must be encrypted or
>signed, you can send plain text messages as you like (however the server
>on the recipient may refuse messages that aren't signed or encrypted)).

This sounds like something that a centralized (maybe residing on the server) 
policy engine could do. The policy engine could always enforce checks to 
make sure messages follow the requirements. I am also not too favorably 
inclined towards a scenario that allows a server to peek into messages 
exchanged between clients. Logging of messages is maybe better left to the 
client and the log may even be better off being stored on the client.

>Second caveat being that my primary interest is JAM and not IM
>specifically (IM only as an application of JAM).

Cool. JAM is where my interest lies as well. :-)

>I think the server should only have access to these pieces of information:
>Sender (indicated by JID & signature)
>Recipient (indicated by JID & signature)
>Quality of Service Descriptors
>If you want to log information at the "server" it can only be these three
>items (and the size of the message).  If you want to log application
>specific items, then the "recipient" should be a "chatbot" operating on
>behalf of the application that has permissions to access the message.

I can see this also being enforced by the policy engine. The client cannot 
dictate what information it will reveal and what it won't. For eg. the 
client cannot hide the JID of the user. The server on the other hand cannot 
ask the client to reveal too much (like the body of the actual message). If 
the client needs some specific QoS, it is indicated in the Qos descriptor. 
The server is the one that negotiates this with the other server(on the 
recipient's side) and comes back with a Yes/No/Maybe (in case lesser quality 
is supported).

>My premise, which I've only discussed with some people here, is that I see
>the server as having a much smaller responsibility than in the current
>Jabber protocols.  It is essentially a security, QoS, store and forward,
>and routing service.  All other activities are handled by "chatbots" that
>can be implemented as internal functionality, modules, or external
>My intent is to shrink the server's responsibility and create a solid
>foundation.  All the other aspects of creating a working IM system are at
>the "application protocol" level.  This includes things like presence,
>chatrooms/conferencing, etc etc.
>Essentially, my goal is to create a JAM framework with the server only
>providing the base foundation you can build on top of.  Standard JAM
>services can begin with those that support IM such as presence/roster
>management, pub/sub, user directory browsing, etc.

Sounds good to me!.

Hey, by the way, has anyone come up with any names/ideas for names for the 
Java Jabber server?

At the risk of being flamed, I am going to propose a few names.

JaBa --  The JAva Jabber server ( you can even say it so it sounds like 
Jabber :-)

Javver -- I know it may seem pretty lame -- but hey, I am gonna put it out 
there anyway!

Jedi -- No particular reason for this. Just sounds cool I guess :-)

Jamba -- JAM and Jabber combo

Hey.. somebody had to do this :-P


Get your FREE download of MSN Explorer at http://explorer.msn.com

More information about the JDev mailing list