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.
this is better than IRC, it's standard is still marked experimental :)
don't forget to patent that before Microsoft does.
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)
--
There is SSL available, I use it when I'm using public computers on Jabber.
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!
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.
...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.
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.