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