Slashdot Mirror
IETF Publishes Jabber/XMPP RFCs
stpeter writes "The Internet Engineering Task Force has published the XMPP specifications as RFCs. These documents formalize the core protocols developed within the Jabber open-source community, and publication as RFCs represents a major milestone in acceptance of Jabber technologies. Read on for details."
Good, now hopefully someone with some market clout will pick this up and market an IM program using these protocols to the masses. Jabber may be cool, but it is no MSN or AIM. Both of those have immense market penetration. I have high hopes for this protocol, hopefully someone like IBM will make this happen.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
I for one welcome our new Jabber/XMPP RPC overlords!
What chance one of the big four (aim/icq/msn/yahoo) adopting these standards? Sorry, I did say standards, so you can discount msn. But if any of the other three did, and there was a greater level of interchangability between those, and jabber because of it, the takeup would be much higher.
But that's the thing about standards - unfortunately it's always the big players that seem to set the ones that have any major sway.
~
~
~
-- INSERT --
Does someone wanna give a quick HOWTO and/or a pointer to a suitably high-level explanation? Thanks.
I find your ideas intriguing and I wish to subscribe to your newsletter.
I remember when IETF drafts took less than six years to make it through to RFC status.
It's WAY too late. For me the main feature in an IM client these days is not whether it's decentralized or XML based. It's whether or not it supports audio and video conferencing. I'm saving hundreds of dollars in long distance (including international) charges by using MSN Messenger. I can not migrate to a client that doesn't support audioconferencing at the very least.
"What chance one of the big four (aim/icq/msn/yahoo) adopting these standards?"
Immediately? Very slim.
However, like almost all of the other standardised protocols they will eventually have to be able to interoperate to survive. In the long term they will adopt a standard protocol or they will vanish.
Deleted
I don't think Jabber/XMPP will truly propogate until every ISP hands you out an IM address on their XMPP compliant server along with the email they hand out. Hopefully this standardisation process will go a long way to see this happening.
To all my former colleagues: this is an historic day for Jabber, for instant messaging, and for the Internet. Congratulations!
Erbo - Former employee, Jabber Inc., Denver, CO
Be who you are...and be it in style!
Do any of you think that google could with financial reason build a chat program using Jabber? It would be kind of cool to have a google chat program, and gmail client integrated into plugins in Mozilla. I just don't know if Google would want to be another blip on the chat program landscape. How would they make money? I don't know if I would want them scanning my chat for text adds. Although I have a gmail account and I guess I don't mind it for that, so why not :).
RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
Well, nobody in this thread seems to care so far, but the question is indeed valid: does this mean that Jabber just beat SIMPLE? How will the IETF accommodate these two competing standards?
"In our tactical decisions, we are operating contrary to our strategic interest."
i thought their mo was to standardize on technology that is owned by a company that encumbers said technology with unfree terms? say, like vrrp and sender-id?
i mean, i think it's good they're going back to making standards with nice licenses, but was there a change in personnel there recently?
vodka, straight up, thank you!
Does anyone here actually use the official AIM?
It gets significantly more bloated and less usable with each version. I have stopped upgrading it and only continue to use it because coupled with Dead AIM it is bareable and neccessary as everyone I know uses AIM for IMs. I understand GAIM or Trillian will also connect with AIM, but my point is that AOL is butchering what was once a simple and elequent program.
http://brandonbloom.name
It's interesting to note that Apple will be supporting this protocol. Perhaps that will be the start of some big industry backing.
Would be a great business proposition for google or novell or redhat to follow up on.... A novell branded IM client ... businesses would like that.
What Jabber struggles with is a high quality open source reference server implementation that can serve as the center of gravity for server side jabber development.
Whether it is hgiher level C# / Java or lowerlevel C++ / C there isn't (yet) a body of software with a lot of developer momentum behind it.
Jive just released some of their stuff, will be interesting to see how that unwinds.
If Jabber could get to that gravity producing mass on an open source implementation, I think you'd start to see Jabber expand into reliable messaging, higher volume messaging, presense, communication, BPM and lots of others apps.
I think Google should, and perhaps may, use Jabber for an IM client. I'm sure they are working on an IM client/network...
From what I know of using jabber, you connect to a server and have nicks and users within that server chatting with each other.
This sounds like a perfect implementation for the workplace. I know that businesses have now started to implement messaging programs for their internal networks. With jabber now "official", could we end up seeing this used as a productivity tool? I don't see competition with AIM/ICQ or MSN happening soon.
For those MSN bashers out there, I happen to know many people who use MSN that live outside the US. Don't know if this is a standard thing, but MSN does seem to be a force to be reckoned with as well.
Well, Apple's putting it in Tiger, so at least there's some hope it could go the way of USB...
BTW, AIM and ICQ are the same thing now.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I personally can not wait until we get off the AIM standard. 90% of my friends use AIM. It is bloated, outdated, and down right obtrusive. If people switch to an open source protocol, I think that companies would make more, even though it means giving up their proprietary protocols. I use Trillian, as I hate how AIM treats me. I do not want bright ads flashing, or a "AOL TODAY" pop up. Is Jabber the Linux of Instant Messaging? Should it become? Everybody has their own 'distro' but the core is the same...
Jeff
It's worth pointing out that XMPP is not just for instant messaging.
XMPP standardizes a method for exchanging structured information streams between autonomous entities -- by they human or automated agent.
Thus, when you (as an engineer) need to set up a network of programs that all communicate with each other, you don't have to roll your own protocol, XMPP can do it for you.
Although IRC "botnets" have existed for quite some time, they are typically very primitive and exist mostly in the realm of script kiddies. Further, IRC is unformatted, unstructured, un-standardized text, making it very difficult to parse reliably.
XMPP allows networks programs to communicate with each other in a "native" language -- data structures -- rather than attempting to glean information from a line of IRC ASCII.
I'm currently using XMPP for several local applications: backup agents communicating with each other, sending and receiving mon monitors and alerts, an improved (RSS-like) syndication system, and more.
This ain't your grandfather's IM protocol.
Look up Intranets. Good things don't always need an "Internet" blessing to succeed.
1: Both are in space (HAL from 2001 and the ISS, or both are from the year 2001, IIRC)
2: That is an IMI Galil, the Jewish makeover of the AK-47 (No, really, Jewish... as in Israel)
3: One of the Daimler/Benz guys' daughter, Mercedes, I think.
4: ??? Dunno.
Now watch this drive.
Jabber is that little jem in the back of everyone's minds, it's great, yet nobody notices it. Very much the Linux of instant messaging.
It's open, easy to understand (if you were so inclined you could type the raw XML yourself) simple yet scalable, and improved by JEPs (Jabber Enhancement Proposals) so even though there may be new features (such as vcards, buddy icons, user tunes), the underlying protocol remains the same.
I love Jabber, it's the greatest IM protocol out there. All it needs is users.
I totally agree! I "upgraded" to the new version of AIM recently and it doesn't work correctly. The preferences page that lets you select whether or not to show the AIM.com window on startup doesn't actually stop the window from popping up. The problem is, however, that gaim doesn't work well on Windows with the AIM protocol. I haven't tried it with jabber, though, because no one that I know uses it.
Since XMPP has been in development for a while, hopefully it shouldn't take too much time for it to climb the Standards Track to full Internet Standard. Right now, XMPP is in the Proposed Standard category, which is the first step (look at the bottom of the list).
The next level up is Draft Standard. To become a Draft Standard, the RFC has to be a Proposed Standard for at least six months, have two independently developed interoperable implementations, and have had "sufficient" successful use. I think that Jabber is pretty much a shoe-in for this category. Several servers been in operation for years from which a large amount of experience with the protocol has been gained, so there shouldn't be any contention about XMPP not being mature. There are many independent implementations, so that shouldn't be an issue either. I don't think there will be any problems getting to Draft Standard in six months.
The final step in the Standards Process is Internet Standard, where the RFC retains its RFC number, and gets the all important STD series number. A standard needs to be in the Draft Standard category at least four months (or until at least one IETF meeting has occurred, whichever comes later). On the technical side, there needs to be a significant implementation of the protocol and much more experience using it needs to be gained. The level of maturity for Standards is such that the protocol is believed to be beneficial to the community. Again, since XMPP has been in the works for over two years now and there are now commercial implementations, I don't think there is a problem with the usage requirements. Furthermore, as the only open messaging protocol, it has a large value to the Internet. Thus, I think getting Jabber to full standard easily is not out of the question.
In about a year, we'll have an Internet Standard for IM and prescence (and an open one, at that)!
Show me on the doll where his noodly appendage touched you.
90 pages.
As excessively verbose as XML streams it describes.
Yuck.
Jabber is a presence-aware XML router. Beyond that, it's imagination-bound.
same people using orkut and GMail
I couldn't access to my orkut account for several weeks. It stalls at "Logging in..." while google and gmail work nicely Oh wait! I see the difference, the last two are running on ... while Orkut is running on ...
It's coherent.
sgis ddo ekil t'nod i
AIM/ICQ, Yahoo and MSN have no need to adopt open standards, and never will. Yahoo does so much stuff that Jabber doesn't do - Imvironments, Audibles, etc., and more importantly, they want to be proprietary so they can decide whether or not to allow third party clients to connect to their service. Twice in the past year I've been locked out of Trillian because of Yahoo, and once they even caused Trillian to crash completely. I had to wait for an update to Trillian, which was available within 24 hours. Supporting open standards wouldn't let them do that. Remember, running a massive IM server and developing a client doesn't make you money, but showing ads does, and Yahoo brilliantly works these in as Imvironments.
Imvironments and Audibles, proprietary smilies, etc. are also strong arguments for using Yahoo's client rather than Gaim or Trillian. I don't get any of those things, and someone with Yahoo will inevitibly complain that I'm not in Yahoo, so I have to launch it. Very clever and "viral" of them.
Jabber will probably never reach the same market penetration as the other IM clients, but that's ok, it's not really competition for them. You use AOL if you want to talk to your friends no matter where they are. You ues Jabber because you want complete control over your chat network - who can connect, whether or not you log chats centrally on the server, and who can eavesdrop.
Jabber can work entirely behind a firewall, so your employees can talk to each other and not worry about revealing trade secrets to someone else sniffing their conversation, or talking to their friends and wasting company time. Or you use Jabber because you're conducting business you don't want someone else to find out about. For example, Google might want to use Jabber to communicate because MSN, Yahoo and AOL are their direct competitors and could listen in to their conversations.
You also use Jabber because you deal with clients and need an audit trail. By logging conversations centrally on a server, you can produce an audit trail superior to even email. Being centrally located, if you trust that nobody's tampered with it, you get chat logs that prove what was said when to who, and what the response was. This is similar to centralied web-based trouble ticket systems.
So, while Jabber may have many mechanical similarities to the other IM clients, the actual uses and needs it fulfils are somewhat different.
They exist alongside each other for a while. IETF lets them battle for the users. The winning protocol ... wins.
I'll give an example:
Imagine the HTTP protocol for persistent connections. Let's imagine for a moment that all HTML instances are well formed and that the only other file type to be transferred is JPEG images. Now imagine that responses came without HTTP headers describing the nature of the response as well as the size. Content-length is really important. It dictates the amount of processing the software needs to do to determine when it has read a whole element of the protocol. This is an _IO_ operation and you snould NOT have to parse during pure IO.
You might say "well, if it is HTML, then just parse it and see where it ends, and if it is a JPEG, heck you just parse that and see where it ends".
No proper framing.
Now imagine you are writing an HTTP Cache server which needs to do this for tens of thousands of connections simultaneously. Hard? Of course it is. Hard to do right at least. (We leave the kindergarten solutions to freshman students).
The problem hinges on the fact that in most scalable implementations, you do not follow the one-thread-per-connection paradigm, hence you need to be able to process input in chunks. Given that you are processing many connections at the same time, you want to minimize context for each connection; ie. the amount of state you have to keep around to make sense of the data.
The only way to securely know that the data you've read so far contains a valid element is to try and parse it. If you were able to consume an element, fine, if not, you have to read more data and try to parse the entire thing all over again. (Also, now you need to figure out how much you consumed, and thus, how much of the input buffer you can throw away).
Of course, you could make your own primitive XML parser which can infer stanza boundaries, but everyone who has written an XML parser that is reasonably standards compliant knows that this is not easy. In fact, it is a significant project unto itself.
It is not like this is a new problem. Just look at BEEP (or whatever it is called now). The designers of BEEP quickly realized just how incredibly clumsy a protocol that does not do proper framing is, so they added framing to an XML protocol, and hey presto, you have a protocol that is a lot easier to implement correctly AND efficiently. Or HTTP for that sake.
I feel that the Jabber team didn't do their homework, and I am incredibly disappointed that IETF didn't have someone flag these problems. The fact that it has been so many years since they started working on this, and that they have not stumbled across this themselves does not bode well for the Jabber team.
Let's hope they do the right thing now and add proper framing to their protocol. This way it becomes much easier to implement correct and really scalable servers, and we might be able to get a usable standard that can be used for large-scale IM.
I'm suprised everyone thinks Jabber is DOA. It's no MSN, AIM, or Yahoo. However, it's not supposed to be.
Currently, Jabber is an open IM standard with tools available now. It has been receiving large rollouts for corporate use, and plenty of people use it exclusively for IM. (Myself, recently, included.)
It the future, instant messaging will become more important. Be it text, audio, video, or something new Jabber (with its XML base) can theoretically support it nicely.
And the worry about numbers isn't something I have. It's fairly simple scalability math. For example, if every cellphone/mobile device comes online and even a quarter of them use instant messaging, the AIM/MSN/Yahoo userspace will be completely swamped.
Hey, if you didn't want to use XML then don't and if you were going to compromise anyway, you should have built a hybrid protocol with proper framing. Like BEEP.
This is the sloppiest, ugliest, most naive piece of protocol design I have seen in many years. The protocol bears witness to the fact that the designers can't possibly have had much experience with building scalable IO-intensive systems.
And it really pains me to say so, because I badly want a proper, open IM protocol.
Guys, go back to the drawing board and don't come back until you've at least remedied the most obvious problem: lack of proper, non-XML-parser dependent framing. This is NOT good enough.
I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.
When you write a high-performance multiplexing server (for any protocol) you wish to minimize the state associated with each session or connection. I am not sure this is necessarily easy for Jabber. Its lack of proper framing dictates that you need to do some serious thinking about how to end up not wasting a lot of memory and CPU. Not really important if your server has ~100 clients, but when you want to accomodate millions of clients (as must be the goal for any large ISP when choosing an IM architecture), these things translate into dollars.
As someone else pointed out: BEEP solves the framing problem, as does HTTP.
How do you solve the framing problem in XMPP? How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?
(The figure was chosen because I've observed a hub IRC server handle 7-800 client connections and 4 servers on IRCNet while only consuming about 10% CPU in steady state)
Was really excited seing RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol. I only thought the jabber people were making rfc's for the basic protocol.
Sadly I don't think there is any clients supporting it yet?
Large ISPs have to think about cost and Jabber is just too expensive to use because the protocol is surprisingly hard to implement correctly and efficiently.
Providers that have their own IM systems will stick to them because they are easier to scale in a cost-effective manner. Providers that do not have their own IM systems will either not bother with the cost or buy (access to) one of the more scalable systems.
Just look at how long Jabber has been around. Now look at the number of efficient implementations that would be a candidate for large-scale (millions) deployment in datacenters.
Exactly.
Jabber is a dud. It is a toy for small scale deployment.
IM is even used in warfare.
A good example of this is the CTF-50 Case Study done by OFT. The types of capabilities they used to increase Mission Effectiveness (i.e. Instant Messenger, Web-logs, basic Portal) would be available directly from Core Information Services.
The study doesn't say which IM protocol/client was used. The value of IM over phone/radio was having a history of what was communicated.
I was thinking the exact same thing. My only guess is that SIP/SIMPLE doesn't have the same amount of 'corporate' backing to push it through the standards process? Although, from other, recent articles, I was lead to believe that SIP had made some inroads in VoIP and P2P... So it is a suprising development.
I could be wrong, as I can't see the picture from work, but #4 is most likely the Black Widow. It's black, and has a red hourglass shape on it's abdomen.
I still wish they would have just improved on IRC. IRC has been around since the late 1980s, and was a significant improvement over talk. It is open and extensible, and can do everything the popular instant messenging protocols can do, and could before these protocols existed. It can even act as a bridge to instant messenging protocols.
How does it compare to Jabber? Well, IRC is much simpler (try to write IRC with netcat, then try XMPP). Many stable and featureful IRC clients exist for various environments; this is only beginning to happen for Jabber. On the other hand, IRC nicknames have a global namespace, which leads to immense scalability problems. However, the solution to this is obvious and easy to implement.
Please correct me if I got my facts wrong.
As far as I understand it, both standards are attempting to map themselves to CPIM (RFC-3862). And I'm pretty sure there is already at least one working gateway from Jabber to SIMPLE, so the two can co-exist in practice anyway.
In the end I hope it's the developers who get the say over which one stays and which one goes. If they get intimidated by the ironic nature of SIMPLE (it's not simple!), and every developer decides to use Jabber/XMPP instead, then all the best apps should inevitably be based on Jabber. That would pull in the most users, and they would win.
About the worst thing that could happen would be for Microsoft to back SIMPLE, write some shitty apps for it, and force them down the throats of the users of their OS. Which... is probably what's going to happen, since Microsoft have been supporting SIP for some time now.
Karma: It's all a bunch of tree-huggin' hippy crap!
There have always been rumours and speculations that someone like Google would get into the instant messaging space. I suppose people think of this as retaliation... Microsoft tried to infringe on the search space, which Google is pretty much the king of right now. So to get back, they really should make an instant messenger which everyone wants to use, just like they made a web mail service which it seems everyone wants to use.
If they ran such an IM system on XMPP, you would see quite a few new users accumulate in a rapid fashion, even if they didn't know they were using the protocol. Think web messenger. :-)
Karma: It's all a bunch of tree-huggin' hippy crap!
AOL, ICQ, Yahoo and MSN will continue to rule the roost and people will continue to be forced to use the crappy lame official clients or risk having their third party client locked out because the protocol was changed for the umpteenth time.
What do these really mean?
Could you elaborate on the short forms....(the only thing i know is the intl space station - ISS).
Also the spider has a resemblence to humam face in the abodomen - not hour glass..
You could consider posting as AC - I dont want to your karma to be burnt!
this is the guy who posted parent.SD doesnt allow more than 10 posts per day!
I Also got another explanatin from another guy....
so is that IMI galil or FAL?
The proper name is: Fusil Automatique Leger which translates to light automatic rifle. The rifle is sometimes called "the right arm of the free world". Not sure how much more famous a rifle can get...
Perhaps AK's and M16's are more ingrained in the American psyche, but this is twice the rifle they'll ever be. It has been adopted by 70+ countries and various South American freedom-fighters and drug cartels. The true compliment to its design is that these 70 nations PAID for the FAL (10 of them bought manufacture rights), where as M16's and AKs were typically given away by the US and USSR respectively.
The FAL is gas operated with a op-rod to cycle the bolt, unlike its biggest competitor the Heckler&Koch G3 which uses a roller locked delayed blow-back design. Both are very robust and incredibly fun to shoot. I highly suggest trying it out. Head over here for more info:
http://falfiles.com
I own a G3 variant and plan on getting an FAL soon.
As for famous in another context? hmm. I think I saw it used in the movie Heat by Val Kilmer's character. But hollywierd's fiction doesnt hold a candle to the real thing.
Also, I seem to remember something about NASA and FEMA choosing Jabber for their needs, and IBM's CapWIN law enforcement / first response flash network using Jabber.
It's interesting that you should bring up IRC. IRC has no means for determining the content length of a message without "parsing" it to wait for the newline. But parsing is grossly inefficient, apparently, so obviously it can't attain the sort of throughputs of which you speak. :-)
Karma: It's all a bunch of tree-huggin' hippy crap!
WHy the hell do they use an XML based protocol? XML is when something has to be human readable and unless its for the benefit of some line tapping hacker who the hell is going to read IM packets? Not only is XML bloated and so sucks up bandwidth (important if you're still on dial up) but its slow to parse and generally ugly. "But its for developers!" someone shouts. I'm sorry? Just how dumb a developer do you have to be to not be able to grok some efficient binary protocol? "But its a standard" someone else shouts. No it isn't. XML is a shell , you can fill it with any old shit and just because something else is "XML based" doesn't mean it will understand it. Using XML for IM is a clear case of jumping on the bandwagon for no reason other than the sheep mentality coming to the fore.
Do you still need a unique username or does it assign an id?
I could see the advantage of say using your email address as the username, but I'm blind.
I know you are psychotic, but please make an effort.
I have several Jabber buddies on my gaim-buddy list, but for some reason I always use icq to communicate with them. It would be really nice to implement some of those fancy Jabber protocols in gaim. If Jabber got an edge over icq, then I would have a reason to start using it :)
I must admit I have never heard of simple, but a quick search (terms: Jabber SIMPLE) reveals that there is a gateway in development: see article.
Jumpstart the tartan drive.
Nicknames aren't the only problem with IRC, though. It also has fundamental scalability and reliability problems. (Speaking as someone who's deployed servers and written client code for IRC.)
The scalability problem comes from the fact that every IRC server must carry all IRC traffic, not just the traffic for the users it is serving.
The reliability problem comes from the fact that the IRC protocol is based on a tree topology with a single point of failure at the root.
Then there's the fact that a lot of the basic functionality (e.g. presence information) is just a hack, implemented via CTCP rather than being part of the IRC protocol. As a result, it's often not implemented by clients, and is so unreliable that it ends up being useless. Don't believe me? Watch how many people feel the need to announce that they are away with messages, rather than using the standard "away" mechanism.
I'm no big fan of Jabber; I think it's a horrendous protocol, in fact. But it's a carefully thought out, complete and scaleable protocol, which is not the case for IRC.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Sure, I'll mod you down. But not because you asked for it. It's because you are trolling.
Of course. I just give anybody I want to talk to an account on my system? Or what about presence? shall I go around and log into 30+ systems just to see if my contacts are availabe? There many reasons why simple telne/ssh/talk are not sufficient for IM.
You're absolutely right. Jabber could be the nervous system of future businesses. I've been putting inter application communication systems together using NNTP servers given the costs of traditional middlware systems, quite a lot of work and the data formats are simple, but it works fairly well but Jabber would be faster and could be more standardised, more ubiquitous.
a re/
e.g.
http://www.archeus.plus.com/colin/middlew
Deleted
Go take a look at the initialization subsystem of any modern Unix (or Linux). Go take a look at how you start X. It's startling how much of Unix is driven by Borne (or Korn or C) shell scripts. Perl's ok, I guess, but it's very definitely not the glue that holds Unix together.
The problem is SIMPLE is a great non-standard. IBM and Microsoft both talk about SIP (Session Initiation Protocol). They have non-interoperable implementations. No one talks about SIMPLE (IM using SIP), they say they are standards based because they use SIP.
SIMPLE is extremely weak and dead ended.
XMPP integration with SIP as a SESSION INITIATION PROTOCOL has some promise.
XMPP is very rich and has lots of potential for data exchange. The vendors all want to market voice and video integration, but I think it misses the point.
There is a lot to be said for text and structured data? Could you imagine slashdot threads occuring over audio????
HTTP and SMTP as ubiquitious protocols are nice but we need something more real time / asynchronous.
The idea behind Jabber/XMPP is you don't need a monolithic server. Anyone can have a server as they do with Email (SMTP).
There are some companies offering Jabber/XMPP services like telco's. Check out Jabber.com and Antepo.com for their customer lists.
Yes, ISPs should offer Jabber/XMPP servers to their users. It would allow them to wrestle back some of their user base from AOL/MSN/Yahoo.
What's needed to get people off of the proprietary IM platform is good public servers that you could move your non-so-technical friends and relatives to.
It would be fantastic if Google became a serious player in IM and beyond.
However, what about Slashdot (and it's parent company)? Why couldn't they offer an IM service based upon Jabber/XMPP?
Think about the possibilities of integrating Jabber/XMPP conference rooms (mult-user chat) (JEP-0045) into slashdot discussions.
Slashdot is already a great community. Why not make it more real time than just RSS feeds?
Instant Messaging is turning out to be a vital business tool. Take a look at The Financial Instant Messaging Association, (aka FIMA) http://www.financialim.org/membership_financial.ht m
m l
a rticle.php/3345961
Financial Services run on messaging. In the past it was all very proprietary home grown solutions. A number of firms have seen the potential for Jabber/XMPP and deployed Enterprise Instant Messaging solutions with external connectivity to clients and counter parties.
Reuters is getting very serious about IM. However they've been a Microsoft shop for a long time and hired away the LCS team from Microsoft. They are still trying to own the whole network and keep things under their control.
Another company offering XMPP based solutions for Financial Services is Communicator, Inc. http://www.communicator.com/HubConnex_Features.ht
EBS is building a Foreign Exchange trading platform with Jabber/XMPP. http://www.instantmessagingplanet.com/enterprise/
IBM has SIP/SIMPLE based products, but when IBM Global Services needed to build a solution for 911 Emergency Services, they built a system on top of Jabber.
Remember this all started with Jabber the open source product. It's available for you to use freely for IM, or better yet for application messaging. Slashdot users can make a serious difference. Get the companies you work for to try Jabber. Try to avoid Micro$oft's LCS
Cheers to Mandrake for including Jabber RPMs in it's linux distro. (I'm not saying other distro's don't include it as well, but it's the one I use).
Actually I wasn't trolling. But thanks for proving my initial point anyway. Theres always one of you around.
Microsoft IS trying to push it's version of SIP/SIMPLE down everyone's throat. It's called LCS. It will be integrated in to M$Office and others. It will become the dominant IM platform and it's basically just 1-to-1 IM, no group chat.
Developers are the only ones who could make a difference.
URL:http://www.antepo.com/ has working commercial SIP/SIMPLE gateways to both LCS and IBM's sametime.
Is it just me, or is this stuff needlessly complicated? This is the first time I've read it, so I'm not really familiar with it, but did I see them recreating the concept of a URL...poorly? And why the emphasis on using this with TCP? Is there some reason that the transport protocol is that important? What if I want to use this with multi-casting, or skip the transport entirely and use a plain old serial cable? Is there any particular reason I shouldn't be able to?
It's a neat idea regardless. I'm just glad I don't have to implement it.
G-chat is nothing compared to G-spot.
3.243F6A8885A308D313
Too bad about the hideous name.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
IRC always seemed overflowing with juvenile h4xx0r wannabes. All the "cool kids" (the FreeBSD development group, UNM geeks, Santa Cruz geeks, etc) hung out on Internet Citizen Band servers. ICB was also developed in the 1980's, but never took off like IRC did. ICB geeks generally agree that this is a good thing -- a high quality clientele makes for a more pleasant experience than high quantity.
ICB's ease-of-use and relative simplicity was also a huge win, over IRC's poorly-implemented oodles of features, IMO.
The folks developing the next-generation ICB have also been going with an XML-based protocol. I guess that's the trend these days; people seem to think this syntactic sugar is the best thing since sliced bread.
-- TTK
At our startup we're working on a new take on the instant-messaging space. Our new product ubergroups.com is currently in beta. It's a team based, on demand IM service for users who need security and want to get past the limitations and consumer-oriented nature of AIM/Yahoo.
We've based it on XMPP so you can use whatever client you want to send IMs... including iChat in the next OS X release!
We picked XMPP because of the wide array of client software available that implements it, and because it can handles complexity and additional (optional) protocol features well. It's a good basis for a first-class IM service.
If you're curious please give it a shot and send us any feedback or ideas you have! Thanks.
That's basically what I just said, isn't it?
Karma: It's all a bunch of tree-huggin' hippy crap!
Bellsouth (a baby bell operating in the Southeast US) has a large Jabber server implementation. Press release. FAQ. One thing I wish they would do is provision the account and provide that info to new users as signup. You have to search their website or ask support to find out about it now.
When technological advances end up in RFC's and not patents...
Jedis are stupid. If they were so powerful, why couldn't they handle counseling for a kid who missed his mom?
I don't think the parent intended to get into a legal argument. I think the idea was that if you use existing open source libraries, you can build XMPP chat into an application with know the ins and outs of the XMPP-IM standard.