[JDEV] msn-t maintainence

[Andrew Sayers]

Hi,

I'm Andrew Sayers - I've been using Jabber for a year or so, and I'm
starting to get into Jabber programming - mostly because I need to know
about the basic technologies behind it (Unicode, XML, network
programming, etc.) and I need a project to learn on :)

I'm thinking about writing a new msn-t in C.  I've been talking around
this issue in the jdev conference room for the last few days, and I
thought it was time to bring this to the list.

I'm not interested in maintaining the old msn-t - I disagree with many
of its design decisions, a quick look through it suggests that it's
poorly documented and not that well written (e.g. it doesn't use
pass-by-reference at all).

As you might have guessed, I'm not that hot on Jabber internals right
now - I've skip-read the protocol document, and I'm now starting from
first principles, so I'm up to chapter 3 of the unicode standard :).  I
need help mostly with two things: where to find libraries etc. and how
best to design the transport.

After talking with many people in the conference room (especially Paul
Curtis, who has been very helpful), I've scribbled out a rough plan for
a new msn-t.  I'd appreciate any comments or ideas - notably, how big a
fool I am for suggesting this :)

The rough plan is below, but the questions I still don't have answers
for are:

* How does a transport support invisible Jabber clients?  How
  does a transport tell that the user is still on-line?  This isn't
  supported in the current msn-t.

* Is it useful/possible to try and synchronise Jabber filters with MSN
  allow/block lists, e.g. to conserve bandwidth?

* How should e-mail notification be supported?  Any method would have to
  be controllable on a per-user basis.  This isn't an MSN-specific
  problem, so the solution shouldn't be MSN-specific.  Is JEP-0024
  (pub/sub) a good solution?

Anyway, with all that said, here is the plan:

*** MISCELLANEOUS ***

Most of the protocol (everything except chat) is fairly easy to support.
The easy things are:

* Profile information is kept synchronised with Jabber personal
  information.  Any information which can't be handled by MSN is ignored.

* MSN users' information is sent as vCards.

* JEP-0022 (Message Events) is supported - this means, for example, that "user
  is composing" is supported.

* Presence information:

  MSN status	Jabber Status
  NLN		Online
  BSY		dnd
  PHN		dnd (Message: On the Phone)
  BRB		away (Message: Be Right Back)
  IDL		away (Message: due to idleness)
  AWY		xa
  LUN		xa (Message: Out to lunch)
  HDN		offline
  FLN		offline

* Types of MSN list

  Forward and reverse lists are (obviously) mapped to subscription
  types.

  Jabber has its own mechanisms for allowing or denying messages from
  specific users.  MSN's allow/block lists are therefore redundant.

* MSN groups are redundant, so ignored.

* File transfer can be supported, using the normal HTTP PUT/GET method, if
  enabled in the configuration file.

* Messages to offline users will be stored until the Jabber user logs out, or
  some time-limit (24 hours?  Can be configured to 0) is reached.  At that
  point, chat messages will be returned as unsendable, and normal messages will
  be sent to the users' hotmail account using smtp-t.

*** CHAT ***

Chat between Jabber and MSN is non-trivial, because the two systems have wildly
different feature-sets.

_Definition of terms_

I'm not sure what the proper terms for these concepts are, but here are the
terms I'll use in this document:

one-to-one messaging	conversation between exactly two clients
one-to-many messaging	conversation between more than two clients
Groupchat (GC)		an implementation of one-to-many messaging used by Jabber.
MSN Messaging (MSNM)	an implementation of one-to-many messaging used by MSN.
Chat			an implementation of one-to-one messaging used by Jabber.

Note1: MSN has no specific "one-to-one" messaging implementation -
it's just a special case of one-to-many chat.

Note2: I'll use Capital Case for "Chat" and Groupchat to show as not to confuse
it with the lip-flapping activity of the same name.

_Chat modes_

MSNM doesn't have a direct translation into Jabber.  Its feature set is a
super-set of Chat (e.g. it supports many people), but a sub-set of GC (e.g. it
does not support room names or subjects).  Therefore any solution that doesn't
involve change to one or other protocol can only ever be kludgey at best.

Since one-to-many chat is possible in both Jabber and MSN, it seems
perverse not to allow one-to-many intercommunication, although the
details of how this work are quite knotty.

Some Jabber users make a strong mental distinction between a
one-to-one chat and a one-to-many chat*.  Some applications of Jabber are
inherently one-to-one.  Therefore, some Jabber clients will be happy to chat
with an MSN client in a one-to-one context, but not in a one-to-many context.

Given the above paragraph, we should layer some kind of one-to-one
system over MSN messaging.  It should be possible to move from
one-to-one context into one-to-many context, but it should also be
possible to end a session rather than move into one-to-many context.
We will see later that many technical problems arise when moving from
a one-to-one context into a one-to-many context.

_Implementation_

Four chat methods are described.  If it is supported, the client can use
JEP-0020 to choose which is used.  Otherwise, the transport uses its best
guess.  Discussion below assumes that the client does not support JEP-0020.

Also assumed is that a client will always keep the id tag intact for a
message.  If a message is sent with no id tag, it is transmitted to the
receiver in the first available MSNM session which has no other users in (or a
new session if none exists).

1) Modified Chat <-> MSN

  This method is not currently a part of the Jabber protocol.  It is a
  specially modified version of Chat to match MSNM's feature set.  As explained
  above, it is necessary to create a new Chat method in order to perfectly
  support MSN <-> Jabber interaction.

  People who feel that breaking Jabber to fix MSN is a bad idea should feel
  free to ignore this method :)

  In addition to normal use of the <message/> tag, conforming clients must:
  
  a) treat any message with the same id as being part of a single conversation,
     no matter who the sender is.
  b) Provide a facility to invite MSN users only (i.e. for a transport
     msn.server, only users @msn.server may be invited)

2) Groupchat <-> MSN

  This method is similar to the Groupchat hack used at the moment.  It is used
  if the server has configured a groupchat.msn.server.
  Obviously, the client must accept invitations for GC to be used.

  A session is massaged so that Jabber users see a GC and MSN users see an MSNM
  session.  The chat will in fact be a normal MSNM session managed on MSN's
  switchboard server.  No GC server will be used.

3) Pretend Groupchat <-> MSN

  This method is used when three or more people are in an MSNM session if there
  is no groupchat.msn.server available.  This solution is very ugly, but I
  believe it's the least bad solution to the problem.

  The transport simulates a Groupchat with normal <message/>s.  The transport
  simulates a Groupchat by sending messages like "[MSN_user1] blah blah blah"
  and "* MSN_user2 has joined".  Invitations are handled by sending a message
  "/invite user at hotmail.com"

  This is better than opening several Chat sessions because (in a session with
  many people) the number of windows created by a client can become
  unmanageable.

4) Chat <-> MSN

  This method is used when conversing with exactly one other person.  If
  Groupchat is available, this method is used until an invitation is accepted
  (if the invitation isn't accepted, this is used until a third user joins).
  This method is similar to the default behaviour of the current msn-t.

  MSNMs are massaged into a session of normal <message/>s so long as only two
  people are in the MSNM.  When a third person joins the MSNM session, a GC
  invitation is sent if possible, otherwise a Pretend GC session is started.
 
  If GC is possible, two actions are taken:
  
  * Further messages are queued until it is clear whether the user will be
    upgrading to a GC.
  * A software version request is sent.

  If the client accepts the invitation, the Chat is upgraded to a Groupchat,
  and queued messages are sent to that Groupchat.

  If the client continues sending messages after the software version reply is
  received, it is assumed that they have declined the invitation.  In this
  case, queued messages from the initial sender are sent in the current
  session, and messages from other participants will trigger the creation of a
  new Chat session.

_Events_

The three significant events that can happen are:

A - User connects to MSN transport

The transport sets a preferred communication method.  If available, this is
(2).  Otherwise, (4) is used.  The transport also stores whether the client
supports method (1) (by default, no)

The transport uses JEP-0020 to request a preferred communication method, and
whether (1) is supported.  The client may respond at any time.

B - Client is invited to an MSNM.

The transport hands the invitation over to the communication method, which acts as explained above.

C - Client begins an MSNM.

If the client sends a normal <message>, the session is handed to (1) (if
possible) or (4) (otherwise).  If the client sends a Groupchat, the session is
handed to (2).

* I am not such a person, but I consider it a valid point-of-view.
  Essentially, a one-to-one chat is a private forum, whereas a
  one-to-many chat is a public forum.  Just as you wouldn't want to be
  thrust into a public place without being asked, you wouldn't want to
  be thrust into a public forum without being asked.


	- Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 362 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20021226/16002e3e/attachment-0002.pgp>