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