Slashdot Mirror
IETF Approves XMPP Core as Proposed Standard
hystrix writes "As long expected, the IESG has approved the Extensible Messaging and Presence Protocol (XMPP): Core (draft-ietf-xmpp-core-22.txt) as a Proposed Standard. For those of you in the dark, thats the protocol behind the only tried and proven open IM platform, Jabber. Congrats to the hard working Peter Saint-Andre, and the entire XMPP Working Group."
...to send Cougaar society status messages around - we've been able to get around 1100 messages (albeit simple ones) per second.
We're using the Ruby wrapper Jabber4R as well as various GUI clients, and we're using the Jabber 1.4.2 server.
The Army reading list
I think this is a good thing, but it all depends on who implements it.. If all the major IM "brands" continue to use their own standard, then whats the point?... If they were inter-operable, then there would need to be other key selling points (what?.. selling points for free IM??) bah.. early morning spout-offs
This is nice... At last we have a standard IM protocol.
However, unless the major player in IM implements the protocol, this standard importance is not very high.
That would change if someone develop a killer app that make use of the protocol, but for IM the way it's done now, we need at least one of the major player to implement the protocol... At that is not likely in a near future.
since e-mail & IM are going to blurr over each other in the future, how about extending this standard to a free, open mailbox standard for email clients? Aren't we *all* sick of every email program using a different, incompatible mailbox format? I still use Netscape 4 for my email because I can't move my mailbox archive over to any newer application that is decent to use.
this is better than IRC, it's standard is still marked experimental :)
don't forget to patent that before Microsoft does.
Good stuff
So how to integrate. Continue working with Jabber libraries, or will these be obviated with XMPP API's and libraries?
Oh, and now that we have a standard, how will this standard hold up againt various patent issues and claims?
--- have you healed your church website?
Just because it's going to be a standard, that doesn't mean it'll become THE standard. IM, etc. would need to adopt it.
Anyway, I'm still wainting for Linksys to make a home router/hub for RFC1149 (IP Datagrams on Avian Carriers)
--
Fortunately Proposed Standard doesn't actually mean that much. As an FYI MIME (multipurpose Internet Mail extenstions) is still a draft standard even though it is widely implemented.
Likewise both S/MIME and OpenPGP have progressed. Eventually sanity will prevail and SIPPING will be "blessed".
There is SSL available, I use it when I'm using public computers on Jabber.
Extensible. Now there's a verb Microsoft loves. They'll extensible this to death now that everyone else thinks it's a standard.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
In the end, we'll still end up with companies (e.g. Microsoft and AOL) who will still continue with their closed/proprietary formats; if they do adopt an open standard, they will try to make it different so it ends up being incompatible, or patent it so no one else can use it. And lets not even get into the ills of what Microsoft did for HTML Scripting... eck.
So, yay, we have a standard. But can we get everyone to implement it PROPERLY?
I'm off to swap some illegally acquired content on XMPPster.
Er, how do you pronounce that again?
These sigs are more interesting tha
a very simple design - uses just a subset of XML (no comments, macros, DTDs)
good error recovery
good service discovery
not tied to any vendor or language
not domain specific
bidirectional asynchronous communication - an XMPP session is just a pair of XML documents (one going in each direction).
decent speed
I see XMPP being as big as HTTP in the future. It will be the standard for interactive distributed communications.
Jabber didn't make it and won't make it for a long time, if ever. There are still problems and lack of voice and video chat (they are not even a part of the standard). Voice/Video can be handled by numerous other standards ... but the problem is that there are too many of them and neither is OSS. It may have a niche in small/medium private chat networks. Its price is right, but it lacks a lot of conveniences other IM protocols have to offer.
The most important factor is that IM standard/service only matter (in the larger picture) if enough people use it. I don't have a single friend or aquantance who use Jabber, most use either MSN, AIM/ICQ or Yahoo. AIM/ICQ, perhaps, has the best chance of becoming a "standard" ... although I hate both. MSN ... is MSN ... enough said. Yahoo is the most balanced IMHO.
This is just further proof that the OS community can right good, solid, secure code. Pooring lots of money at a problem just makes prices higher, and a few high level management people richer. It's just adding overhead to the problem. OS can right good solid secure code. If only Microsoft could....
Not codes, standards.
Jabberd1.4.x is um...well, don't get me wrong, I LOVE jabber, I have it setup at several different places and all that, but jabberd1.4.x sucks rocks. 2.0 is better, and has better features, but written by the same folks, so while I use it because I need it, I'm always keeping a wary eye out for it doing silly things.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
A) More bloated than a binary format
I know very little about XML, but couldn't you compress it up in some way (like you would zip up a file)?
If you can, then this would mean you can eliminate one of the big disadvantages of XML.
Avantslash - View Slashdot cleanly on your mobile phone.
This is great news. People need to list as a requirement for clients and servers XMPP compliance.
Everyone who uses iChat, stop what you are doing and go fill out a bug request form on Apple's developer site (http://developer.apple.com).
I'm going to go fill my request right now.
While you're at it, maybe you should request that they open a protocol plugin api to developers.
-Peter
. Penguins Surely Ca
the first IETF IM standard to make it through the process was the CPIM package (draft-ietf-impp-cpim-msgfmt). It's a specification on how to interconnect IM systems rather than a complete IM protocol specification.
The other major player in IETF standards-space is SIMPLE - the presence specification documents for that (draft-ietf-simple-presence) are in the RFC Editor's queue.
The nice thing about standards is that there are so many of them.....
Not if you compress the data before sending it, and even if it was, who cares? It's not like IM chat streams are going to take a significant amount of bandwidth, no matter what format the use.
B) Harder to parse & hence less efficient that a binary format
How is downloading and calling the parse() method of any of several dozen free XML parsers "harder" than having to write and debug your own custom portable parser for a binary format? As for less efficient, probably -- but for modern processors and IM-style applications, the advantages of being easily cross-platform compatible and transparently extensible outweigh the extra CPU usage, which nobody will ever notice anyway.
C) Much easier to casually snoop on
If you think relying on obfuscated data formats is the best way to prevent snooping, you are in for some unpleasant surprises. If you are worried about snooping, you should tunnel your data over SSL, not pretend that having a hard-to-use data format is going to stop anybody from snooping.
Face it , XML is flavour of the month and trendy , it has zero advantages over formats
Face it, you are trying to criticize something based on the wrong criteria. XML was developed to solve a certain set of problems, and it solves those problems well. If you don't like it, then by all means don't use it, but don't think that means it's not useful to other people.
I don't care if it's 90,000 hectares. That lake was not my doing.
Even with XMPP I don't think, in the short term, you'll be able to get away with only one IM account (such as AIM) and be able to talk to your buddy on Yahoo!. But as software like Gaim and Trillian move toward XMPP and people use Gaim and Trillian more and more, the independant services AIM, Yahoo! MSN, ICQ, will have to move to XMPP or risk being left in the dust (because once people are using XMPP and Gaim/Trillian, they don't really need AIM or Yahoo! servers to communicate.
...and that's the way the cookie crumbles.
Few months ago, I tried to run jabber in the company where I work, because we have offices in different parts of Europe and the communication is sometimes too slow. The interesting feature of jabber is that one can run his own server, so that the secret communication doesn't go anywhere outside a firm like with ICQ. We have linux RH7.3 and (mostly) Win2000 desktops, so I installed gabber resp. exodus. But all the jabber software turned out to be quite unuseable. Exodus was very unstable. Gabber didn't want to dock on my gnome panel. To configure the jabberd was also quite a pain. Actually, after my experience with IRC and ICQ I find a panel applet to be the most important part of the IM. If one finds a message always 2 hours after arriwal, it has no point to use IM :( ICQ is quite a good in this respect.
I got to the point that we exchanged two messages with a coleague in the same office. Then I decided that it is not worth of the effort. Neither the windows nor the linux client are mature enough to be convenient to use. Well, in my job, I can play half a day with something like that, but not much more ;)
But maybe somebody has a different experience. Is there somebody who really uses jabber in real word for a real communication with real people? With at least basic functionality (= arrival of a message makes a change on panel) in both linux and windows?
...because less than a decade later the same folks (AOL and MSN, for two) who had the lesson smashed in their face in the mid 90's are trying to stick with the exact same mistake.
Back then, there were fiefdoms of online access and email, all kind of piddling along. They began getting a clue, first with email bridges to the Internet, and saw their business start to take off. They then got into the business of making their bridges better, and so did their business. Eventually they quit being Online Service Providers and became Internet Access Providers.
In the mainstream press, it was eventually stated that people wanted to go online to communicate with each other. Services that helped that, thrived. Services that hindered, withered.
What is IM but communication?
But IM providers are still in this stupid gatekeeper role. Perhaps one of the WORST things that Microsoft has done is to teach us all that the most successful business model is to become a gatekeeper or tax collector. IMHO a large part of the IM protocol mess is that businesses are paying more attention to the Microsoft model than to the Internet model.
The living have better things to do than to continue hating the dead.
Perhaps, but you're using entirely the wrong criteria to determine efficiency. If our primary goal is creating proprietary data structures, then it might be more efficient to do it your way. If our primary goal is communication - i.e., broad usefulness of data structures in multiple application domains and types - XML is *far more efficient*. And at execution time, there's little penalty, because the XML data can be parsed into your C struct with little effort, and juggled entirely within that context until sucha time as you feel the need to send the data to hard drive or other application.
ROFLMAO!!! You just don't get it, do you? The point the previous poster was making may have escaped you, so I'll try and express it in simpler terms. Regardless of the format you use, if you don't take action to secure data (i.e., encryption) you might as well be posting it on a bulletin board - even if your protocol is binary; the conversion is trivial.
Just in case you didn't catch this, AIM uses HTML; yahoo may, as well, I haven't looked at yahoo messages on-the-wire. XML isn't offered as a 'secure transmission method', but a nearly-universal data-description and encoding format that allows data translation to be much more efficient than the 'efficient' binary data structures you're touting.
LOL!!! Perhaps you'd like to educate us on what domain of problems XML is designed to resolve and why this particular application falls outside that domain? In fact, this would be a classic case for XML - interoperable data description and encapsulation. What works for data files also works for data exchange, and stream compression eliminates the 'data set size' advantage of your C structs.
Thinking outside my Head
Isn't the art of good coding to make things as efficient as possible?
No, with today's CPUs, the art of good coding is primarily to make things as maintainable as possible, with the exception of very specific problem sets, of which chat is not one.
With a binary format the data can usually in whole or part be mapped direct onto a C structure. In other words the parsing is down for you in a few lines and uses up bugger all CPU.
Um, no. Binary data across a wire can never map directly on to a struct due to endianness differences on the CPU, and even due to differences in how the compiler chooses to pack the struct. Unless both sides are using the same processor and using identical C compilers (down to the version number), all bets are off.
Plus, clients written in one of the thousands of languages that are not-C still wouldn't benefit.
I said CASUAL snooping. If someone can just run tcpdump on a LAN they can read all the correspondance going on. If they have to figure out the protocol they'll probably not bother unless they have malicious intent.
Even if the protocol was binary, the main payload will still be ASCII, which casual snoopers can still read. You could compress or encrypt the protocol, but then you can compress or encrypt the XML protocol as well.
Yes it was, but being a high level network protocol was NOT one of them.
Funny, none of the most commonly used high level network protocols (HTTP, SMTP) use binary protocols.
Isn't the art of good coding to make things as efficient as possible?
:). For IM, using a binary protocol would be pointless.
No! Nonononononono!
Efficiency of your code only matters when you specifically need your code to be efficient. In the case of IM, that simply isn't the case.
Efficient code counts for nothing if the overall structure is not clean and well thought out, especially when it comes to standard formats, or libraries.
Any good programmer will know this.
With a binary format the data can usually in whole or part be mapped direct onto a C structure. In other words the parsing is down for you in a few lines and uses up bugger all CPU.
The advantages of this do not outweight the disadvantages. Sure, you may get your IM application constructing and destructing messages at times under 1ms, but when it's going to take 200ms or so for the messages to arrive, who cares? The speed that binary protocols would give mean nothing outside absolute real-time environments (such as networked Quake III
Binary data is far, far harder to extend, and it would also be harder for the programmer to make a parsing algorithm. Since it's XML, he can just use a library to do the work for him. This makes the code modular, simpler, easier to maintain, and less prone to error.
I said CASUAL snooping. If someone can just run tcpdump on a LAN they can read all the correspondance going on. If they have to figure out the protocol they'll probably not bother unless they have malicious intent.
Security through obscurity. The point is that if you want security, you'd just encrypt it. Jabber does have an option to do that. It's as simple as pressing a button.
By having obscure protocols, you just give the illusion of security. And in any case, just because an IM protocol is binary doesn't mean that it won't have plaintext within it.
Yes it was, but being a high level network protocol was NOT one of them.
By using XML, you have the benefit of having a selection of XML libraries to do the work of parsing for you. You have the advantage that it's easy to debug, because it's human-readable. You have the advantage that XML is easily extensible, unlike a binary protocol.
Terseness doesn't particularly matter for an IM protocol. Therefore there is no reason for the speed of a binary protocol. Security through an obscure protocol is silly, as with a standard it would be simple just to pipe tcpdump through a translator. All it discourages is the most casual of listeners. If you have something important to say, encrypt it. It's as easy as setting an option.
Binary has lots of disadvantages. It's very hard to extend, which was one of the main goals for Jabber. It's also harder to parse than XML, considering the amount of libraries availiable. It's harder to debug and more error-prone, thus affecting stability.
XML isn't perfect. It's got a lot of crap in the protocol that isn't needed. But for Jabber, XML was the perfect choice.
"even if your protocol is binary; the conversion is trivial"
Actually its not unless the person has the specs. Ever tried it? Oh I forgot , every on slashdot as a 190 IQ.
"What works for data files also works for data exchange"
Since when? XML data files are entities that only ger referenced occasionally and hence only have to be parsed occsaionally. They don't get referenced dozens of times a second.
Instead of practising your tediously patronising acronyms why don't you practice getting a clue.
Doing so, with an embedded URL: $10
Fucking up the spelling of "Engineering" while forming your smarmy reply: $10
Failing to observe that the previous AC was making a joke: Priceless
For those that would die defending it, Freedom
has a sweet taste that the protected will never know.