Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Communications The Internet Software

IETF Publishes Jabber/XMPP RFCs 248

Posted by timothy from the jaw-gab-palaver-prate-yak-blather dept.
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."
This discussion has been archived. No new comments can be posted.

IETF Publishes Jabber/XMPP RFCs More

IETF Publishes Jabber/XMPP RFCs

Comments Filter:

  • Market Penetration (Score:5, Insightful)

    by The Snowman ( 116231 ) * on Monday October 04, 2004 @11:46PM (#10436708)

    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.

    • Re:Market Penetration (Score:2, Interesting)

      by LnxAddct ( 679316 )
      or Google? :) I really hope they come out with a GIM.
      -Steve

      • Re:Market Penetration (Score:5, Interesting)

        by The Snowman ( 116231 ) * on Monday October 04, 2004 @11:57PM (#10436770)

        Google makes a great search engine, I do appreciate their Usenet archives, but they do not have the Midas touch. If they made a GIM I am sure they would have a hardcore following, probably the same people using orkut and GMail, but I doubt they could market it to enough people.

        Jabber is much more than a simple IM protocol, but that is where it needs to take root. I doubt even Google can see beyond IM here, but someone needs to (hence the IBM reference). A wise man (the Linux nerd who converted me) once told me (while drunk) that "Perl is the glue that holds Unix together." Jabber could be the glue that holds networks together at the application level (I am not drunk but I wish I was). Cross-platform, standards based (XML), extensible, versatile...

        • Re:Market Penetration (Score:5, Informative)

          by vr ( 9777 ) on Tuesday October 05, 2004 @02:42AM (#10437313)
          If they made a GIM I am sure they would have a hardcore following, probably the same people using orkut and GMail, but I doubt they could market it to enough people.
          It's Google. Sure they could.

          And the cool thing is that with IE, Mozilla, _and_ Opera (in the upcoming 7.60 release) supporting XMLHTTPRequest, they could make a web-based IM, without using such nasty stuff as Java or Flash.
        • 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.

          e.g.
          http://www.archeus.plus.com/colin/middlewa re/

    • Re:Market Penetration (Score:5, Interesting)

      by mo ( 2873 ) on Monday October 04, 2004 @11:53PM (#10436743)
      Actually, Jabber has found a very good niche doing behind the scenes work in lots of commercial software. For example, we were using it in my last job writing console video games. We're also looking to use it in a current voip product at my new company. The thing is, most of this work uses LGPL/BSD licensed libraries like iksemel [jabberstudio.org] so you'd never know that the underlying protocol driving that video game chat lobby is jabber unless you ran tcpdump on it.

      • Re:Market Penetration (Score:3, Interesting)

        by jeif1k ( 809151 )
        The thing is, most of this work uses LGPL/BSD licensed libraries like iksemel so you'd never know that the underlying protocol driving that video game chat lobby is jabber unless you ran tcpdump on it.

        In both cases, you are required to acknowledge inclusion of the software. Furthermore, in the case of the LGPL, you are required to offer redistribution of the library to your users (which means that they must know that you are using it).

        In fact, if you want to behave decently, you should (1) acknowledge

    • Re:Market Penetration (Score:5, Insightful)

      by Sheepdot ( 211478 ) on Tuesday October 05, 2004 @01:24AM (#10437091) Journal
      Actually, the ease of use and portability is what will eventually make Jabber the new thing. Don't get me wrong, Yahoo, AIM, and Microsoft's alternative have a lot more functionality, but that same functionality can be easily integrated into Jabber. In fact, many have done so already.
    • hopefully someone like IBM will make this happen

      HP do that for us. Not only are they sponsoring various Jabber-related projects, but they also use Jabber for internal IM. I can reach any HP employee using the internal Jabber system (Yes, I work at HP).

    • 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 ac

  • So how does jabber work then? (Score:5, Interesting)

    by B747SP ( 179471 ) <slashdot@selfabusedelephant.com> on Monday October 04, 2004 @11:49PM (#10436720)
    OK, I know, I should RTFRFC, but in a nutshell maybe? I tinkered with jabber for a bit, couldn't get my head around how it worked in a big-picture sense (servers, networks thereof, how to find a server with lots of like-minded folks on it, etc, etc). I'm ashamed to say that I've always ended up traipsing back to IRC/ICQ/Yahoo despite that my client [miranda-im.org] and my other client [sourceforge.net] both speak jabber fluently...

    Does someone wanna give a quick HOWTO and/or a pointer to a suitably high-level explanation? Thanks.

    • Comment removed based on user account deletion

    • Re:So how does jabber work then? (Score:5, Informative)

      by Hawke666 ( 260367 ) on Tuesday October 05, 2004 @12:51AM (#10436986) Homepage
      In a nutshell, it's pretty similar to e-mail, only without indirect routing between servers, and (partly therefore) less store-and-forward, and definitely less latency. It also includes presence information. See also http://www.jabber.org/oscon/2004/jabber-bootcamp.p pt
      and http://en.wikipedia.org/wiki/Jabber

    • Re:So how does jabber work then? (Score:5, Informative)

      by mindstrm ( 20013 ) on Tuesday October 05, 2004 @01:10AM (#10437047)
      The glossed over version:

      jabber is multi-site, like mail. You don't need a server with like-minded people... all jabber users globally can chat with each other (unless, you know, you set up a private jabber server, etc.. same with email)

      The protocol is open and extensible, and supports the idea of extended transports.. so the jabber server can act as a gateway for msn/icq/aol/foo/bar/baz. My jabber server deals with all of this... my yahoo/aim/icq/msn contacts are all stored on my jabber server.. I just sign in with whatever jabber client I want, and it all just works.

    • Simple Explanation (Score:3, Insightful)

      by ari_j ( 90255 )
      Jabber is a presence-aware XML router. Beyond that, it's imagination-bound.

      • Re:Simple Explanation (Score:3, Informative)

        by ari_j ( 90255 )
        I should note that I used Jabber as the network layer of my honors thesis project, a general-purpose distributed computing architecture. If my web server weren't dead this week, I'd share a link with you, but rest assured that Jabber makes things simple that would otherwise not be.
    • I'm not sure exactly what you're asking when you want a "HOWTO"... are you trying to set up a server?

      Because if you just want to figure out how to use jabber as a client, just use gaim (or any other multi-protocol client), and then register a jabber account at jabber.org, and start looking for other people with jabber accounts. Not sure what you mean by "a server with lots of like-minded folks on it", any jabber server can talk to any other jabber server.

      Jabber is basically the same as email, except that

  • took long enough (Score:4, Insightful)

    by js7a ( 579872 ) <james@nOspAm.bovik.org> on Monday October 04, 2004 @11:50PM (#10436727) Homepage Journal
    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.

  • Propogation (Score:4, Interesting)

    by Guidlib ( 814472 ) on Monday October 04, 2004 @11:57PM (#10436772)
    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.

  • From an ex-Jabber Inc. guy (Score:5, Insightful)

    by Erbo ( 384 ) <amygalert@gma[ ]com ['il.' in gap]> on Monday October 04, 2004 @11:58PM (#10436783) Homepage Journal
    I know that this represents the culmination of many years of effort on the part of many people, both at Jabber Inc. [jabber.com] and in the open-source community, especially Peter Saint-Andre [saint-andre.com], Jabber architect and evangelist extraordinaire. And, of course, without Jeremie Miller [jeremie.com], none of this would even exist.

    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

    • I don't get it..

      is someone just wandering around randomly moderating things troll?

      This is the second completely on topic and reasonable post I've seen marked troll...

      Has moderation lowered to the point where you just flip a coin these days?

  • Needed... bad (Score:3, Informative)

    by SnprBoB86 ( 576143 ) on Tuesday October 05, 2004 @12:01AM (#10436793) Homepage
    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.
    • AOL's pretty good at that sort of thing. After all, look what happened to ICQ after they bought it in 1998.

    • The problem with any third party client is directims are more likely to crash you than they are to work. Sure, gaim can usually get a connection going, but once someone pastes a bitmap or a large jpeg or whatever, there goes your client.

      WinAIM breaks compatability with itself pretty much every version, but atleast if it fails it fails gracefully.

  • Industry Support (Score:2, Interesting)

    by Guidlib ( 814472 )
    It's interesting to note that Apple will be supporting this protocol. Perhaps that will be the start of some big industry backing.

    • Re:Industry Support (Score:3, Insightful)

      by Erbo ( 384 )
      Actually, Apple has been supporting this protocol, in their iChat software. It uses Rendezvous to get two nodes connected, but the message traffic between them is XMPP.

  • Open Source Reference Implementation (Score:5, Insightful)

    by augustz ( 18082 ) on Tuesday October 05, 2004 @12:15AM (#10436855)
    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.
    • One problem I had when using Jabber for my honors thesis project was that it doesn't make fully-standard use of XML. The way the protocol assumes namespaces work is incorrect, and a fully-compliant XML parser will not work with Jabber, in my experience.
      • Indeed, it is my observation as well that Jabber is somewhat of bastard protocol in that it uses XML, then doesn't want to be compliant with the spec and then fails to add needed mechanisms for making implementation easier.

        As mentioned earlier, I looked at what is today known as XMPP a few years ago, and decided it wasn't really worth the hassle because the protocol didn't really solve the problem at hand well.

        Jabber has some good design decisions; the sloppy use of XML and its failure to identify im

  • I think Google should, and perhaps may, use Jabber for an IM client. I'm sure they are working on an IM client/network...

    • Re:GJabber (Score:5, Informative)

      by timealterer ( 772638 ) <slashdot@@@alteringtime...com> on Tuesday October 05, 2004 @12:30AM (#10436923) Homepage

      Right from the Google corporate philosophy: "Google does search. Google does not do horoscopes, financial advice or chat."

      While it'd be wonderful for Google to come along in its shining armour and rescue us from the oppression of closed IM protocols, I think the fact that not doing chat is right in their official philosophy is worth noting. Of course Apple's iChat will have support for it, in OS X 10.4, and others may well follow... just maybe not Google.

      • I dunno, they could adopt chat and then focus on searching the chat logs... just like they did for email. I never delete my gaim logs, but hell if I can ever find anything in it (grep only goes so far).
      • From that philosphy, Google does not do email either. Oh, wait a second...

  • Not just instant messaging (Score:5, Informative)

    by jgarzik ( 11218 ) on Tuesday October 05, 2004 @12:34AM (#10436936) Homepage
    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 [kernel.org], an improved (RSS-like) syndication system, and more.

    This ain't your grandfather's IM protocol.

    • Re:Not just instant messaging (Score:4, Insightful)

      by jgarzik ( 11218 ) on Tuesday October 05, 2004 @12:46AM (#10436972) Homepage
      To elaborate a bit further...

      The reason why XML is so darned handy is that is captures the essence of what makes a computer useful: data structures. XML standardizes parsing (never write a text parser again), leaving only the task of grok'ing data structures to the programmer.

      XMPP takes that a step further: a standardized way two programs may exchange data structures.

      To me, this has all sorts of useful implications, particularly in enterprise installations. Now engineers can stop rolling their own TCP protocols just to get two custom applications to communicate with each other; they can now use XMPP, and exchange data structures.
      • Yup, this would have been good to know a couple years ago when I wrote our client/server tcp stuff for our database app. (Initial revision had used samba 'mailslots' -- serverless-ish, damned slow, damned annoying across subnets, and did I mention really slow?) It was (is) responsible for forwarding refresh information from each client to other connected clients, to keep listviews refreshing with the data (callbacks to decide if the updates are relevant, etc.) It works, it's messy, it was a good learning ex
    • As I stated elsewhere, I consider XMPP to be a "presence-aware XML router". If you need XML to get from point A to point B in a presence-aware fashion, Jabber is the protocol to use. And if your data can be at all sanely represented* as XML, it qualifies to use Jabber as a presence-aware router.

      * - <wtf-data href="http://server.com/manymegs.dat" /> is a valid representation of data - no excuses!
    • Ok. What have they done to prevent spam here. email/smtp had some design
      flaws when it comes to identifying senders. Does Jabber "solve" this.
    • Sheesh..
      It's what XMLRPC and SOAP are for. Look ma, RPC over XML via any medium (http, e-mail, ftp etc etc). And it's _widely_ supported.
      Would you please enlighten me why XMPP is better than SOAP?
    • You know you're getting old when your grandfather has an IM protocol.

      --HC

  • Great start! (Score:5, Informative)

    by pyrrhonist ( 701154 ) on Tuesday October 05, 2004 @01:04AM (#10437034)
    This is a great news! After years of being an Internet Draft, Jabber finally entered the Internet Standards Track. This is good news for end-users, as a standard IM protocol with a standard presence protocol is exactly what we need to integrate disparate messenging devices like cell phones, VOIP phones, and IM clients. I am totally thrilled about this.

    Since XMPP has been in development for a while, hopefully it shouldn't take too much time for it to climb the Standards Track [ietf.org] to full Internet Standard. Right now, XMPP is in the Proposed Standard [rfc-editor.org] 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 [jabber.org] 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)!

    • 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 [bitlbee.org].

      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

      • Re:IRC (Score:4, Informative)

        by pyrrhonist ( 701154 ) on Tuesday October 05, 2004 @04:51AM (#10437649)
        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.

        Yeah, IRC has some nice features, and it was the way to do IM before there was such a thing as IM (talk and write be damned). All the cool kids were using it.

        Unfortunately, its adoption as a standard ran into some issues:

        • RFC 1459, the Internet Relay Chat Protocol RFC was placed into the "Experimental" category.
        • Many programs implemented special improvements that were eventually collectively released as RFCs 2810 through 2813. These RFCs, though, were marked as "Informational".
        • The IRC Client-To-Client Protocol (CTCP) for sending structured data between clients was released as an Internet Draft, but was never made an RFC.
        I think the real killer of IRC as a standard, was the release of RFC 2779, "Instant Messaging / Presence Protocol Requirements". IRC just wouldn't fit this model without a major overhaul, and at that point, you have to question whether it would be worth trying to do that without sacrificing compatibility. It was probably easier to just write a new standard.

        How does it compare to Jabber? Well, IRC is much simpler (try to write IRC with netcat, then try XMPP).

        At it's base level, yes, it's definitely easier. You can do most of what you need for IRC with just a Telnet client. This is kind of fun actually.

  • Don't you just love 90 page RFC ? (Score:2, Interesting)

    by Anonymous Coward
    90 pages.
    As excessively verbose as XML streams it describes.
    Yuck.

  • Good for Jabber (Score:4, Insightful)

    by marktaw.com ( 816752 ) on Tuesday October 05, 2004 @01:34AM (#10437122) Homepage
    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.

    • Re:Good for Jabber (Score:3, Insightful)

      by kyhwana ( 18093 )
      Maybe you like all that flashy crap, but I use IM (gaim in windows in this case) for just IM and (sometimes) file transfer. I don't want imvironments "smilies", "audibles" and all that other crap.
      (It also lets you ignore all the fonts/colours/etc that other people have set, which a godsend, so I don't have try to read red text on a purple background or something equally hideous)

      For me, all the crap is a strong argument for NOT using yahoo's client.

  • XMPP Still Broken (Score:5, Interesting)

    by Anonymous Coward on Tuesday October 05, 2004 @02:38AM (#10437306)
    XMPP has a serious design flaw in that it does not implement a framing protocol that helps the software that parses the protocol to separate messages. This might not be an obvious problem to the casual programmer, but if you are going to make scalable implementations that can multiplex thousands of connections, this is a very serious problem indeed.

    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.

    • You're 100% right. I stumbled upon the same problem when I was trying to implement a simple Jabber client some time ago (b/c all currently existing for Mac OS X suck pretty badly), and I had a pretty simple solution: I wrote a parser that only balanced the tags (look for <, check for / as the first or last non-whitespace character of the tag, look for ? or ! as the first or last non-whitespace character, etc), that took only a few lines of code and worked fine.

      It's more complicated than it's supposed to

      • Exactly, what you ended up doing is what I've seen a lot of other people do (for XMPP and similar protocols) and what most people suggest when presented with the problem.

        This is not a problem that is likely to be of much concern in trivial or naive implementations, but it becomes a major pain in the neck if you try to juggle with more than a few connections.

        The problem with the solution you had to resort to is:

        • It is a complex solution. The point of using XML is to not have to write a par

        • There are probably a few things to say.

          The XMPP spec everyone has now read describes a method for mapping XMPP over TCP. It also says that TCP is only one example of a transport for the protocol. A further JEP, JEP-0124 [jabber.org], describes binding XMPP to HTTP... thereby HTTP becomes the transport for XMPP.

          Of course, they could then invent XMPP over UDP, with one stanza (or frame) per UDP packet. Since UDP already tells you how big the frame is, your requirements are satisfied. But in all honesty, you'd have t

          • First off: the only interesting transport for XMPP is the one actually being widely used, so using UDP, HTTP or something else which does provide framing (albeit at the cost of their own set of new problems) is somewhat academic.

            Second: just because something is possible or doable doesn't mean it is as simple as it should be. Parsing content for discovering stanza boundaries is inelegant and it is more error prone than it should be and it is more work.

            The whole point of using XML in the first place i

    • Re:XMPP Still Broken (Score:5, Insightful)

      by vidarh ( 309115 ) <vidar@hokstad.com> on Tuesday October 05, 2004 @04:40AM (#10437612) Homepage Journal
      You're assuming that parser state is going to be larger than keeping an input buffer large enough to keep a complete message.

      In the real world, XML is a very verbose protocol, and in most cases it is trivial to store the incoming data in a less space consuming format. Using a SAX parser that is reasonably efficient, the only state you will need to keep track of is namespace declarations and open tags - that is highly unlikely to be much data, and certainly unlikely to get anywhere close to closing the gap between the maximum size of a well parsed data set and the maximum allowed size of a message. As a consequence, a well written server should REDUCE state by parsing as you go, not increase it, and only a complete moron would keep trying to parse the message over and over again from the beginning each time.

      Even if this wasn't the case, a well written system would run into bandwidth limitations and IO limitations of the server long before memory limitations in any sane configuration - memory and CPU is cheap, good IO subsystems aren't.

      As a benefit of this approach, by the time all the data has arrived from the client, you have the message in a much more efficient representation. In fact, in many cases you might have enough information even before you have received the complete message that you may not even need to store the rest of the message as it comes in.

      The idea that you need the complete message before you start doing work on it is flawed - it implies that during sudden bursts of activity, your system will sit mostly idle until complete messages have been received, and then suddenly be swamped with processing, instead of spreading the processing cost over the whole time it takes to receive a message, which could potentially be a "long time" for many clients on slow connections.

      • The idea that you need the complete message before you start doing work on it is flawed - it implies that during sudden bursts of activity, your system will sit mostly idle until complete messages have been received, and then suddenly be swamped with processing, instead of spreading the processing cost over the whole time it takes to receive a message, which could potentially be a "long time" for many clients on slow connections.

        Hmm, I can't say that I've seen that happen a lot in practice. I've written

    • AC said:

      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.

      In fact the designer of BEEP, Marshall Rose, has been active in the XMPP area (he took the minutes for the Jabber BOF in Yokohama, summer 2002). So it's not that they had nobody around with a

  • The Future of IM (Score:3, Insightful)

    by Scott Robinson ( 108176 ) on Tuesday October 05, 2004 @02:43AM (#10437317) Homepage
    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.

  • XMPP Framing problem fixed or not (Score:3, Informative)

    by borud ( 127730 ) on Tuesday October 05, 2004 @03:02AM (#10437365) Homepage
    I just threw a cursory glance at the XMPP specification and I still can't see any fixes for the framing problem.

    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)

    • Could you elaborate a little bit for me. Aren't you going to have to parse the content one way or the other?

      Yes, I know I don't have a great grasp of what you're saying but I'm trying to obtain one.

      --HC
      • Yes, you have to parse the content in any case, but lack of proper framing makes the IO system depend to a greater degree on understanding what it is transporting because it has to understand when it has a complete message.

        The IO code will have to use the parser to figure out if it has 0, 1 or more stanzas that can be consumed.

        This results in inelegant, inefficient and ultimately fragile code.

        (Which is OK for most people since most people are going to be writing simple applications that only concer

    • 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. :-)
      • Well, IRC employs "the other efficient means for framing": trivial boundary separators.

        An IRC message cannot contain a CRLF sequence because this is the sequence used to delimit messages.

        I am not saying that this is a fantastic way to do things, but it is significantly easier to implement correctly. (Note that easy to implement correctly is what we are after -- not simply easy to implement).

        Consider the differences in implementation complexity between a correct parser that can:

        • Recognize a
        • Neither the CRLF parser, nor the XML parser have to be written by me, since they have both already been done and I can re-use other people's existing parsers. Why write a new one? Boredom?

  • Crypto (Score:3, Informative)

    by daserver ( 524964 ) on Tuesday October 05, 2004 @03:04AM (#10437370) Homepage
    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?

    • It's sad to see that the End-to-End Encryption spec which made it in uses S/MIME.

      Pretty much nobody in the community has expressed interest in implementing S/MIME-based encryption in clients, partially because the existing OpenPGP-based implementations work, but also because S/MIME is a dog to deal with, both as a developer, and as a user.

      So no. I don't think you'll see any clients supporting it for quite some time. But Psi and Gabber still support OpenPGP, right?

  • 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.
    • This may be true *now*, but sooner-or-later enough people in positions where their influence is important will realise that an open, IETF support, XML-based messaging client makes more sense for their business than tying themselves into a proprietry networks that will eventually be questioned by organisations like the FCC.

      Failing that, check out the Jabber Components [jabber.org] and MSN/AOL/ICQ/Yahoo!/SMS/E-Mail gateways, your clients need not worry about 'crappy lame official clients'

Slashdot Top Deals

"Tell the truth and run." -- Yugoslav proverb

Close