Zitat

Here's the lay of the land from my perspective as putative leader of the Jabber community:

1. XMPP (RFCs 3920-3923) is the IETF's formalization of the core Jabber protocols (mainly designed within the open-source Jabber projects back in 1999), where formalization involved updated security bits (TLS and SASL) and some improved internationalization coverage (BTW, all Jabber addresses are fully i18n-friendly and can contain virtually any Unicode character -- coming to email in 2020 or so).

2. XMPP extensions are not defined in the IETF for many reasons, not least of which is that we'd be wasting IETF bandwidth on things like avatars and other application-specific functionality. This is why the xmppwg list is quiet -- we shut down the XMPP WG once we were done with the core specs.

3. We define XMPP extensions through the Jabber Software Foundation's JEP series. This works well. No need to send every last XMPP extension through the IETF, faster document updates, etc. So all the traffic and activity is at the JSF these days, not the IETF.

4. Groupchat (a la IRC) has never been the main focus of the Jabber community. We have only one groupchat protocol, defined in JEP-0045. It is backwards-compatible with an older, less featureful protocol we put together in 1999. JEP-0045 has not been approved by the IETF (it's a JEP, not an Internet-Draft or RFC), but I can tell you that there are multi-user chat rooms up and running for all IETF working groups over at the ietf.xmpp.org chat service, and they get a fair amount of use.

5. Jabber/XMPP does not primarily provide gateways to the consumer IM services, we're too busy building out a better technology for IM, presence, and real-time request-response functionality.

6. Jabber/XMPP is fundamentally a technology for streaming XML. I know I know, it seems odd from the W3C perspective (Tim Bray told me once that "I wouldn't have done it that way"), but it works well for a wide range of applications beyond IM, including workflow systems, network management, content syndication, gaming, even transports for XML-RPC and SOAP.

7. Jingle is a set of XMPP extensions for doing multimedia signalling / negotiation over our streaming XML channel. We go out of band (typically using RTP) to do the heavy lifting of the voice/video/etc. transport itself. Not that dissimilar from how things are done in the SIP world, except we require authentication and effectively prevent address spoofing, thus avoiding many of the security problems related to SIP.

8. Jabber/XMPP most definitely does not have the same spam issues that SMTP has, despite having a similar (client-server) network topology. We *require* authentication to get on the network, we *require* servers to stamp "from" addresses on all packets (no address spoofing here), we *require* servers to at the least perform reverse DNS lookups before accepting data from other servers (or do TLS with certificates), etc. Plus we have an extremely diverse client ecosystem (no obvious attack vector), a pure XML transport (not friendly to binary worms and viruses), a very retricted set of allowable XHTML formatting (an official XHTML subset that we worked on with some W3C guidance), and so on. We do not have spam on the Jabber/XMPP network (thousands of servers, millions of users, growing organically since 1999). We don't have viruses or worms or other malicious content either.

9. Yes, Google is indeed opening their Google Talk service to federation with the rest of the Jabber/XMPP network. They wrote their first release without server-to-server support. It's coming soon to a public network near you.

10. Yes, iChat natively supports the Jabber/XMPP protocols in Tiger. The pre-Tiger support was only in Rendezvous (now Bonjour) mode. In Tiger, you can connect to any accessible Jabber server if you have an existing account. And yes, that includes connecting to Google Talk. Open standards are good, no?

That's the short version. Email or Jabber me via stpeter@jabber.org if you have more questions.

Zitat

The main advnatage of the Jabber Protocol (besides it being an open source specification and a standard) is that it is federated like the Email system is, meaning, if I send an Email to another friend who is on the same server, that Email will never leave the server.
If I send an Email to a friend in a different server (domain) that Email can go through 1 or more other servers until it reaches its destination.

Zitat von »hurra«

Sehr nett, wenn ich nicht schon jabber nutzen würde, würde ich umsteigen

Zitat von »hurra«

Was bedeuten diese zwei @-Zeichen?

Zitat von »Hummerman«

Schade das das Jabber-Plugin für Trillian nur mit der Pro-Version geht.