[JDEV] Re: Info (or long rant about client/server division)
dmag at umich.edu
Tue Jan 12 22:22:05 CST 1999
Donovan Schulteis wrote:
> I don't agree that the Jabber client should have email and SMTP integrated
I second that.
> Send and receive messages for particular systems (i.e., AIM, ICQ, etc).
> If the intended recipient is not available (not connected to his/her Jabber
> server), then the Jabber client should ask if the sender wishes to send the
> message as email, or place on que (a la, ICQ). This preserves an ack/deny
> simplicity in the client.
I'll expand on this: Only the remote (destination) server knows about the
different ways to contact the user. The server can say "He's not in right
now, but you can reach him via e-mail or text pager". The client would get
this info and will address the message to the e-mail transport of the
There would be no client code for e-mail (or AIM or ICQ for that matter),
as these are figments of the remote server's imagination. New transports
can be added to (or removed from) the remote server at run time, without
changing any clients. In fact, the client should not know about e-mail at
compile time, only at run-time. As far as the client is concerned, it
doesn't know the difference between e-mail and AIM. It just knows that they
are different methods/transports reported on the remote server.
> The receiving Jabber server then sends the message text as email via
> it's own SMTP engine to the registered email address of the
> recipient [..] thus removing SMTP from the client.
Exactly: the receiving server has a transport module called 'email'. If a
server doesn't want the 'security risk' of generating e-mail, then they
don't install it. The remote server decides where to send the e-mail too.
In fact, this way the client isn't privy to the actual e-mail address.
> It also assumes that users would have a permanent email account
<sidenote> The E-mail transport would have the following configurations:
- Mail sent to local users only, with same name as their jabber/unix name.
Mail disabled by default. Users enable it, and add optional filters (size,
keywords, times, etc.) Users can't control WHERE the mail goes, because it
always gets delivered locally to that user. ISPs would like this.
- Mail sent to configurable e-mail address. For example, alice at alice.org
could have her e-mail sent to her 'real' e-mail of alice at hotmail.com.
People who run a jabber server for their friends would like this.
Of course, if the mail transport isn't installed, no mail can be sent.
Receiving e-mail would also be a "remote server" issue. Your jabber server
may or may not have e-mail, but you can communicate 2-way if my jabber
server can send/rcv mail. Receiving mail can be configured a number of
ways. Again, that's a transport configuration issue.. (could be SMTP
listener on deticated computer, could be sendmail filter for virtual
domain, etc etc...)
> that the different protocols for messaging could be verified that it is
> possible to que messages. Also, that each user would be registered on one
Message que and auto-email will be server side configs. In fact, each user
will probably want something different. For instance:
alice.org runs jabber with 4 server transports:
1) e-mail (send/rcv)
2) answering machine
4) text pager
- alice at alice.org enables e-mail, her pager and ICQ. If she's not logged
in, there is no default (messages are bounced). She can be e-mailed or
paged only by explicitly routing to that transport. To prevent abuse, only
her buddies can page her. (Others don't see the pager transport.) The ICQ
transport is only active if she's reachable on ICQ.
- jane at alice.org enables e-mail, and makes it the default when she's not
logged in. When she is logged in, jabber becomes the default.
- roger at alice.org enables e-mail, and also enables caching of messages via
a transport called "answering machine". When he's not logged in, clients
see "answering machine" and e-mail, with "answering machine" being default.
The answering machine transport stores all messages, and replies (with a
low-priority reply) with "Your message has been safely stored.". When he is
logged in, "answering machine" is disabled, and jabber becomes the default.
> There must be a sort of a tag in the
> header of the message stating send as email.
Instead of smtp%user at host.com (which I find hard to parse and remember), I
propose using the nicknames, maybe with some special indication that it's a
transport nickname. For example, the user display on a client might look
Alice at alice.org
Which would mean that alice is on in 2 locations (Home and Away), and that
3 alternate transports are available. One could send a message directly to
her pager without sending a message to Home or Away. A different user might
get a different display because Alice said "Only my buddies can use my
Here's some senarios, with bob at bob.gov (his server doesn't have ANY
transports enabled. He can only send pure jabber messages). Bob is dialed
in thru UUNET, but his client must send messages thru bob.gov.
- Bob starts a message to alice at alice.org
- Bob's client checks with alice.org to find what nicknames/transports are
- Bob's client defaults to sending to alice's "Home" nickname (because
alice made it high priority), but allows him to choose a different
- Bob chooses 'pager' and sends the message.
- The messages goes out as:
<to nick='pager'>alice at alice.org</to>
I'm not sure if it's a Good Idea to overload the nick parameter. However
it's done, the client needs to distinguish between 'normal' nicknames and
'transport' nicknames. The server gets to decide what the default
transport/nick will be, and the client gets to override it (based on
available transports only).
<sidenote> the config screen for a roger at alice.org would look like this:
Transport Priority Enabled when logged in or out
--------- -------- -------
e-mail 10 IN and OUT
answering machine 20 OUT only
ICQ 0 neither
text pager 0 neither
Home client 50 IN only (duh)
Enough ranting. More coding!! ;) Seriously, whatcha think?
More information about the JDev