Massive polling for updates leads to scalability problems? Big surprise! We need to learn that HTTP is not always the best technology for the job. Just-in-time content delivery requires a different set of tools. There's already an Internet-Draft for sending Atom feeds over XMPP (a.k.a. Jabber), and the same "publish-subscribe" technology could be used for RSS (or a smart service could translate to Atom so your client doesn't need to parse all those RSS formats). Check out PubSub.com for a real-life implementation of the basic concept (they track 3+ million feeds and notify you when a feed you're interested in has changed, and even do handy keyword-based monitoring). And one added benefit of using the XMPP pubsub extension is that these are all open protocols with many open-source implementations. In this problem-space at least, HTTP is so second-millennium!
> Never mind the ACTUAL implementation of presence > and instant messaging that ALSO leverages this > infratstructure.
Except that there's no there there -- does anyone actually use SIMPLE for IM? 10+ million people are using Jabber/XMPP, which is just as "standard" as SIMPLE given that the IETF has approved the XMPP specifications.:-)
> Every time I hear about proprietary solutions > to VOIP (like Skype) or people going on about > Jabber I sort of shake my head and wonder why?
You're right regarding Skype, but people are "going on about Jabber" because it is an open standard with tons of open-source code behind it, which enables you do to lots more than IM (it's all just a streaming XML technology -- think SVG whiteboards, real-time RSS/ATOM feeds, and other forms of dynamic content).
As to VoIP, enabling most voice (and video) over the Net is just a question of how you get to RTP or some other bytestreaming technology (you certainly don't do the content exchange via SIP, only the negotiation). You could get there via SIP, via H.323, or via Jabber (expect protocols and implementations soon), but in the end you're just streaming some bytes. Who cares how you get there?
And let's not forget that sometimes people want to exchange text (IM, email, IRC, etc.) rather than voice or video. Personally I rather like having multiple channels going simultaneously -- voice is so single-channel that it makes multitasking hard.
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.:)
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!"
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 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.
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.
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.
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).
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.
Slashdot Mirror
Massive polling for updates leads to scalability problems? Big surprise! We need to learn that HTTP is not always the best technology for the job. Just-in-time content delivery requires a different set of tools. There's already an Internet-Draft for sending Atom feeds over XMPP (a.k.a. Jabber), and the same "publish-subscribe" technology could be used for RSS (or a smart service could translate to Atom so your client doesn't need to parse all those RSS formats). Check out PubSub.com for a real-life implementation of the basic concept (they track 3+ million feeds and notify you when a feed you're interested in has changed, and even do handy keyword-based monitoring). And one added benefit of using the XMPP pubsub extension is that these are all open protocols with many open-source implementations. In this problem-space at least, HTTP is so second-millennium!
> Never mind the ACTUAL implementation of presence
:-)
> and instant messaging that ALSO leverages this
> infratstructure.
Except that there's no there there -- does anyone actually use SIMPLE for IM? 10+ million people are using Jabber/XMPP, which is just as "standard" as SIMPLE given that the IETF has approved the XMPP specifications.
> Every time I hear about proprietary solutions
> to VOIP (like Skype) or people going on about
> Jabber I sort of shake my head and wonder why?
You're right regarding Skype, but people are "going on about Jabber" because it is an open standard with tons of open-source code behind it, which enables you do to lots more than IM (it's all just a streaming XML technology -- think SVG whiteboards, real-time RSS/ATOM feeds, and other forms of dynamic content).
As to VoIP, enabling most voice (and video) over the Net is just a question of how you get to RTP or some other bytestreaming technology (you certainly don't do the content exchange via SIP, only the negotiation). You could get there via SIP, via H.323, or via Jabber (expect protocols and implementations soon), but in the end you're just streaming some bytes. Who cares how you get there?
And let's not forget that sometimes people want to exchange text (IM, email, IRC, etc.) rather than voice or video. Personally I rather like having multiple channels going simultaneously -- voice is so single-channel that it makes multitasking hard.
It's obvious that "google" is short for "go ogle", no?
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.
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!"
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 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.
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.
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.
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).
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.
Ben Franklin actually said: "They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
The Jabber folks did submit an RFC -- it's here.
Peter Saint-Andre
Editor, Monadnock Review