Jabber Could Get An IETF Working Group

21mhz writes: "There is a story on CNET news that provides an analysis of what is happening with SIP/SIMPLE, AOL protocols and Jabber/XMPP in the IETF. It says that Jabber is close to securing a dedicated IETF working group, in spite of political struggle and corporate maneuvering."

Comments

Links

[Taylor_Durden]

Jabber Central (more pratical information on jabber)
Jabber Powered (an initiative to create products based on Jabber)
Jabber Studio (the development hub of the Jabber community)
Old Jabber documentation
Jabber FAQ
A nice overview of Jabber
Jogger (a jabber based weblog)
Jabber Python module
Unofficial Jabber user guide
Programming Perl(an O'Reilly book)

Re:Links

[CBAS]

RhymBox - an open source client in DHTML

Fantastic

[ghazban]

For those of you who want to try out jabber, psi is a great crossplatform client, with support for windows, linux and mac OSX. I've been using it for some time, and with the msn, icq/aim, etc transports, there isn't really any reason to use anything else.

I really do hope the jabber folks are able to make jabber a standard.

Re:Fantastic

[FattMattP]

A little off-topic, but did anyone else notice this item on the PSI page?

We recently learned that a commercial entity has taken Psi's source code and made a closed source product from it. They have chosen not to release the source to their derivative work, thus violating the terms of the Psi licence, the GPL.

We are currently in talks with both the FSF and this commercial entity, and we'll be sure to let you all know if and when it's resolved. To protect the aforementioned company from hordes of angry Psi users and GPL advocates, we choose not to disclose their name. Don't even ask us, we won't tell... unless, of course, they decide to continue using the Psi code without releasing the source to their product, then you can have them.

Re:Fantastic

[tzanger]

he only issues I've have with PSI are general problems locating stable transport servers.

How is Psi the cause of your transport problems? That would be a jabber server issue. I compiled my own server and don't have these troubles, although I'd love to get the IRC and Yahoo transports working.

I do agree with you though, Psi is the best damned jabber client out there. I think I went through every single Linux and Java server until I settled on Psi. The others were either too MSN-ish (who the hell can work when a new message not only pops up but takes focus?!) or too new-ICQish. Psi brings the best of the old Mirabilis ICQ client to Jabber. With luck it will become standard with KDE3.1 and be fully DCOP-accessible.

Re:Fantastic

[tzanger]

A little off-topic, but did anyone else notice this item on the PSI page?

Yup, and slashdot rejected the story last week:

• 2002-08-25 19:44:26 [name withheld] ripping off GPL code (articles,news) (rejected)

Name removed at Justin's (Psi developer) request -- he doesn't want hordes of angry people attacking the ass who did this...yet.

Re:Well..

[Teknogeek]

Jabber is, simply put, a universal IM client.

If you use AIM, ICQ, Y!M, or MSN Messenger (or any combination thereof), you can connect to them with Jabber.

It's great if you have, say, family members on AIM, friends on ICQ, and co-workers on MSN.

It also has its own, internal protocol.

However, AIM and Jabber have a history of not working together all that well...so if you have to have AIM connectivity in your IM client, I'd go with Trillian if you use Windows, IMCI for Linux or FreeBSD, or Fire if you use OS X (which doesn't support MSN...but if you're on a Mac, you probably don't need it anyway).

Explanation

[ghazban]

Jabber is an open protocol for instant messaging, based on XML. It allows for communication similar to current aim, icq and msn messenger protocols/programs. However, it is able to surpass them based on the openness of the protocol (lots of non-braindead clients for many platforms), features such as ssl encryption on messages (if client and server support it) and through use of transports which allow users of a jabber network to openly interface with clients on other networks (msn messenger, icq, aim, etc).

The ability to log on with only one username/pass and have all contacts on all of your networks be contacted through a consistant interface alone is worth trying jabber out. I recommend psi as a good starting client, however you can find many other clients on jabbercentral .

Jabber strength are the different implementations

[pippo_67]

Jabber is not only the product of one company but the collective effort of many Open Source developers and companies: Jabber servers are available for linux and , and windows.

Clients are available for any platform.

You can choose your preferred server or client and they will work with each other!!

Re:Well..

[martyn s]

I think you're missing the point though. Yes, Jabber is compatible with AIM, ICQ, Y!M and MSN messenger, but the real purpose of jabber is to establish a standard protocol. Jabber hopes to be to instant messaging what POP3 is to email.

Great.......?

[jukal]

My experiences with IETF and it's working groups are not just positive. The organisation seems to be very slow moving, full of politics - and also, full of clever minds. It is ofcourse good to get official recognition and other good things that can come out of it, but one of the obvious minuses I see is: it s ..l ...o ...w .e..s. d...o...w...n . . .t..h..e d..e...v...e..l..o..p...m..e...n.....?

Re:Great.......?

[horza]

[The disadvantage of the IETF is] it s ..l ...o ...w .e..s. d...o...w...n . . .t..h..e d..e...v...e..l..o..p...m..e...n.....?

So does documenting your code... is that a bad thing too? Seriously though, IETF protocols once finalised tend to be very well thought out and have shown they can stand the test of time (look at SMTP, FTP, etc).

You can code as much as you like, the worst that can happen is that you will have to modify your code afterwards to fit in with the final standard (the library you use to talk the Jabber protocol will only make up a small percentage of your application code). My advice is code away, and once the final RFC is out it will give you a baseline of garaunteed interoperability with every other fellow client out there.

Phillip.

Re:Great.......?

[jukal]

>Seriously though, IETF protocols once finalised tend to be very well thought out

Yes, I agree. And to be honest, I have not followed Jabber enough to base an opinion on whether it's in good phase to "IETFed".

SMTP and FTP examples of good work, but I think that when these were under consideration, IETFed still worked much more smoothly than it does today. There has been lots of discussion on stagnation, as for examle this and number of others state. But if Jabber is in good phase, a little slow down might not be that bad. And anyway, the would is better of WITH IETF than without it :)

Re:Great.......?

[ClarkEvans]

one of the obvious minuses I see is: it s ..l ...o ...w .e..s. d...o...w...n . . .t..h..e d..e...v...e..l..o..p...m..e...n.....?

IETF is a standards body, a place where concensus is established, and as such it probably isn't a good place to do development. However, it is a great place to have your stuff reviewed, poked at, and perhaps eventually published as an RFC. It has to be slow and deliberate, it is the nature of the beast. If it wasn't so slow then it would probably turn into the big ball of corporate mud that is the W3C.

Re:Great.......?

[Zeinfeld]

The organisation seems to be very slow moving, full of politics - and also, full of clever minds. It is ofcourse good to get official recognition and other good things that can come out of it, but one of the obvious minuses I see is: it s ..l ...o ...w .e..s. d...o...w...n . . .t..h..e d..e...v...e..l..o..p...m..e...n.....?

The big problem with IETF process is that it is very easy to block a specification indefinitely and plenty of folk try to do so.

The problem is not so much the companies as individuals with their own private agenda. I think it very unlikely that a Jabber group would be derailed by AOL seeking to defend its IM turf. But one or two people with an agenda to push some other spec like BEEP could easily bring the group down.

The IETF also has a large number of procedural problems, like insisting that all the group development take place on the mailing list rather than through a mailing list and regular teleconferences as is standard in OASIS or W3C. Another problem is that the RFC format freezes the format of specs in the era of the teletype. Not only is the output ugly, it is damn hard to read.

Another problem with the IETF is that it really does not play well with other children. Most standards bodies have by now got used to interacting with other bodies, not the IETF which has a massive NIH complex. The PKIX group which has been profiling the X.509 standard developed by the ITU is a case in point rather than an exception, the ITU standard had to be profiled before it could be used in IETF standards.

A graphic example of this is BEEP. The Web Services vendors stated at the outset that all their infrastructure was being designed arround XML schema, they would not support BEEP if it was specified as a DTD. So the IETF rushes BEEP to draft standard in less than a year with a DTD based spec and now wonders why none of the major platform vendors intend to use it. The only 'justification' for this decision ever given has been Marshall Rose saying 'well there are some problems with XML Schema', but no details to substantiate the assertion which basically comes down to the whole 'trust us, we know what we are doing and if you disagree with us then you obviously do not'.

The inner circles of the IETF are largely closed to anyone who has not been arround the IETF for 15 years or more. The big problem is that the fine words about being open etc etc are simply not backed by any accounability process with the inevitable result that 'meritocracy' quickly degenereates to cronyism.

The part where things fall apart is at the IESG level. In theory the IESG is charged with maintaining some sort of consistency across IETF work. The problem is that maintaining consistency can easily be a cover for trying to propagate some piece of lossage that should probably be taken off to the woodshed and shot instead. So a lot of groups have been pressured into considering BEEP even though it is inappropriate to their application.

Finally the IETF has a whole rack of shiboleths that have passed their prime. For a long time the IETF was absolutely against NAT 'if you're NAT on the NET you're NOT on the net', to the extent that the IPSEC protocol was designed to be incompatible with NAT (I was there at the meeting). This might have been a defensible position if the IETF had not been responsible for the 32 bit address space allocation scheme that would already have been exhausted in several countries without NAT.

I was giving the keynote at a security track of a Web Services conference recently. A member of the IESG spoke on the IETF approach to standards and inevitably a question about firewalls came up. Not suprisingly the IETF mantra of 'end to end security' was repeated. The problem being that when Alice and Bob are both working for different enterprises the 'ends' of the communication are not identical to the 'ends' of the security context (the enterprise network) or the ends of the trust relationship (the enterprises as a logical construct).

From a design point of view no specification should rely upon security services provided by a firewall. However that is not the same as saying that firewalls provide no protection or add no value. Fifteen years ago, before the ubiquitous availability of crack answered the question a very large number of UNIX sysops argued against the use of shadow passwords as being an exemplar of 'security through obscurity'. The IESG argument on firewalls falls into the same category - although hopefully with Steve Bellovin now on the IESG as a security area director he will be able to do some clue insertion.

The IETF does some usefull work, but they really need to radically reasses what their future role is going to be and how they are going to fill it. They need to shed a lot of the dogma and look into ways that they can improve upon the way things have been done for twenty years rather than continuously praising themselves.

Re:Great.......?

[Zeinfeld]

SMTP and FTP examples of good work, but I think that when these were under consideration, IETFed still worked much more smoothly than it does today.

I doubt that either FTP or SMTP would be passed in their current form today.

SMTP was introduced as a quick and dirty 'Gordian knot' solution to email transport. The good part is that it was introduced as a far simpler solution than the competing UUCP, MTP etc specs...

The bad part is that SMTP has plenty of features that are poorly thought out and still more that are not well specified. For example most of the problems with mailing lists could have been avoided if the design of SMTP had considered mailing lists more thoroughly.

Now as it happens none of the alternatives to SMTP address the real problems of email any better than SMTP. However the real failing of the IETF process is that once something like SMTP becomes a standard changing the spec is far harder than the initial design. Only a small part of that difficulty is the problem of compatibility with the legacy base.

In the early days of IETF specifications were published as 'Request For Comments' - the original concept was that they were nothing more than a lengthy email. Today there is layer upon layer of protocol.

weak spot is the server

[jilles]

Unlike propietary networks like icq or msn, jabber is a distributed network of multiple jabber servers pretty much like email. Users have a profile hosted by a server and are identified as user@jabberhost in a similar way to email. This is both its strength (anyone can set up a server) and its weakness (you need someone to host a server). Endusers without the ability to run servers themselves and without a provider offering a jabber server have to rely on one of the public jabber servers. Unlike with the big messaging networks, however, there are no central servers where you can permanently host your jabber profile. There are plenty of public testing servers but these may go offline at any time.

Because of this, many people download a jabber client, figure out that they need a server and are told by the jabber faq that they might try this or that server without any guarantees that it will still work next week. Not very convincing.

For people to adopt jabber as an alternative to current propietary messaging clients, a reliable, available server that will host profiles for free is needed. As long as servers are lacking, jabber will remain an interesting technology that is mostly used in corporate intranets.

If a good public server was available, I would have been running jabber years ago.

Re:weak spot is the server

[stpeter]

The jabber.org and jabber.com servers have been up for years (not talking about uptime!) with no likelihood that they will ever go away. And those are simply the two most prominent public servers.

Re:weak spot is the server

[lpontiac]

Because of this, many people download a jabber client, figure out that they need a server and are told by the jabber faq that they might try this or that server without any guarantees that it will still work next week. Not very convincing. For people to adopt jabber as an alternative to current propietary messaging clients, a reliable, available server that will host profiles for free is needed.

This is exactly the same situation that exists with email. You need to find someone to run a mailserver for you - and for 99.9% of users it ends up being their ISP, or one of the free providers like Hotmail.

I think similar things will happen once there's a well established standard for IM, although instead of new IM companies springing up we'll see the existing providers go backwards and start to interoperate via the common protocol - just like AOL, Compuserve etc eventually got their mail systems interoperating with the rest of the Internet via SMTP.

As long as servers are lacking, jabber will remain an interesting technology that is mostly used in corporate intranets.

People tend to take the stuff they see at work and use it at home. Especially if their client at work can be used to talk to the outside..

Re:weak spot is the server

[jilles]

I'm sure that there are jabber servers which have been running for some time. I'm also pretty sure that none of these servers is prepared to host millions of users. The whole point of jabber is not to have such central points of failure. For developers/early adopters, it is great that you can host your profile at jabber.org, jabber.com or whatever for a while. However, jabber.com sells servers and jabber.org is a non profit organization primarily interested in stimulating development of jabber servers/clients. Neither organization is interested in the long term hosting of millions of jabber accounts.

ICQ, AOL and MSN are propietary networks, if they would go offline that would literally seriously piss off millions of their customers, that's a pretty good reason to assume that that is unlikely to happen (other than by accident).

Re:weak spot is the server

[IamTheRealMike]

If a good public server was available, I would have been running jabber years ago. Well, it's a plug, but here goes :)

I help run the theoretic.com with Adam Theo, which is most definately not a public testing server.

First up, we don't have AOL or ICQ transports, as we got too popular to remain unnoticed ages ago so it's firewalled now. The MSN transport still works fine though, and Yahoo, well, nobody used that :) You can always use an external transport (and many do)

Now for the good news. There are 2 admins in 2 separate timezones (London and Florida time), so there's normally somebody about if you want to chat to an admin. We don't track the latest releases unless we need a bugfix, so the server is stable. We haven't rebooted it since February as far as I can remember.

We also have some features other servers don't. For instance, the SMTP transport is mondo cool. If you send an email to user@im.theoretic.com, it'll be turned into a jabber message. If you reply, it'll be turned back into an email. You can add email addresses to your roster as well if you want to fire off quick messages.

Finally, we try to be as polite as possible. If we're restarting a transport for whatever reason, or need to reboot the server (rare now), we'll send a public broadcast message about 10 minutes before so you can finish up conversations etc.

RhymBox, which is a great little Windows client already, and the new version will totally rock, tied with theoretic should hopefully ease most of the pains that have put off non geeks from using jabber up until now.

Re:weak spot is the server

[hta]

You've identified one of the best points of Jabber: It's a protocol, not a service.
AOL and MSN are services that run their own proprietary protocols; if you buy into them, you have no choice but to accept their terms of service.
With Jabber, as with any open protocol, if you don't like this provider's service, try another.

(The reason there is so much noise around the DNS is that it's the known example of an open protocol that implies a single service....)

Re:Well..

[KagatoLNX]

I've used Jabber on and off from the beginning and I can safely agree that the user end is a bit rough.

However, here are the reasons you want it:

XML: Now I'm sure by the time this is posted, there will be tons of "XML is the future, adopt it and DESPAIR" posts, but in this case, it is a clear benefit. Bascially, due to XML, the message format allows trivial extension of the protocol. Really, you can just make up an XML element, stick it in the right place and *poof*.

"Is it really this trivial?", you ask. Well, one of my pet projects was writing a Jabber bot for pen/paper RPGs (think Dungeons and Dragons). It took about six hours and I added a element (use the sides property to specify type of dice) that would message you back with a dice roll. I never completely finished the client, but it worked.

Keep in mind all I did to do this was hack two copies of the command-line client--no server changes whatsoever. The key here is that any Jabber server will pass custom XML--so protocol content changes *DO NOT* require server changes and are completely client implementable. Freedom for the masses, anyone?

The possibility of custom clients is huge. Unfortunately, the ability for large companies (AOL, MSFT) to control the state-of-the-art and to make sure that, despite interacting with all IM clients, theirs offers better proprietary functionality on their network (i.e. everyone can message, but AOL partnered with newgame.com so only AOL users can use IM to launch NewGame netgames).

Transparency: This is a big win. It is always possible to pull apart the protocol. Heck, the protocol is designed to be human-readable. This has the added benefit of making obfuscation really obvious (why is AOL using elements named option1, option2, and option3? What is the nsakey element for? ...).

OpenSource: You read Slashdot, you know the pros and cons. The less obvious side of this is how it compares to the corporate offerings--specifically SIP. SIP is great, but try to find a free implementation. If you're using SIP for VoIP (which is pretty much the norm) you probably have had to drop a chunk of change on a nasty Cisco CallManager server.

Loosely Connected: Perhaps the most intelligent Jabber decision was to make it just like e-mail. There's no longer a global hostname, but rather a user@host naming scheme. If you're Internet savvy you can get your e-mail address and jabber address to be the same (exercise left to the reader, think about it).

Existing Gateways: Jabber's weirdest appeal is that it already has gateways to access existing services. The docs have the specifics, but the gateways servers can hit AOL and about everybody else.

Good Standards: Practically all of the corporate offerings are standards that were thrown together (Mirabilis ICQ grew like a Frankenstein's monster, see the procotol specs, they're scary http://www.d.kth.se/~d95-mih/icq/). A ground-up thoughtful implementation like Jabber is a Good Thing(TM) compared to some of the messes.

There are other reasons but I'm tired of typing. You get the idea--Jabber stays crunchy in milk. It's nummy. Get some.

Jabber for what, and for who?

[cullenfluffyjennings]

I was at the Jabber BOF and it was quite interesting.

One thing is that jabber was presented as a solution not for instant messaging (IM) or presence protocol (PP) but as a solution for asynchronous transfer of XML. Another BOF, XML Conf, was suggesting there was a requirement for this sort of stuff to provision routers and such.

Most people seemed to feel that Jabber had major issues from a security and privacy point of view for doing IMPP. Remember that the IETF did look at jabber a few years ago for doing IMPP and it was rejected. Since then, many protocols have been proposed. IM can send message in "page mode" where you are just sending a one time message or it can set up a whole session between the clients for cases where you are going to transfer many message back and forth. This second mode is called session mode. Right now the SIMPLE group more or less has a good proposal for page mode and setting up sessions but is debating how to transfer messages in session mode.

I believe that the following companies have said they will support SIMPLE: Microsoft, Yahoo, Lotus, etc. Unlike what the CNET article said, I was told that AOL filed documents with the FCC saying they would do SIMPLE.

If there is a IETF WG on jabber, which I believe might happen, the interesting thing will be to read what that groups chatter is to do - I bet it won't say that it is gong to developed a complete IMPP solution.

On a side note about how this effects open source development, I work with the vovida.org project which develops voice over IP and messaging open source software. We have talked to the jabber.org and jabber.com multiple times. It's always been difficult to figure out how this all fits together from an open source point of view. You see, jabber.com has patents on stuff you need to implement jabber. At the Jabber BOF at IETF I specifically asked them if they would make this IPR available in a way that worked for open source people. They answered that people had implements this stuff and they weren't suing them. This is like yah, DUH, of course when we are trying to get people addicted to the drug we don't sue them. They have NEVER made any commitment to allow this IPR to be used in open source products. They are a desperate company looking for a way to make a business model out of jabber. If you think jabber is the best for open source - give that some careful thought.

Cullen

Re:Jabber for what, and for who?

[stpeter]

Jabber Inc. does not have "patents on stuff you need to implement Jabber" (check the USPTO for the facts). The company does own a trademark on "JABBER" but that will be transitioned to the non-profit Jabber Software Foundation. The Jabber protocol is as free as air, and there are multiple open and free implementations of it (server, libraries, clients).

Re:Jabber for what, and for who?

[Temas]

The allegation that Jabber, Inc. "has patents on stuff you need to implement jabber" is absurd and ill informed. Jabber, Inc. did not even exist when Jabber started, and because Jabber has kept everything in the public eye, and basically put the protocol in the public domain, it's near impossible for Jabber, Inc. to actually own any part of it. Yes, they own the trademark, but as stpeter pointed out it is being transferred to the JSF. It's also true that Jabber, Inc. has many commercial products, but the open source community has something equivalent to most of them.

As to their commitment to the open source community they have people such as myself and stpeter on their payroll that really only work on open source projects and tools. Neither of us have worked on any of the commercial projects in quite a long time.

Re:Jabber for what, and for who?

[AJWM]

One of the cool things about the Jabber protocol is its growing ubiquity (hence likelihood for piercing firewalls along with HTTP) and the fact that it is session oriented rather than HTTP's default "connectionless" mode. Alright, the two cool things about the Jabber protocol are...

Anyway, this makes for easier programming of services that would, if based on HTTP ("web services"), require the usual sorts of messing with session ids and cookies or URL-encoding to work properly. Jabber can be viewed as a high-level transport protocol; it's easy enough to wrap it around whatever data you want transported, especially since it's XML based. Don't forget, the "user" at the other end of that Jabber session doesn't have to be a human at a keyboard, it can be a process. (Okay, the three cool things about Jabber...) Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client" for certain classes of application.

Re:Jabber for what, and for who?

[AJWM]

Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client"

Actually for command-line type apps you don't even need the HTML renderer. You just plug stdout and stdin into some sort of adapter process that converts them to/from Jabber send and receive streams (something like how inetd fires up server processes with stdin and stdout pointing at the socket connection.)

There's probably something like that already out there, I haven't looked. (It'd be pretty easy to write.)

Re:Jabber for what, and for who?

[alext]

One thing is that jabber was presented as a solution [...] for asynchronous transfer of XML.

A store-and-forward network, in other words. That's great, but to actually add value over email you need to know whether the other party is there, whether they've read your message etc.

These are examples of what workflow people call 'process state' information and, perhaps surprisingly, this requires synchronous communication to track. "Messaging" products are always sold as providing a completely asynchronous solution, then awkward details such as guaranteed delivery, resend requests and process state queries raise their heads and suddenly the wonderful asynchronous model needs supplementing with good old RPC again.

Jabber protocols should all be implemented as synchronous and RPC-like at the detail level - any "asynchrony" will emerge from the use of store-and-forward queues, which each party will interact with using simple RPC.

I assume that Jabber isn't already like this because XML-RPC is identified as an extension to the basic protocol rather than the other way around, but feel free to enlighten me.

Re:Jabber for what, and for who?

[IamTheRealMike]

We have talked to the jabber.org and jabber.com multiple times. It's always been difficult to figure out how this all fits together from an open source point of view. You see, jabber.com has patents on stuff you need to implement jabber. At the Jabber BOF at IETF I specifically asked them if they would make this IPR available in a way that worked for open source people. They answered that people had implements this stuff and they weren't suing them. This is like yah, DUH, of course when we are trying to get people addicted to the drug we don't sue them. They have NEVER made any commitment to allow this IPR to be used in open source products. They are a desperate company looking for a way to make a business model out of jabber. If you think jabber is the best for open source - give that some careful thought.

As far as I know, this is just FUD. I've been tracking Jabber since the cows came home, as has Adam, and neither of us has heard anything about any trouble from (enforceable) patents on Jabber.

Having said that, it's probably true. Bear in mind any non trivial program will have patents on it within the US. There are hundreds of patents that affect Linux for instance. What can these companies say, except we won't use them?

Finally, Jabber Inc does have a business model. They sell industrial strength commercial servers and support. This does make money. The question is, will they make enough money to survive.

Unfortunately, J inc has sort of lost its way lately. Andre Durand who set it up has left, and it was taken over by his former bosses who didn't really have much of a business before. The company has been going downhill since then.... I hope they do survive, but it's not the company it once was. Oh, and a quick disclaimer : I now work for Andre, on an unrelated project ;)

Re:Jabber for what, and for who?

[alext]

I'm not convinced that you have really embraced your 'presence' mechanism - it sounds rather as if you'd prefer to treat it as some sort of parallel and separate communication phenomenon. In reality, establishing presence takes you back to square one - you need "live" (i.e. synchronous) interaction to track it.

Now having developed message delivery and tracking mechanisms, it seems a trifle defeatist to deny that you have invented a guaranteed delivery system. Somebody somewhere is recording what each party has received, and ultimately this information can be accessed by a client interested in finding this out.

Latency is a consequence of tracking the state of a distributed system in any form. The good news is that there are plenty of interesting design choices that can be made to minimize it, and I suggest that this is where the Jabber designers should concentrate their efforts.

Re:Jabber for what, and for who?

[AJWM]

it was taken over by his former bosses who didn't really have much of a business before.

I'm not familiar with that stage of the company's history or who exactly you mean, but if you mean the likes of the current Chairman and/or CEO -- well, it has been some years since I worked with them at GeoVision, but as far as, say, Perry goes, I wouldn't call MapQuest "not much of a business".

If you have something specific to say then say it: vague negative statements about one's former employer may leave an impression you didn't intend. But at least you posted the disclaimer.

Re:Jabber for what, and for who?

[IamTheRealMike]

I'm mainly referring to the guys at Webb who started taking over the business, back when the subsidiary was getting bigger than the parent company itself.

Also, it should be noted that I've often talked with employees of the company. Of course they may just be pointlessly doom talking or whatever, but they told me it was nothing like the company it once was.

Well, whatever. I never worked for Jinc myself.

Re:Jabber for what, and for who?

[AJWM]

If you're designing a system from scratch and have a pretty good idea of the bounds of the system, then yeah, you can go with lower-level protocols and writing the code directly to that level.

If you're piecing something together from pre-existing parts or there's a good possibility that the use of the system will extend beyond the bounds you have direct control over, then it helps to have a few adapters and higher level protocols in the toolkit. It may also be that those higher-level toolkits have a level of robustness and ease-of-use beyond what hand-rolling your own to a lower level might have.

But you may have a point. Why do people see the need to layer extra levels of abstraction on top of raw machine code? What was wrong with assembler, Fortran and C that required Python, Perl or Java to fix? ;)

Re:Jabber for what, and for who?

[AJWM]

Jabber-based client application will do something like

[jabber steps omitted]

What I'm trying to figure out is how this is easier, more robust, or otherwise superior to

[tcp socket steps omitted]

It looks to me like pretty much the same set of steps. I'm honestly confused about what the Jabber layer adds, other than xml buzzword compliance. Anyone?

The XML buzzword compliance is actually pretty significant -- not so much for the message content (as you point out, you can send XML with plain old TCP), as for the wrapper. Routing of TCP packets is done at a level way below what most applications can or want to handle; routing of Jabber's XML packets is handled at the application level, and there are standard ways to tell Jabber "routers" (servers) where (what user or service) the packet is to go to. Further, Jabber messages can be stored and forwarded if the destination address isn't currently available. (More like email in this sense).

I think that may be the step you're missing -- the point of Jabber isn't for the client to talk to the server, it's to route through the server to another client (or group of clients).

Because it's XML-based, it is extensible in well-understood ways that any given Jabber-enabled program can safely ignore if it doesn't understand the extension. (But a human might be able to figure out by inspection.)

Protocols are about making it easy for different developers to create programs that will cooperate with each other. Sure, you could create an email system (for example) that used raw RPC calls between client and server, but nobody else would be able to talk to it, at least not without using that same RPC API, which constrains the design. A standard protocol (eg SMTP in this case) simplifies things greatly -- heck, I can send email via telnet to port 25 if I want.

Beyond that (eg your questions about why XML-RPC), well, sure, some of it is just fad or using what tools you already know vs learning a new one. (The "if all you have is a hammer, every problem looks like a nail" syndrome.) On the other hand I've seen pretty fair arguments that XML is just an exotic dialect of LISP, so why not?

Re:Jabber for what, and for who?

[chefmonkey]

The simple fact -- and as Executive Director of the Jabber Software Foundation I have the in-depth knowledge to state this categorically -- is that there is no IPR on "things you will need to implement a Jabber server".

You and Joe Hildebrand need to get your story together, then. (Joe, for the other readers out there, is Jabber.com's Chief Architect, and a member of their senior management team). I was in the same room as Cullen and heard Joe make the exact statements to which Cullen is referring. By Joe's assertion, Jabber.com (not the Jabber Software Foundation) owns patent rights to Jabber-related technologies. The only reassurance that Joe gave during that discussion is that Jabber.com has not pursued anyone for patent infringements to date.

It is interesting to note that the Jabber.com open source license specifically mentions, for example, that "No patent license is granted separate from the Licensed Product", implying that the open-source implementation available from Jabber.com (to which people are contributing) is, in fact, covered by patents owned by Jabber.com.

Not very comforting, from an open-source perspective.

Re:Jabber for what, and for who?

[chefmonkey]

Jabber Inc. does not have "patents on stuff you need to implement Jabber"

Check the minutes of the Jabber BOF held at the IETF in Yokohama: "[P]ortions of the Jabber, Inc., implementation have IPR protection, but there are at least two commercial XMPP implementations from other companies, and the Jabber, Inc. lawyers aren't suing them."

And that was from a member of Jabber, Inc's Senior Management Team (Joe Hildebrand). Not actually being with Jabber, Inc anymore, do you think you know better than their management team what IPR they hold, Peter?

No, I didn't think so.

Re:Well..

[iso]

Fire is a decent IM client, but if one is using Mac OS X, I would strongly suggest using Proteus instead (which, for what it's worth, does support MSN).

I also wonder why you say just because somebody uses a Mac they probably don't need MSN. Unfortunately, MSN is used by SO many people these days that, at least for me, it's been practically impossible to know a large group of friends and not have a significant number of them only on MSN.

- j

Re:Well..

[Mansing]

Maybe that should read "Jabber is, simply put, a universal IM server." The fact that the client implementations are separate from what "legacy" IM services the server can connect to make the protocol that much more appealing.

Jabber on Trillian

[catbutt]

I sure hope someone is ready with a Jabber plugin for Trillian when version 1.0 comes out. (which will allow plug-ins.....incidentally, their beta version of 1.0 -- which is under tight wraps but it leaked so it's not hard to find -- has a Slashdot plugin, which is kind of cool)

Trillian is in my opinion a much better way to have interoperability with the Yahoo, MSN, ICQ and AOL, than by using Jabber (trillian's interoperability is client side, jabber's is server side). Trillian works great and doesn't add an extra, unnecessary layer to communication with the non-Jabber people.

Still, I'd like to use Jabber as my "main" account on Trillian, if only it supported it. That would be the best of both worlds. Trillian's client is by far the best I have seen.

BTW, I'm told that version 1.0 will also run on linux and OSX.

karma whoring at its finest

[altair1]

How stupid. You typed Jabber into Google and copied and pasted most of the first 20 links. In EXACT SAME ORDER too, with the exception of that oreilly link... LOL.

Re:Jabber strength are the different implementatio

[tzanger]

The fact that there are so many clients, none of which is polished, is jabber's biggest weakness.

Yes, Jabber suffers SourceForge Syndrome but two clients in particular stand out: Gabber and my personal favourite, Psi. Both are highly polished and robust clients. Psi's even multiplatform.

Trillian is a good idea done the wrong way. Why put all that code in one application which needs to be constantly updated as the big two (especially AOL) shift their protocol around and block non-sanctioned servers? It's the wrong approach. The smaller Jabber servers don't get blocked since they're well below AOL's radar and the end user gets a much smaller application with far less code to worry about keeping updated.

Re:Q: public servers, experimental groupware syste

[AJWM]

I have some ideas for an experimental groupware system that I would like to play with. One problem that I was anticipating was to sync-up system users when they are online.

I'm not sure I entirely get your point here -- by "sync-up" do you mean giving late-comers the opportunity to catch up on messages that went before?

If so you might want a back-end designed for such a purpose, something like an asynchronous conferencing system like CoSy. That won't fit the bill as-is, but a while back I did some work on separating out the user and storage interface pieces (some documentation/code on that here. Lately I've been thinking that wrapping it all into a Jabber server (with extensions) makes more sense.

OTOH maybe I missed your point.

Re:Well..

[MenTaLguY]

What happens the first time someone registers billyg@microsoft.com?

microsoft.com's jabber server (as designated by the relevent DNS SVC records) would have to allow them to do that.

Registration @ a particular domain is controlled by the jabber server(s) for that domain. Like email.

Most Jabber servers right now allow open registration, but there's no requirement that they do. And anyway, I don't think microsoft.com is operating a jabber server yet.

Re:Just what we need...

[Zeinfeld]

The IETF should give Jabber recognition as the industry standard, and then it is up to the other software manufacturers to comply to the Jabber standard or fall behind.

That is not what the IETF does. Standards do not 'recognize' anything, and plenty of IETF standards fail to be used outside the Working Group.

As for manufacturers 'falling behind', an IETF working group is not going to force them to adopt a standard.

In the IETF adoption is a criteria for recognition. The cases where the IETF has tried to drive adoption have been the least successful (BEEP, GSSAPI, DNSSEC).

Re:I hate these groups

[0x0d0a]

More than three people use MS Messenger?

Re:Well..

[0x0d0a]

What happens the first time someone registers billyg@microsoft.com

Well, his signed messages won't match up an he won't be able to decrypt anything from the PGP pubkey, which you *should* be using...