Minutes of the Jabber BOF (jabber) Time: Monday, 2002-07-15, 1930-2200, room 501 Chair: Pete Resnick Minutes: Marshall Rose 1. Agenda Bashing: The chair introduced the agenda, and asked for some to take minutes. A volunteer was indentured. It was agreed to revise the agenda to allow for questions both during and in between the presentations. In particular, much discussion was expected after the first two technical presentations. 2. Introduction: The chair introduced the bof by noting that Jabber is a lot of different things, but that the bof was limited to the XMPP protocol that Jabber uses. In particular, the question to answer is whether its a good idea to bring xmpp into to the IETF. An initial question was whether the owners of XMPP understood what that entails. (Much discussion along this line was held later on, cf., Section 6, below). 3. XMPP Overview, by Joe Hildebrand, Chief Architect, Jabber, Inc. The speaker's basic points: - XMPP is an XML-based protocol that delivers asynchronous XML content, of which IM is a one kind of traffic - Three are 3 I-Ds that document the existing XMPP - XMPP's model is similar in concept to the SMTP model, the major addition being the notion of resources (multiple mailboxes for the same recipient) and services (a standardized way of extending a server) - Each direction of an XMPP connection is a single XML document containing zero or more "packets" - There are three types of packets: message, presence, and info/query The speaker gave some examples of XMPP packets and usage and then indicated areas in which the IETF could add value: - Separation of presence from IM - Security standardization - Transport independence (e.g., SMS) 4. Questions Do XMPP entities trust the "From" element? Not really. Servers require that clients authenticate themselves, and server/server authentication occurs with a dialback mechanism, but neither are inherently secure. Does XMPP support anonymous messages? Although there are anonymizers, in general, the answer is no. Are subscriptions bi-directional? No, there are for kinds: to, from, both, or none. Why did you crate a new URL scheme ("jabber:") for a few new datatypes. This was a historical decision. How do you handle downgrade attacks? Clients may be configurable as to the minimum level of acceptable security. (It was subsequently noted that, in the absence of TLS, that an attacker could hijack a TCP connection regardless of the method of authentication.) 5. XMPP and the IETF, by Jeremie Miller, Founder, Jabber Software Foundation The speaker recounted the early history of Jabber, starting back in 1998, along with his initial interactions with the IMPP working group. The speaker then explained Jabber's growth, both in terms of users and applications. As a result, there are presently over 100K deployments with over 1M users. This growth is leading to new pressures on the Jabber Software Foundation (JSF) which current manages XMPP development. Rather than start diverging activities, the JSF would prefer that XMPP move to the IETF to get: - a "better" standards-process - help with security - help with internationalization In terms of comparing XMPP with IMPP, the speaker noted two differences: 1. XMPP is XML-based whilst IMPP is MIME-based, and that you could encapsulate XML in MIME and vice-versa. However, when building a CPIM gateway, if end-to-end encryption were used, then translation could not occur. 2. XMPP achieves presence using broadcast, not transient subscriptions. However, a CPIM gateway could easily translate between the two. 6. More Questions: There were several questions concerning change control. The second speaker explained the current process used by the JSF. Briefly, Jabber Enhancement Proposals (JEPs) are submitted, discussed in a group, and a vote is taken by the JSF's council. If the IETF starts work on XMPP, with the JEP process be discarded? For the parts that deal with XMPP, yes. (Jabber is more than XMPP.) Are you comfortable with the notion of giving up control of the technology in your flagship project? Yes, this has sign-off at the highest levels of management in Jabber, Inc. Will you support the resulting specification? Yes, this has sign-off at the highest levels of management in Jabber, Inc. It was noted that the IETF process isn't as fast as the way XMPP has developed. There were several questions on backwards-compatibility. The first speaker explained that XMPP was very "upgrade friendly" and that two large protocol upgrades had already been made to XMPP since 1998. What is special in XMPP that we need to standardize something else that does presence? Jabber is a simple, easy to configure and use system that asynchronously transports XML content. What would prevent other companies with IM technology and coming to the IETF and making the same offer? Nothing, and that's a good thing. There was some discussion as to whether CPIM was still needed if SIMPLE were to be the only IM technology used by the IETF. 7. User experiences (part one), by Dale Malik, Bellsouth The speaker briefly discussed a commercial offering provisioned for 1.5M users. Under test, the system has supported 200K simultaneous users with 100K simultaneous sessions. The speaker indicate the kinds of things he'd like to see in moving foward with XMPP: - more security - more carrier class - easier application integration 8. User experiences (part two), by Alexandre Noell, France Telecom The speaker briefly described a commercial offering for an ISP having 7M users. After developing an internal protocol, the ISP adopted XMPP instead because: - it was XML-based, so it was easy to understand, implement, and integrate - it supported interoperability with other IM systems, including server/server queries - it is connection-oriented, which is good for server-push - it is extensible, making it easy to extend exsting features and add new protocol functions. The ISP subsequently added about 10 new services to XMPP, e.g., blacklisting. In terms of technology choices, the ISP deployed the service using both Sun/Oracle and PCs. The front-ends are each able to handle 10K simultaneous sessions and upto 400 messages/second, and the servers are each able to handle 100K simultaneous sessions and 2000 messages/second (i.e., a user sending a message every 50 seconds). The offering launched in April, 2002 and is currently running with 300K users. The speaker indicate the kinds of things he'd like to see in moving foward with XMPP: - presence packets should be per domain instead of per contact - presence should be better seperated from subscription 9. Still More Questions: There were several questions/comments (well, mostly comments) regarding whether (or not) introducing XMPP was destructive of the IETF process, e.g., - should the IETF be standardizing technologies or picking winners? - doesn't SIMPLE have mind share? the IETF shouldn't do overlapping protocols (oh, wait there's already CPIM) - we're setting the bar too high by requiring that a new effort not compete with an existing effort, the only questions should be: is it tecnically credible, are people willing to work on it, are people willing to use it? - we should be deciding things based on the number of folks who want to do things, not the number opposed. - what exactly is the scope of xmpp? asynchronously transport of XML content - do we have the resources to split up our efforts? It was noted that SIMPLE wasn't the only thing in the IETF, that APEX was being published as RFCs. What are the advantages of XMPP over SIMPLE? traverses firewalls, has congestion control, a lot easier to implement and integrate with. Will XMPP implementors (other than Jabber, Inc.) synchronize their work with the IETF product? If there's functionality there, sure. It was noted that a generic XML delivery system, or even an IM transfer protocol, such as XMPP would be an interesting work item for the IETF. And, finally: is any of the XMPP technology encumbered by IPR issues? No, portions of the Jabber, Inc., implementation have IPR protection, but there are at least two commercial XMPP implementations from other companies, and the Jabber, Inc. lawyers aren't suing them. 10. Wrap-up The chair asked for humming for the following three activites: How many folks would are willing to work on XMPP for: - for async messaging - for im - for presence after receive various hums, the meeting was adjoured. #######