[JDEV] Extra namespaces for legacy protocols?

[Andrew Sayers]

A couple of nit-picks before I begin the full rant...

> Perhaps we need to:
> a) Clearly define what features each of the existing protocols support. 

Proper documentation simply doesn't exist for some protocols.  I've
spent months trying to decode the MSN protocol, and I still could be
fundamentally mistaken about how it works (it wouldn't be the first
time).  It doesn't help that MS have few qualms about releasing new,
incompatible, versions of their protocol at the drop of a hat.

>             ... These JEPs can then be retired as the legacy IM systems 
> die off :)

Since no-one seems to have listened before, I'll be a bit more direct:
this is never going to happen.  Put all thoughts of a Jabber-only world
out of your mind.

With that said, the important bit...

> A lot of the discussion recently has indicated that the legacy protocols 
> are not feature-compatible with jabber.

To be precise, it's not just that they're feature-incompatible (like,
say, Word and Excel), but that they look at the same problems in
fundamentally different ways (like, say, techies and lay-people).

In places where Jabber lacks some feature that exists in another
protocol (e.g. negotiating arbitrary OOB sessions), the solution is to
add that feature to Jabber, then add it to the transport.

In places where Jabber has a different perspective on the same problem,
the solution is not to balkanise Jabber by creating protocol-specific
extensions, but to translate the behaviour of the protocol into
something J. Random Jabberite would expect to see.



To give a concrete example, MSN Messenger lets you send messages to
people through Hotmail or to their mobile when they're offline.  If you
double-click on the icon of an offline user, IE will be opened to a
Hotmail "composing" page.  If you select "Actions|Send Message to a
Mobile Device...", you can select a user, then send a message to their
mobile device (assuming they have one registered).  Jabber has no
comparable features, so how do you implement them?

You could implement an "msn:sms" and/or "msn:hotmail" namespace.  On the
plus side, this leads to a very direct mapping between Jabber and MSN
features, so people coming over from MSN will have less feature-shock.
On the minus side, that would require all client authors to upgrade their
clients.  Since most authors have already stated the have no interest in
other (what they consider "legacy") protocols, they probably aren't
going to do this.  Also, what happens if AOL bring out an identical
feature in 6 months time?

You could work with the people looking into e-mail and/or SMS
transports.  On the light side, that would make your MSN contacts'
e-mail and SMS options work the same as your jabber contacts' e-mail and
SMS options.  On the dark side, the amount of co-operation you'd need
between all the transports would risk merging them all into some huge,
unmanageable, MSN/SMS/mail transport.

You could could have normal messages to offline users go straight to
their hotmail inbox, and chat messages go to their SMS number (or
hotmail if they don't have one).  On the one hand, that doesn't require
special support from clients or other transports, and maps fairly well
to the expectations of most Jabber users.  On the other hand, you don't
necessarily want "See you later" sent by e-mail to someone who logged
off faster than you expected, and if you only used SMS once every few
months, you'd be hard pressed to remember how it works.

My personal favourite (at the moment) is to define several resources -
"user%hotmail.com at msn.jabber.org/messenger",
"user%hotmail.com at msn.jabber.org/hotmail", and
"user%hotmail.com at msn.jabber.org/sms".  This is easy to use, easy to
remember, and easy to implement, but it doesn't map as directly to the
expectations of a Jabber user than the above.


Translating between Jabber and other protocols isn't a science but an
art, and it necessarily requires lateral thinking.  IMO, JEPs aren't the
right solution to *pure* issues of translation.  However, other
protocols can inform us about features lacking in Jabber.

	- 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/20030615/673c623a/attachment-0002.pgp>