[xmppwg] New charter please
joe.hildebrand at webex.com
Mon Mar 30 18:11:27 CDT 2009
I believe this captures what we discussed at the BoF, and is the right set
of things for us to start working on.
On 3/30/09 4:54 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
> So, incorporating everything in one place, here is what I have in my
> working copy...
> Extensible Messaging and Presence Protocol (xmpp2)
> Area Director(s):
> Area Advisor:
> Mailing Lists:
> General Discussion:xmppwg at xmpp.org
> To Subscribe: xmppwg-request at xmpp.org
> In Body: subscribe
> Archive: http://mail.jabber.org/pipermail/xmppwg/
> Description of Working Group:
> The Extensible Messaging and Presence Protocol (XMPP) is an IETF
> technology for the near-real-time exchange of messages and presence
> notifications, where data is exchanged over Extensible Markup Language
> (XML) streams. XMPP was originally formalized by the XMPP Working Group
> in 2002-2004, resulting in publication of RFCs 3920-3923.
> Implementation and deployment experience since that time has resulted in
> errata, clarifications, and suggestions for improvement to the core XMPP
> specifications (RFCs 3920 and 3921). Furthermore, some technologies on
> which XMPP depends have also undergone modification. The documents
> draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect
> this work but need to be completed by the group. It is envisioned that
> these specifications will be recycled at Proposed Standard because of an
> accumulation of small changes and improvements.
> Although RFC 3923 defines an end-to-end signing and encryption technology
> for use by XMPP systems, to date it has not been implemented. A goal of
> the group is to develop an implementable method for end-to-end encryption,
> preferably based on well known and widely deployed security technologies.
> XMPP uses TLS for encryption and the Simple Authentication and Security
> Layer (SASL) for authentication. In the case of a server-to-server
> stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism,
> where each peer presents an X.509 certificate. This model introduces
> scaling challenges in multi-domain deployments because RFC 3920 requires
> that a stream cannot be reused for more than one domain, thus
> necessitating multiple TCP connections. The group will work to overcome
> these challenges by defining an optional mechanism for using a single
> connection with multiple identities. It is anticipated that most of the
> work will consist of defining and providing requirements to the TLS and
> SASL working groups.
> Many of the core and extended features of XMPP have also been
> implemented in technologies based on the Session Initiation Protocol
> (SIP). To ensure interworking between XMPP systems and SIP systems, a
> number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been
> produced. The group will define a framework within which this work could
> be completed.
> In completing its work, the group will strive to retain backwards
> compatibility with RFCs 3920 and 3921. However, changes that are not
> backwards compatible might be accepted if the group determines that the
> changes are required to meet the group's technical objectives and the
> group clearly documents the reasons for making them.
> Goals and Milestones:
> - Deliver rfc3920bis and rfc3921bis to the IESG.
> - Decide upon a direction for end-to-end encryption.
> - Decide upon a direction for server-to-server connection reuse.
> - Define a framework for SIP-XMPP interworking.
> - Define a solution for end-to-end encryption.
> - Define a solution for server-to-server connection reuse.
More information about the xmppwg