IETF Approves XMPP Core as Proposed Standard 222
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."
We've been using Jabber for the past two years... (Score:5, Informative)
We're using the Ruby wrapper Jabber4R [rubyforge.org] as well as various GUI clients, and we're using the Jabber 1.4.2 server.
OSS Does It Right (Score:1, Informative)
Re:OSS Does It Right (Score:4, Informative)
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.
Re:OSS Does It Right (Score:2)
Random shutdowns ( rare ), unable to find remote jabber servers on start up ( not so rare ). No method for updating all profiles at once. Manual modifications of profiles are touchy, sometimes jabberd will erase them on startup, sometimes it accepts them.
While I'm willing to accept the responsibility for some of that ( I might mod the profiles under windows, which adds funky characters in there ), but the program is flaky anyway.
Jabberd2, on the other hand, i
Re:OSS Does It Right (Score:2)
What, the decision by the IESG to approve a standard proves something?
Slashweenie ideology asside, have you any idea what has happened or how OSS is involved? There is an OSS implementation of the spec, well
Re:OSS Does It Right (Score:2)
Of course at the moment SIP isn't even able to maintain a list of the users you know, which is one of the most important features of an IM system, the other being presence, which AFAIK, SIP doesn't have either.
Without either of these two features, you might as well just be using a phone, or email.
Then there is SIMPLE, the IM extensions for SIP. As far as I've heard even these guys haven't figured out how to make a list of users yet. Go figure.
Re:OSS Does It Right (Score:2)
Interestingly enough, the SIMPLE specifications for doing the same thing are in exactly the same state as XMPP's: essentially finalized, awaiting approval by the IESG. And, yes, that includes the
Standardized IM Format (Score:5, Insightful)
Re:Standardized IM Format (Score:4, Interesting)
First, complementing what the other poster said (though I don't completely agree with him), this is good for enterprises, especially because the IM server is open-source and available for free, and if you want to create your own server implementation, you can do it, and even extend it to your content.
Second - I don't know if the official proposed standard includes this, but the Jabber implementation allows interoperability between the most popular IMs (ICQ, MSN, Yahoo, etc.), and best of all, this is implemented in the server side. The nice thing about this is that when a protocol changes (MSN for example, that did this months ago), you don't have to update the clients (or client plugins, on some cases), just the protocol gateway on the server.
Of course, this doesn't mean that user John Doe will switch to it overnight, there's just no practical reason for him to do it. It will have to be pushed, and by some company/trademark that has influence, e.g. Netscape distributing a Jabber-compatible IM client along with their browser suite. Though it wouldn't be likely that Netscape would do it, as they are tied to AOL/AOLIM. So it's more likely that this will be a enterprise-only adopted standard, at least for some time.
Good but... (Score:5, Insightful)
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.
Re:Good but... (Score:2, Informative)
Re:Good but... (Score:4, Insightful)
Actually, this isn't really true. ICQ/AOL, MSN and Yahoo all have a different protocol but products like Trillian [trillian.cc] can use Jabber as a generic protocol to layer on top of these proprietary protocols.
Not that I think it will happen, but with Jabber being a standard you'd think these smaller IM players could join together. Or at least link together.
Re:Good but... (Score:2)
Hint: they encourage you to use their apps.
Why would Yahoo want their users talking to ICQ users? The whole point of Yahoo IM! is for it to be a loss leader to suck people into Yahoo Mail, Shopping, etc.
What about Gaim? (Score:4, Interesting)
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.
Re:What about Gaim? (Score:3, Insightful)
Actually Gaim supports IRC as well. Or did you mean that Trillian does not support IRC? In that case, you should work on your grammar.
"...(because once people are using XMPP and Gaim/Trillian, they don't really need AIM or Yahoo! servers to communicate."
Hold on. To communicate with other AOL AIM users, you MUST connect to their servers. Most AOL AIM users do not use Gaim or Trillian. Also, if they did, it
Re:What about Gaim? (Score:2)
I meant I wasn't sure if Gaim supported IRC because I don't use it and was typing in a hurry. Upon closer inspection I realize that Gaim does indeed support IRC (and Jabber, and Gadu-Gadu which I'm not familiar with).
To communicate with other AOL AIM users, you MUST connect to their servers. Most AOL AIM users do not use Gaim or Trillian. Also, if they did, it does not necessarily mean they use XMPP
This gets to the point of my first message. If a cri
History needs to yell more loudly... (Score:4, Interesting)
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.
Re:Good but... (Score:2)
SIP and XMPP are entirely different. (Score:2)
XMPP has attracted some companies attention, while SIP has attracted other companies mindshare. There will be a split in enterprise messaging systems in the next few years.
I should form a company that sells gateways between the two...
Re:SIP and XMPP are entirely different. (Score:2)
To ensure compatibility, both the SIP IM stuff (done in a working group called SIMPLE) and the XMPP IM stu
Thanks... but (Score:2)
Since I've never used jabber, and only looked at SIP (but not for IM), I wouldn't pretend to be knowledgable about the availability of tools.
But I did want stress the dif
We need more of this (Score:2, Insightful)
Re:We need more of this (Score:2, Informative)
I certainly had no problem importing the mailboxes into other clients when I stopped using it.
I truly open standard would be nice, but I don't think Netscape 4 has major client lockin issues.
For those who don't know... (Score:3, Interesting)
Congratulations, and.. (Score:4, Funny)
so do I use existing Jabber API's or wait ...? (Score:3, Interesting)
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?
Re:so do I use existing Jabber API's or wait ...? (Score:2)
Actually, technically it is possible to make a server which only supports XMPP, and doesn't support the legacy Jabber protocol.
In practise though, jabberd2 supports both. The commercial products will also support both. And generally, everybody will support both at least until all the clients upgrade.
Unimportant. (Score:3, Insightful)
Anyway, I'm still wainting for Linksys to make a home router/hub for RFC1149 (IP Datagrams on Avian Carriers)
SIPPING (Score:2, Interesting)
Likewise both S/MIME and OpenPGP have progressed. Eventually sanity will prevail and SIPPING will be "blessed".
I sense a mass migration... (Score:1, Funny)
That was like a stampede!!
Extensible (Score:3, Insightful)
Extensible. Now there's a verb Microsoft loves. They'll extensible this to death now that everyone else thinks it's a standard.
Re:Extensible (Score:2)
"SIMPLE" is a pretty ironic name for what SIMPLE is, isn't it?
(p.s. whoa, LOTS of familiar names in the comments on this story. Must say something about which groups I circle in...)
In The End (Score:4, Interesting)
So, yay, we have a standard. But can we get everyone to implement it PROPERLY?
Excellent. (Score:4, Funny)
Er, how do you pronounce that again?
Re:Excellent. (Score:4, Funny)
XM like eczema, as in, I have a skin condition. PP like pee pee, as in, I need the toilet.
So, pronounce XMPP as skin condition, need toilet informally, and Ezcema, Water Closet formally.
Jabber protocol is excellent (Score:5, Insightful)
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.
Re:Jabber protocol is excellent (Score:2)
Terrible design.
1 - Makes it harder than necessary to reconcile messages going in one direction with messages going the other. How much work does it take to display a log of both sides of a conversation?
2 - Doesn't scale well from 2-way communications to 3-way, 4-way, n-way communications.
3 - If a session gets terminated prematurely, you've got a partial XML document. Which won't validate.
Messages can be encapsulated in XML
Re:Jabber protocol is excellent (Score:2)
As fa
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
A computer cannot figure out semantics from that -- as far as a computer is concerned it's simply a string of ASCII characters.
To the receiving PC, it might as well be:
<aabb ab="42"><ffff>John Doe</ffff><yyyy>Hey Bob</yyyy></aabb>
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
But that's an argument about XML, and not XMPP.
Re:No it isn't , it uses flavour-of-the-month XML (Score:3, Interesting)
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.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Yes, and add a whole new one. Compression overhead! I agree with the grandparent post. XML is very 'flavor of the month', and very inefficient for use in IM. It's far too redundant.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
http://slashdot.org/articles/99/01/04/1621211.s
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:OpenOffice.org file format is XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:5, Interesting)
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.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Isn't the art of good coding to make things as efficient as possible?
"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?"
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
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Yes, but it depends what you mean by "efficient". Do you mean efficient in processing time, memory usage, programmer time? It makes no sense to spend hours optimizing a section of code if your program almost never executes that section of code. It makes a lot more sense to optimize a program for memory on a PDA, but it may be a waste of time if it will run on a desktop and it only takes up 200K unoptimized.
The art of good coding is solv
Re:No it isn't , it uses flavour-of-the-month XML (Score:2, Insightful)
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 st
Re:No it isn't , it uses flavour-of-the-month XML (Score:3, Insightful)
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.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Actually its not unless the person has the specs. Ever tried it? Oh I forgot , every on slashdot as a 190 IQ.
Considering that the title of the article is "IETF Approves XMPP Core as Proposed Standard", it's a fairly safe bet that everybody will have access to the specs.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
" XML is:
A) More bloated than a binary format
B) Harder to parse & hence less efficient that a binary format
C) Much easier to casually snoop on
Face it , XML is flavour of the month and trendy , it has zero advantages over formats."
This is what you said at first, LET US DISECT.
A, yes true, but does it really matter? As others have stated, you don't ALWAYS need to have extremely small, efficient, fast, etc. code/programs/information/etc.
In the c
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:5, Interesting)
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.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
I would be willing to BET MONEY that the IETF sat down with XML in mind and did NOT critically evaluate the suitability (or not) of XML before deciding the protocol.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Wow. A good fraction of a second in an application where the bottleneck will almost certainly be network latency.
Re:No it isn't , it uses flavour-of-the-month XML (Score:5, Interesting)
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.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Anyone who believes that deserves the buffer overflows that they are about to receive.
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
No. (As a rule, although it depends on what you mean by 'things', 'efficient' and 'as possible'.) The art of good coding is to make the code as correct and easy to maintain, in the least amount of coding time, as possible. Optimize (make efficient) only after doing that and profiling to find the bottlenecks.
With a binary format the data can usually in whole or part be mapped direct onto a C structure.
Not at all helpful if the
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
XML i
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Really? Since when? You go show me the code to an XML parser then compare it to something like:
struct data_packet { uint16_t id; uint32_t len
struct data_packet *dp = (struct datapacket *)read_buffer;
dp->id = ntohs(dp->id)
etc etc.
"C) Human readable"
Oh right, and thats a good thing when your passing private conversation over the internet it is?
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
Ummm... even your binary representation will send the text across the line readable. What difference does it make if you make a program easier to debug by making the data human-readable?
And how well will your struct read on an architecture with different endian integers? Doesn't look like you thought of that.
Re:One bit of needless XML bloat: named closing ta (Score:2)
Re:One bit of needless XML bloat: named closing ta (Score:2)
Re:One bit of needless XML bloat: named closing ta (Score:2)
This is for clarity. IMHO, it's a Good Thing. If XML is too bloated for what you need it for, don't use it. This is a chat protocol for crying out loud.
If you'd look at the protocol, you'd see that the amount of XML actually transferred between two clients for a typical chat is rather minimal - I can't remember exactly what it was off the top of
Re:No it isn't , it uses flavour-of-the-month XML (Score:2)
As a side-note to the usual binary XML trolls which come up every time XML gets mentioned in any Slashdot story, there are in fact ways to transmit XML as binary. These include WBXML which is used heavily in the WAP industry, ASN.1 which is being touted by Sun as a performance enhancer for SOAP (another XML protocol), and I believe there is even a group within the W3C working on a standard binary encoding for XML.
What people usually forget XML is mostly that the model is not the format. You can serialise
Re:Jabber protocol is excellent (Score:2)
Apparently.
uses HTTP as transport instead of sockets
Um, HTTP usually uses sockets, too. HTTP is also not stream-oriented the way XMPP is -- although you can get around that to some extent with keep-alive and session ID cookies. (It's just ugly as hell.)
Raw sockets don't work with many proxies and firewalls that I'm facing.
There are probably some work arounds (Jabber proxy?), myself I just make sure the port is open.
Re:Jabber protocol is excellent (Score:2)
for those in the dark (Score:2)
Eh... for those in the dark... what exactly is IETF and/or IESG ???
Re:for those in the dark (Score:2)
IETF is the International Engineering Task Force. They are responsible for keeping the RFCs which have made the internet what it is today. They are responsible for creating standardizations for protocols which have enabled all of the major operating systems today to interoperate (on a crude level) on a huge public network.
Be thankful for their hard work.
IETF? XMPP? HUH? (Score:1, Funny)
What is it good for? (Score:4, Interesting)
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.
Re:What is it good for? (Score:2, Interesting)
Re:What is it good for? (Score:2)
For voice chat there's a wonderful invention that already has significant installed infrastructure. Originally developed by some guy named Bell. It's called the telephone.
it lacks a lot of conveniences other IM protocols have to offer.
Name three.
Excellent, now go request support from Apple! (Score:3, Interesting)
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
Re:Excellent, now go request support from Apple! (Score:2)
Right, flood their bug database with identical requests that someone will have to go through and delete... once the slashdot effect has worn off and they can use the database again. You've identified a really great way to win their developers over to your point of view.
Apple might be doing the mozilla thing and refusing connec
Re:Excellent, now go request support from Apple! (Score:2)
not the first IETF IM standard.... (Score:4, Informative)
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.....
Re:not the first IETF IM standard.... (Score:2)
-A. Tannenbaum, introduction to Computer Networks
Re:not the first IETF IM standard.... (Score:2)
Does anybody use it succesfully? (Score:2, Interesting)
Re:Does anybody use it succesfully? (Score:2)
We do!!! :-D
Granted, Gaim's interface for Jabber has a few issues. If you know how to massage your way past them it's a great solution.
We are a small, company, btw. Scalling for a huge corperation might take a lil planning, but is very doable. We can message out to the jabber.org server and accept messages back in from it. Really excellent stuff, and all over SSL.
Re:Does anybody use it succesfully? (Score:2, Informative)
Re:Does anybody use it succesfully? (Score:2)
As a bonus, we run a 'bot on the channel that does stuff like phone number lookups, IP subnet calculations, etc.
Re:Does anybody use it succesfully? (Score:2)
Peter Saint-Andre at Denver JUG next month. (Score:2)
It's free, including the food (if you get there before it's all gone
great news (Score:2)
XMMP's relevance to IM's future (Score:2)
His latest response was so interesting, I feel compelled to share it here:
XMPP is fascinating, and with a few (okay, quie a few) revisions could become
an all-encompassing standard. Going through the IETF and an open process was
absolutely the right way to make it happen and get the standard out.
Unfortunately, it may also be wholly irrelevant. AOL has won the IM battle, and
unlike the web, where unknown browsers may be connecting to arbitrary unknown
servers, wi
MSN Messenger != Microsoft Messenger (Score:2)
Microsoft Messenger, the one that uses SIP/SIMPLE, is aimed at the enterprise mark
It won't work and I know why (Score:2)
AIM, Yahoo! and MSN are here to stay, folks.
But can you do it in perl? (Score:2)
What about the other end?
Re:Still room for lock in.. (Score:3, Informative)
Re:Still room for lock in.. (Score:2)
Re:Still room for lock in.. (Score:2)
Ah, so you want stream negotiation [jabber.org] for features such as file transfer [jabber.org]. Also encrypted sessions [jabber.org], for which another variant [jabber.org] is already in use.
Whether they then make it through the IETF processes is yet to be seen, but they are being documented, either way.
So close... (Score:5, Funny)
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