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."
Links (Score:3, Informative)
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)
Re:Links (Score:1)
Re:Links (Score:2, Interesting)
karma whoring at its finest (Score:2, Funny)
Fantastic (Score:4, Informative)
I really do hope the jabber folks are able to make jabber a standard.
Re:Fantastic (Score:1)
but then again, that's not exactly a psi issue.
psi rocks.
Re:Fantastic (Score:2)
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)
Re:Fantastic (Score:2)
A little off-topic, but did anyone else notice this item on the PSI page?
Yup, and slashdot rejected the story last week:
- 2002-08-25 19:44:26 [name withheld] ripping off GPL code (articles,news) (rejected)
Name removed at Justin's (Psi developer) request -- he doesn't want hordes of angry people attacking the ass who did this...yet.Re:Fantastic (Score:1)
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.
Just what we need... (Score:1)
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...
Re:Just what we need... (Score:2)
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).
I've been saying this for years... (Score:1)
Jabber strength are the different implementations (Score:3, Informative)
Clients are available for any platform [jabbercentral.com].
You can choose your preferred server or client and they will work with each other!!
Re:Jabber strength are the different implementatio (Score:1)
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?)
Re:Jabber strength are the different implementatio (Score:2)
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.
Great.......? (Score:2)
Re:Great.......? (Score:2)
So does documenting your code... is that a bad thing too? Seriously though, IETF protocols once finalised tend to be very well thought out and have shown they can stand the test of time (look at SMTP, FTP, etc).
You can code as much as you like, the worst that can happen is that you will have to modify your code afterwards to fit in with the final standard (the library you use to talk the Jabber protocol will only make up a small percentage of your application code). My advice is code away, and once the final RFC is out it will give you a baseline of garaunteed interoperability with every other fellow client out there.
Phillip.
Re:Great.......? (Score:2)
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)
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.
Re:Great.......? (Score:2)
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)
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.
weak spot is the server (Score:4, Insightful)
Because of this, many people download a jabber client, figure out that they need a server and are told by the jabber faq that they might try this or that server without any guarantees that it will still work next week. Not very convincing.
For people to adopt jabber as an alternative to current propietary messaging clients, a reliable, available server that will host profiles for free is needed. As long as servers are lacking, jabber will remain an interesting technology that is mostly used in corporate intranets.
If a good public server was available, I would have been running jabber years ago.
Re:weak spot is the server (Score:4, Informative)
Re:weak spot is the server (Score:1)
Most clients have default entries for the server (jabber.org in many Windows/Linux clients, or even the server run by the client developers).
Re:weak spot is the server (Score:2)
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.
People tend to take the stuff they see at work and use it at home. Especially if their client at work can be used to talk to the outside..
Re:weak spot is the server (Score:1)
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.
Re:weak spot is the server (Score:1)
Re:weak spot is the server (Score:2)
ICQ, AOL and MSN are propietary networks, if they would go offline that would literally seriously piss off millions of their customers, that's a pretty good reason to assume that that is unlikely to happen (other than by accident).
Re:weak spot is the server (Score:2)
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.
Re:weak spot is the server (Score:1)
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.
Re:weak spot is the server (Score:2)
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....)
Jabber for what, and for who? (Score:4, Interesting)
One thing is that jabber was presented as a solution not for instant messaging (IM) or presence protocol (PP) but as a solution for asynchronous transfer of XML. Another BOF, XML Conf, was suggesting there was a requirement for this sort of stuff to provision routers and such.
Most people seemed to feel that Jabber had major issues from a security and privacy point of view for doing IMPP. Remember that the IETF did look at jabber a few years ago for doing IMPP and it was rejected. Since then, many protocols have been proposed. IM can send message in "page mode" where you are just sending a one time message or it can set up a whole session between the clients for cases where you are going to transfer many message back and forth. This second mode is called session mode. Right now the SIMPLE group more or less has a good proposal for page mode and setting up sessions but is debating how to transfer messages in session mode.
I believe that the following companies have said they will support SIMPLE: Microsoft, Yahoo, Lotus, etc. Unlike what the CNET article said, I was told that AOL filed documents with the FCC saying they would do SIMPLE.
If there is a IETF WG on jabber, which I believe might happen, the interesting thing will be to read what that groups chatter is to do - I bet it won't say that it is gong to developed a complete IMPP solution.
On a side note about how this effects open source development, I work with the vovida.org project which develops voice over IP and messaging open source software. We have talked to the jabber.org and jabber.com multiple times. It's always been difficult to figure out how this all fits together from an open source point of view. You see, jabber.com has patents on stuff you need to implement jabber. At the Jabber BOF at IETF I specifically asked them if they would make this IPR available in a way that worked for open source people. They answered that people had implements this stuff and they weren't suing them. This is like yah, DUH, of course when we are trying to get people addicted to the drug we don't sue them. They have NEVER made any commitment to allow this IPR to be used in open source products. They are a desperate company looking for a way to make a business model out of jabber. If you think jabber is the best for open source - give that some careful thought.
Cullen
Re:Jabber for what, and for who? (Score:2, Insightful)
Re:Jabber for what, and for who? (Score:1)
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
Re:Jabber for what, and for who? (Score:1)
Re:Jabber for what, and for who? (Score:2)
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.
Re:Jabber for what, and for who? (Score:1)
Re:Jabber for what, and for who? (Score:1)
Re:Jabber for what, and for who? (Score:2)
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.
Re:Jabber for what, and for who? (Score:1)
Re:Jabber for what, and for who? (Score:3, Informative)
As to their commitment to the open source community they have people such as myself and stpeter on their payroll that really only work on open source projects and tools. Neither of us have worked on any of the commercial projects in quite a long time.
Re:Jabber for what, and for who? (Score:2)
Anyway, this makes for easier programming of services that would, if based on HTTP ("web services"), require the usual sorts of messing with session ids and cookies or URL-encoding to work properly. Jabber can be viewed as a high-level transport protocol; it's easy enough to wrap it around whatever data you want transported, especially since it's XML based. Don't forget, the "user" at the other end of that Jabber session doesn't have to be a human at a keyboard, it can be a process. (Okay, the three cool things about Jabber...) Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client" for certain classes of application.
Re:Jabber for what, and for who? (Score:2)
Actually for command-line type apps you don't even need the HTML renderer. You just plug stdout and stdin into some sort of adapter process that converts them to/from Jabber send and receive streams (something like how inetd fires up server processes with stdin and stdout pointing at the socket connection.)
There's probably something like that already out there, I haven't looked. (It'd be pretty easy to write.)
Re:Jabber for what, and for who? (Score:1)
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. (:
Re:Jabber for what, and for who? (Score:2)
If you're piecing something together from pre-existing parts or there's a good possibility that the use of the system will extend beyond the bounds you have direct control over, then it helps to have a few adapters and higher level protocols in the toolkit. It may also be that those higher-level toolkits have a level of robustness and ease-of-use beyond what hand-rolling your own to a lower level might have.
But you may have a point. Why do people see the need to layer extra levels of abstraction on top of raw machine code? What was wrong with assembler, Fortran and C that required Python, Perl or Java to fix?
Re:Jabber for what, and for who? (Score:1)
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?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.
Re:Jabber for what, and for who? (Score:3, Informative)
[jabber steps omitted]
What I'm trying to figure out is how this is easier, more robust, or otherwise superior to
[tcp socket steps omitted]
It looks to me like pretty much the same set of steps. I'm honestly confused about what the Jabber layer adds, other than xml buzzword compliance. Anyone?
The XML buzzword compliance is actually pretty significant -- not so much for the message content (as you point out, you can send XML with plain old TCP), as for the wrapper. Routing of TCP packets is done at a level way below what most applications can or want to handle; routing of Jabber's XML packets is handled at the application level, and there are standard ways to tell Jabber "routers" (servers) where (what user or service) the packet is to go to. Further, Jabber messages can be stored and forwarded if the destination address isn't currently available. (More like email in this sense).
I think that may be the step you're missing -- the point of Jabber isn't for the client to talk to the server, it's to route through the server to another client (or group of clients).
Because it's XML-based, it is extensible in well-understood ways that any given Jabber-enabled program can safely ignore if it doesn't understand the extension. (But a human might be able to figure out by inspection.)
Protocols are about making it easy for different developers to create programs that will cooperate with each other. Sure, you could create an email system (for example) that used raw RPC calls between client and server, but nobody else would be able to talk to it, at least not without using that same RPC API, which constrains the design. A standard protocol (eg SMTP in this case) simplifies things greatly -- heck, I can send email via telnet to port 25 if I want.
Beyond that (eg your questions about why XML-RPC), well, sure, some of it is just fad or using what tools you already know vs learning a new one. (The "if all you have is a hammer, every problem looks like a nail" syndrome.) On the other hand I've seen pretty fair arguments that XML is just an exotic dialect of LISP, so why not?
Re:Jabber for what, and for who? (Score:1)
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.
*cough* Exchange *cough* (:
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....)
Re:Jabber for what, and for who? (Score:2)
A store-and-forward network, in other words. That's great, but to actually add value over email you need to know whether the other party is there, whether they've read your message etc.
These are examples of what workflow people call 'process state' information and, perhaps surprisingly, this requires synchronous communication to track. "Messaging" products are always sold as providing a completely asynchronous solution, then awkward details such as guaranteed delivery, resend requests and process state queries raise their heads and suddenly the wonderful asynchronous model needs supplementing with good old RPC again.
Jabber protocols should all be implemented as synchronous and RPC-like at the detail level - any "asynchrony" will emerge from the use of store-and-forward queues, which each party will interact with using simple RPC.
I assume that Jabber isn't already like this because XML-RPC is identified as an extension to the basic protocol rather than the other way around, but feel free to enlighten me.
Re:Jabber for what, and for who? (Score:1)
Re:Jabber for what, and for who? (Score:2)
Now having developed message delivery and tracking mechanisms, it seems a trifle defeatist to deny that you have invented a guaranteed delivery system. Somebody somewhere is recording what each party has received, and ultimately this information can be accessed by a client interested in finding this out.
Latency is a consequence of tracking the state of a distributed system in any form. The good news is that there are plenty of interesting design choices that can be made to minimize it, and I suggest that this is where the Jabber designers should concentrate their efforts.
Re:Jabber for what, and for who? (Score:2)
As far as I know, this is just FUD. I've been tracking Jabber since the cows came home, as has Adam, and neither of us has heard anything about any trouble from (enforceable) patents on Jabber.
Having said that, it's probably true. Bear in mind any non trivial program will have patents on it within the US. There are hundreds of patents that affect Linux for instance. What can these companies say, except we won't use them?
Finally, Jabber Inc does have a business model. They sell industrial strength commercial servers and support. This does make money. The question is, will they make enough money to survive.
Unfortunately, J inc has sort of lost its way lately. Andre Durand who set it up has left, and it was taken over by his former bosses who didn't really have much of a business before. The company has been going downhill since then.... I hope they do survive, but it's not the company it once was. Oh, and a quick disclaimer : I now work for Andre, on an unrelated project ;)
Re:Jabber for what, and for who? (Score:2)
I'm not familiar with that stage of the company's history or who exactly you mean, but if you mean the likes of the current Chairman and/or CEO -- well, it has been some years since I worked with them at GeoVision, but as far as, say, Perry goes, I wouldn't call MapQuest "not much of a business".
If you have something specific to say then say it: vague negative statements about one's former employer may leave an impression you didn't intend. But at least you posted the disclaimer.
Re:Jabber for what, and for who? (Score:2)
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.
IPR Clarification (Score:1)
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
Re:IPR Clarification (Score:1)
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)
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..
Re:so is JXTA.. (Score:1)
Q: public servers, experimental groupware systems (Score:1)
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
Re:Q: public servers, experimental groupware syste (Score:2)
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.
Re:Q: public servers, experimental groupware syste (Score:1)
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)
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 has everything (Score:1)
I hate these groups (Score:1)
Re:I hate these groups (Score:1)
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...
Re:I hate these groups (Score:1)
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?
Re:I hate these groups (Score:2)
Re:Well.. (Score:3, Informative)
If you use AIM, ICQ, Y!M, or MSN Messenger (or any combination thereof), you can connect to them with Jabber.
It's great if you have, say, family members on AIM, friends on ICQ, and co-workers on MSN.
It also has its own, internal protocol.
However, AIM and Jabber have a history of not working together all that well...so if you have to have AIM connectivity in your IM client, I'd go with Trillian [trillian.cc] if you use Windows, IMCI [imici.com] for Linux or FreeBSD, or Fire [epicware.com] if you use OS X (which doesn't support MSN...but if you're on a Mac, you probably don't need it anyway).
Re:Well.. (Score:2, Informative)
Re:Well.. (Score:2)
Fire is a decent IM client, but if one is using Mac OS X, I would strongly suggest using Proteus [indigofield.com] instead (which, for what it's worth, does support MSN).
I also wonder why you say just because somebody uses a Mac they probably don't need MSN. Unfortunately, MSN is used by SO many people these days that, at least for me, it's been practically impossible to know a large group of friends and not have a significant number of them only on MSN.
- j
Re:Well.. (Score:2)
Re:Well.. (Score:1)
Yes, actually it does. I'm using it right now. I find, however, that the yahoo service usually flat-out doesn't work.
Explanation (Score:2)
The ability to log on with only one username/pass and have all contacts on all of your networks be contacted through a consistant interface alone is worth trying jabber out. I recommend psi [sourceforge.net] as a good starting client, however you can find many other clients on jabbercentral [jabbercentral.org].
jmrjmrjmr == Troll (Score:1, Offtopic)
Re:Well.. (Score:5, Informative)
However, here are the reasons you want it:
XML: Now I'm sure by the time this is posted, there will be tons of "XML is the future, adopt it and DESPAIR" posts, but in this case, it is a clear benefit. Bascially, due to XML, the message format allows trivial extension of the protocol. Really, you can just make up an XML element, stick it in the right place and *poof*.
"Is it really this trivial?", you ask. Well, one of my pet projects was writing a Jabber bot for pen/paper RPGs (think Dungeons and Dragons). It took about six hours and I added a element (use the sides property to specify type of dice) that would message you back with a dice roll. I never completely finished the client, but it worked.
Keep in mind all I did to do this was hack two copies of the command-line client--no server changes whatsoever. The key here is that any Jabber server will pass custom XML--so protocol content changes *DO NOT* require server changes and are completely client implementable. Freedom for the masses, anyone?
The possibility of custom clients is huge. Unfortunately, the ability for large companies (AOL, MSFT) to control the state-of-the-art and to make sure that, despite interacting with all IM clients, theirs offers better proprietary functionality on their network (i.e. everyone can message, but AOL partnered with newgame.com so only AOL users can use IM to launch NewGame netgames).
Transparency: This is a big win. It is always possible to pull apart the protocol. Heck, the protocol is designed to be human-readable. This has the added benefit of making obfuscation really obvious (why is AOL using elements named option1, option2, and option3? What is the nsakey element for?
OpenSource: You read Slashdot, you know the pros and cons. The less obvious side of this is how it compares to the corporate offerings--specifically SIP. SIP is great, but try to find a free implementation. If you're using SIP for VoIP (which is pretty much the norm) you probably have had to drop a chunk of change on a nasty Cisco CallManager server.
Loosely Connected: Perhaps the most intelligent Jabber decision was to make it just like e-mail. There's no longer a global hostname, but rather a user@host naming scheme. If you're Internet savvy you can get your e-mail address and jabber address to be the same (exercise left to the reader, think about it).
Existing Gateways: Jabber's weirdest appeal is that it already has gateways to access existing services. The docs have the specifics, but the gateways servers can hit AOL and about everybody else.
Good Standards: Practically all of the corporate offerings are standards that were thrown together (Mirabilis ICQ grew like a Frankenstein's monster, see the procotol specs, they're scary http://www.d.kth.se/~d95-mih/icq/). A ground-up thoughtful implementation like Jabber is a Good Thing(TM) compared to some of the messes.
There are other reasons but I'm tired of typing. You get the idea--Jabber stays crunchy in milk. It's nummy. Get some.
Re:Well.. (Score:1)
Correct, however, the current version is described here [uni-karlsruhe.de]. And add to this the necessarity to have different versions of the same protocol, you really have a huge mess.
Re:Well.. (Score:1)
Re:Well.. (Score:1)
The vovida.org stuff appears to be good code. My only beef is that vendors threaten me when I try to use stuff like this. We're considering taking a vendor to court right. They won't support their own keyset units because we have an Asterisk PBX between their phone system and the CO.
As you can imagine, I hesitate to do anything but buy a Cisco controller after this nightmare. The legal fees alone make it worth it.
That being said, I hadn't seen this before. Thank you Cisco.
-K
Re:Well.. (Score:1)
Correct, however, the current version is described here [uni-karlsruhe.de]. And add to this the necessarity to have different versions of the same protocol, you really have a huge mess.
Did I ever mention that SlashCode sucks?
Re:Well.. (Score:1)
Well, not if you want to keep your current email address and you don't happen to own the domain.
If they had been really smart, they could have figured out a way to have any email address be your Jabber id....all it has to be is unique (which email addresses are). There would have to be some sort of directory system or something. But Jabber people are smart, right? They can figure that out.
The benefits would be immense, in my opinion.
Expecting people to be "internet savvy" to the degree that Jabber folks seem to expect, is a huge weakness for Jabber, IMO.
Re:Well.. (Score:1)
Any identification system needs to be clear. If your e-mail is bob@asdf.com, you can be sure that if your ISP doesn't support Jabber, at least it won't be anyone else impersonating you. Thus the onus is on the ISP, not the protocol, for problems that might arise. If ISPs are responsible for delivering your e-mail, I don't see it to be a big step for IM traffic (and the routing is a heck of a lot more distributed).
If your ISP doesn't support IMs (a few actually blocked ICQ for a while), I don't see it to be any worse than not supporting e-mail. Both are a service to your customer that require modest (per user) computing and bandwidth requirements.
Re:Well.. (Score:1)
Any reasonable directory would verify email addresses.
Re:Well.. (Score:2)
microsoft.com's jabber server (as designated by the relevent DNS SVC records) would have to allow them to do that.
Registration @ a particular domain is controlled by the jabber server(s) for that domain. Like email.
Most Jabber servers right now allow open registration, but there's no requirement that they do. And anyway, I don't think microsoft.com is operating a jabber server yet.
Re:Well.. (Score:1)
Speaking of which, does Jabber support the use of DNS service records? I thought it just used standard DNS hostnames, which kind of sucks (makes it harder to use @example.com as Jabber address). A quick read through the FAQ on jabber.org makes a few quick mentions of DNS but nothing fancy like SRV records.
Re:Well.. (Score:2)
Well, his signed messages won't match up an he won't be able to decrypt anything from the PGP pubkey, which you *should* be using...
Re:Well.. (Score:1)