Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet

Jabber Could Get An IETF Working Group 125

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."
This discussion has been archived. No new comments can be posted.

Jabber Could Get An IETF Working Group

Comments Filter:
  • Links (Score:3, Informative)

    by Taylor_Durden ( 605279 ) <SlashdotTylerDurden@hotmail.com> on Monday September 02, 2002 @01:06PM (#4184502) Homepage

    Jabber Central [jabbercentral.org] (more pratical information on jabber)
    Jabber Powered [jabberpowered.org] (an initiative to create products based on Jabber)
    Jabber Studio [jabberstudio.org] (the development hub of the Jabber community)
    Old Jabber documentation [jabber.org]
    Jabber FAQ [jabber.org]
    A nice overview of Jabber [pipetree.com]
    Jogger (a jabber based weblog) [jabber.org]
    Jabber Python module [sourceforge.net]
    Unofficial Jabber user guide [saint-andre.com]
    Programming Perl [oreilly.com](an O'Reilly book)

  • Fantastic (Score:4, Informative)

    by ghazban ( 28784 ) on Monday September 02, 2002 @01:09PM (#4184517) Homepage
    For those of you who want to try out jabber, psi [sourceforge.net] 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.
    • The only issues I've have with PSI are general problems locating stable transport servers. there is a website out there which I can't recall right now that lists a few, but they're all overloaded:(

      but then again, that's not exactly a psi issue.

      psi rocks.
      • 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 (Score:5, Interesting)

      by FattMattP ( 86246 ) on Monday September 02, 2002 @02:47PM (#4184888) Homepage
      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.

      • 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.
    • Yes i use PSI. I have noticed that many servers will kick you fast unless you use the ssl connection. Its yet another problem to convince my dumb friends that insist on using m$ messenger. (Because the encription stuff does not come bundled, needs separate download, etc...)

      I wish they started charging access for passport once and for all, it would ease things. Oh and AOL could charge for their AIM/ICQ services as well, and yahoo.
  • Jabber, fantastic technology that it is, really should be made standard. For too long, Instant Messaging has been in corporate pockets and completely useless.

    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.

    Now, I would never really say this, but... "w00t w00t!". Okay, I'll come quietly...
    • 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).

  • Sometimes a little conformity isn't all that bad.
  • by pippo_67 ( 187509 ) on Monday September 02, 2002 @01:35PM (#4184609)
    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 [jabber.com] and , and windows [tipic.com].

    Clients are available for any platform [jabbercentral.com].

    You can choose your preferred server or client and they will work with each other!!
    • The fact that there are so many clients, none of which is polished, is jabber's biggest weakness.

      All the jabber clients are shamed by trillian, in my opinion. As I said in another post, someone needs to make a Jabber plugin for Trillian 1.0, I think that would do a lot to get people in the real world using Jabber. (assuming that's what we want....it is, isn't it?)
      • 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 [affinix.com]. 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.

  • 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.....?
    • [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.
      • >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 [nwfusion.com] 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.......? (Score:3, Insightful)

          by Zeinfeld ( 263942 )
          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.

    • 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.......? (Score:5, Insightful)

      by Zeinfeld ( 263942 ) on Monday September 02, 2002 @02:53PM (#4184913) Homepage
      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.

  • by jilles ( 20976 ) on Monday September 02, 2002 @01:53PM (#4184668) Homepage
    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.
    • by stpeter ( 112130 ) <stpeter@jabber.org> on Monday September 02, 2002 @01:56PM (#4184677) Homepage
      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.
    • Check out JabberView [jabberview.com] for a list of public servers, most of which have been online for more than two years.

      Most clients have default entries for the server (jabber.org in many Windows/Linux clients, or even the server run by the client developers).
    • 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..

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


        But ISP's don't provide a Jabber server. And why should you expect them to? Email is different, it was well entrenched long before the internet had mass appeal. Not so with Jabber.

        And the free mail clients aren't really "email servers", as they don't support email clients (POP, etc). So its a pretty different situation. Jabber folks have a lot of work to do if they want Jabber to gain the acceptance level of email....assuming that "Jabber is just like email, so it will gain the same acceptance" is incredibly naive.
    • I invite you to log in to the jdev conference room on jabber.org and hang out for a while. I am afraid that you didn't "get the full scoop." Although it is advantageous to have your own server, it isn't necessary. I have participated for months now w/o my own server. While logged into a public server, I have chatted with family and friends who are logged into AOL or MSN. My profile and "Buddy List" are safe and sound. Although it is posted that there are no guarantees, I haven't had a problem in all these months. What guarantees do MSN and AOL provide regarding their messaging? I haven't seen anything. If something went wrong what would they do?
      • 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).
    • 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 [rhymbox.com], 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.

    • Well another weak spot is the implementation. When I used Jabber (a year ago), the server daemon crashed all the time, and was a real pain to configure. The integration with ICQ and other chat systems was very crappy (e.g. file transfers didn't work, etc.). The clients were crappy, too.

      Right now I'm using Trillian [trillian.cc], but that won't help people w/Linux desktops. Maybe things have changed, but last I checked Jabber is one of those great concepts whose implementation doesn't do it justice. Heh, kind of like Java.
    • 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....)
  • by cullenfluffyjennings ( 138377 ) <c.jennings@ieee.org> on Monday September 02, 2002 @02:07PM (#4184715) Homepage
    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
    • 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).

      • I'm not worried that they own the trademark that is fine. I did not say they own IPR on the protocol - I said they owned IPR on things that you will need to implement a server. If someone can point me to a document to the contrary I will stand corrected - I have asked people at Jabber this and I certainly did get the "there is no IPR answer". However, I encourage you to look carefully at this.

        Cullen
        • Hmm, let's see, there's no IPR on the protocol, since it is totally free. And essentially it's nothing more than a protocol for streaming XML over TCP sockets. So in order to implement a server it looks like you'll need to perform socket I/O and parse some XML. Wow, I sure hope Jabber Inc. doesn't have IPR on TCP sockets and XML parsers! And it doesn't, which is why there are both free/open and proprietary Jabber servers for *nix (including OS X) and Windows, Jabber clients for everything from *nix to cell phones, Jabber libraries for Perl, Python, Java, C++, Ruby, and so on, and a thriving ecosystem of open-source projects that are using the Jabber protocol, including DotGNU. That's an awful lot of activity for a community that from your post sounds like it should be stifled by IPR enforcement. 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". Yet here you're asking for a document that clearly specifies the non-existence of any such IPR. Sorry, logic shows that one cannot prove a negative. The onus of proof is on you.
          • 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 [jabber.org] 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.

            • chefmonkey! I'm so glad to see you back in the FUD seat. I remember an earlier thread [slashdot.org] by you in which you FUD'ed about Jabber. I imagine you were one of the people mentioned in Pete Resnick's summary [jabber.org] as somebody who was voiced "opposition to this work was based on fear of taking in an outside (non-IETF originated) effort or on allowing competition to existing efforts." In fact, your support of SIMPLE on the basis that it had commercial support AOL is obviously pointless now.
              It is interesting to note that the Jabber.com open source license [jabber.org] 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.
              Jabber, Inc. does not provide an open source implementation of the server. And if you are referring to the server software provided by Jabber.org, it is currently dual licensed under both JOSL and GPL. In fact, the next version of the software (which is basically a complete rewrite) will probably be licensed under GPL only. The only code that Jabber, Inc. releases under the JOSL has been written in house, and are generally libraries developed in order to speed development for Jabber-related projects... if you're worried about license issues, you can simply choose not to use them. AFAIK, the only server-side component that has been released by Jabber, Inc. into open source was developed in-house, and iss the Server Connection Manager (SCM) which uses a protocol that is documented in the protocol specifications [jabber.org]. And just to wave my Jabber flag a little higher, here's one last quote from Pete Resnick's summary of the BOF [jabber.org]:
              In summary, I think there are enough people willing to work on this in the IETF, that it is of sufficient technical merit, and that people seem willing to implement and use the protocol, that I would recommend the IESG consider this as a working group. I think the room being stuffed with folks opposed to this work on political grounds does nothing to change that opinion.
              Maybe you should have ended your last post with the line, "Not very comforting, from a SIMPLE perspective."
            • OK, chefmonkey and I talked out-of-band about this (at least I assume it was chefmonkey, since the private email I received contained the same text as the message posted here, predated by a few hours). As both Joe Hildebrand (Jabber Inc. Chief Architect) and I explained, Jabber Inc. holds copyright on the code it has written (who wouldn't copyright their own code?). Jabber Inc. does not hold patents on implementations of the Jabber protocol, it has not applied for such patents, it does not intend to apply for such patents, and even if it or some other entity wanted to apply for such patents, they would not be granted because the open-source jabberd server and various Jabber clients would certainly be counted as prior art. Ergo the concerns raised about Jabber Inc. or some other company squelching development of open-source or commercial code compliant with the Jabber protocol are entirely without foundation. So take a deep breath, relax, and enjoy the Jabber goodness already. :)
      • 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 [ietf.org]: "[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.

        • A simple misunderstanding. Jabber Inc. does not (and almost certainly never will) hold patents related to Jabber. However it does assert copyright over its own code. When Joe said "IPR" he meant copyright, but others took that to mean patents. So one more time, y'all sing along with the chorus: "There are no Jabber patents!"
    • 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 [jabber.org]. 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.
    • 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.

      • 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.)
        • 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.)

          And this would be different from libsocket.a or netcat how? Besides the overhead of Jabber marshalling / unmarshalling, I mean.

          Honestly, I don't quite understand why everyone in today's world sees the need to layer extra protocols on top of raw TCP, and otherwise reinvent the wheel. For example - what exactly was wrong with ONC, DCE-RPC or CORBA that required SOAP or XML-RPC to be invented to fix?

          My pet theory on this is that some people feel the compulsion to invent an "application layer" just because their CS textbooks placed a misleading emphasis on the OSI model. (:

          • 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? ;)
            • 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.

              Nicely put, and sufficiently vague that it's hard to argue with.

              But what I'm really arguing here is exactly what the new abstraction layer abstracts away - does it simplify anything after all? Take Jabber. I assume (without knowing, so correct me if I'm wrong) that a Jabber-based client application will do something like

              • look up server name using jabber presence protocol thingy
              • build some sort of xml data structure
              • send said data structure to the server in an IM-like packet
              • maybe wait for response, or maybe not (Jabber is supposed to be asynchronous, after all)
              What I'm trying to figure out is how this is easier, more robust, or otherwise superior to
              • look up server name in DNS
              • build some sort of data structure, xml or otherwise
              • send a UDP packet to the server address, or possibly open a TCP connection and send the packet that way
              • wait on the TCP connection for a response, possibly xml structured, possibly not, or maybe just close the TCP connection if everything is supposed to be asynchronous
              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?
              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? ;)

              Actually the way I see it my question is more like "Assume you have Perl, Python and Java running everywhere. Now imagine someone invents a Java-like language named C$ and implements it in Perl. What would be the point?"

              Can anyone answer my (offtopic) side question: what does XML-RPC do better than DCE-RPC, DCOM or CORBA? Remember, "easier to implement" isn't much of an answer - those three have been widely available for many platforms (well, except DCOM) for years, so that's a solved problem.

              • 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?
                • 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).

                  Ahh, thanks - that clears it up a little. The more I think about the Jabber architecture, the more I like your comparison to e-mail. If you don't consider the store-and-forward capabilities, you have to admit Jabber looks a lot like a fancy proxy server, with 'ping' proxied as a presence protocol and regular Internet routing tunneled through the server-to-server protocol (does that have a name?).

                  Store-and-forward changes everything - it allows true asynchronous operation, if desired, and that in turn can foster a certain amount of anonymity. We already use email gateways for various things - I guess Jabber is a natural replacement which is better suited to applications as opposed to human communication.

                  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

                  *cough* Exchange *cough* (:

                  A standard protocol (eg SMTP in this case) simplifies things greatly -- heck, I can send email via telnet to port 25 if I want.

                  Indeed. Oh, and speaking of extensibility - don't forget that SMTP has in fact been extended in a backward compatible way, by ESMTP. And ESMTP has its own regular extension mechanism, likewise designed for graceful operation if client and server support different extensions. (I just wanted to point out that this sort of thing by no means requires anything like XML....)

    • 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.
      • Jabber servers are not primarily about store-and-forward (as is email), but about near-real-time delivery of an XML snippet to another network endpoint, which snippet you send because you know (via presence) that the intended recipient is online right now. So in Jabber you do have presence information. We also have a spec for message delivery notification (the spec is informational only at this point and is not part of the core Jabber spec -- see http://www.jabber.org/jeps/jep-0022.html). We also have the ability to track messages using IDs conversation threads or individual packets, so we can track messages. Jabber does *not* have guaranteed delivery since that would introduce serious latencies into the system and it's not a requirement for the main application built using the protocol. That doesn't mean we would never add guaranteed delivery to the protocol, just that we have not seen a requirement for that so far. In sum, Jabber is indeed asynchronous, which is good for its target usage but not necessarily good for other kinds of applications that people might want to build.
        • 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.

    • 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 ;)

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

    • I had some offline conversations with Joe Hildebrand, Tony, and Peter and they have put together some strong statements about IPR that show my previous worries about IPR and jabber are not an issue. Attached below are some very clear statements of their position.I am very happy they are taking this position on patents.

      Cullen Jennings



      Hi. I am the Vice President of Open Standards & Alliances for Jabber, Inc..
      In response to your message below and on behalf of the company, I will state
      that Jabber, Inc. neither has, nor claims any patent rights with respect to
      the XMPP protocol. Further, Jabber Inc. has no intent to claim any
      intellectual property rights with respect to the protocol that would limit
      in any way its free and open use. I hope this addresses your concerns. If
      you have any additional questions or issues, please feel free to contact me
      directly.

      Sincerely,

      Tony

      Tony Bamonti



      As Executive Director of the Jabber Software Foundation (JSF), I can state
      categorically that the JSF does not now hold any patents, that it has not
      applied for any patents, and that it never will apply for any patents. The
      JSF is a standards organization founded to manage the Jabber protocol. As
      soon as our new Board is installed (our annual meeting is being held one
      hour from now), we will finalize our IPR policy and include a statement
      about the fact that the JSF does not assert any IPR.

      Peter

      --
      Peter Saint-Andre

      • Hi Cullen,

        Thanks for posting these. We never realized that there was actually a concern, but now I can see how one might have taken Joe's statement at the BOF about IPR to refer to patents rather than copyrights. Section 10 (the IETF's IPR policy) does refer to copyrights, so my sense is that Joe wanted to be complete. The resulting confusion was certainly unintended. :)
  • so is JXTA.. (Score:1, Interesting)

    I would say that JXTA is alos close to securing its own working group fo standards inclusion..

    The major difference between Jabber and JXTA is that Jabber runs like a standard IM in that there is a centralized server..

    JXTa however does not use any central server.. its straight P2p decentralized..

    INfo:

    http://www.jabber.org

    http://www.jxta.org

    Now guess which one is imune from DMCA legal attacks? JXTA! Jabber deployment would stil get your compnay in hot water because they would go after the company that hosts the central server..

    • Which Internet-Drafts are you reading? Jabber in no way uses or requires a centralized server. The architecture of Jabber is the architecture of email -- is there one centralized email server? No. Anyone can run their own Jabber server, just as anyone can run their own Jabber server. This is in contrast to the legacy IM systems like AOL, MSN, and Yahoo, whose architecture just plain sucks if you want to create a secure, distributed service like email or IM the way it should be.
  • I looked through the Jabber.org FAQ and found a list of public servers.

    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 had thought of requiring people to set up a separate email account (finally, a use for those "get 5 POP accounts" ISPs) that would be used to distribute temporary dial-up IP numbers, etc.

    Looking at Jabber, using a few public Japper servers looks like a good alternative for syncing-up users when they come online.

    The question: has anyone else used public Jabber servers for something similar? (i.e., use the protocol and free servers for new uses)

    -Mark

    • 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 [sourceforge.net]. 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 [webcosy.com]. Lately I've been thinking that wrapping it all into a Jabber server (with extensions) makes more sense.

      OTOH maybe I missed your point.
      • Thanks for the links and comments.

        I just re-read my own post and it was unclear.

        The system that I have been thinking about is peer-to-peer and aimed at very small working groups so each client could maintain a socket connection with all other clients in the group.

        Since many people have temporary IP addresses (e.g., dialup access), there has to be a way to "sync-up", that is, let other people online know your temporary IP address.

        On Windows, I have played with groupware products like Groove, but I was thinking of something tailored to very small work groups.

        -Mark

  • Jabber on Trillian (Score:2, Interesting)

    by catbutt ( 469582 )
    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.

    • Gaim seems to support all the protocols you mention. The user interface could do with a little extra polishing, but it is good fun to be able to use all the protocols at the same time.
  • I hate these groups when many people talk their opinions about software. It always end up in slowing down the development. How hard can it be? Just install microsoft messenger and be happy. It has all those features you would need, except those that lame-ass ICQ patented.
    • Just install microsoft messenger and be happy. It has all those features you would need,

      Everything you need? What about the fact that the basic message service is the ONLY service that works if you are part of a NAT network. Which is becomming increasingly popular even at home since people want to share their cable/dsl and have two (or more) computers connected to the Internet.

      And no, "opening the ports" or "port forwarding" doesn't work. The IM protocol is flawed. You can receive files but not send, etc...
    • >Just install microsoft messenger and be happy.

      I tried and a big WINE debug box came up.

      Maybe you could help me get it running?

      I don't own a license to Microsoft Windows, nor do I want to pay $150 for an IM client, so unfortunately I won't be able to install it that way.

      Any ideas?
    • More than three people use MS Messenger?

"I have just one word for you, my boy...plastics." - from "The Graduate"

Working...