From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: xmpp WG <xmpp@ietf.org>
Subject: WG Review: Extensible Messaging and Presence Protocol (xmpp)
The Extensible Messaging and Presence Protocol (xmpp) working group in
the Real-time Applications and Infrastructure Area of the IETF is
undergoing rechartering. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2013-02-28.
Extensible Messaging and Presence Protocol (xmpp)
------------------------------------------------
Current Status: Active Working Group
Chairs:
Joe Hildebrand <jhildebr@cisco.com>
Ben Campbell <ben@nostrum.com>
Assigned Area Director:
Robert Sparks <rjsparks@nostrum.com>
Mailing list
Address: xmpp@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/xmpp
Archive: http://www.ietf.org/mail-archive/web/xmpp/
Charter of Working Group:
The Extensible Messaging and Presence Protocol (XMPP) is an
technology for the near-real-time exchange of messages and presence
notifications, where data is exchanged over Extensible Markup Language
(XML) streams. The original XMPP working group published 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). Some technologies on which
XMPP depends (e.g., Transport Layer Security and the Simple
Authentication and Security Layer) have undergone modifications of their
own, which XMPP needs to track. Finally, the group needs to define a
sustainable solution to internationalization of XMPP addresses, since
the approach taken in RFC 3920 (based on stringprep profiles) is limited
to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
draft-saintandre-rfc3921bis-* reflect community input so
far regarding these modifications, but the group needs to complete this
work, especially with regard to internationalization. Because of the
scope of changes involved, it is envisioned that these specifications
will be cycled at Proposed Standard.
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.
In addition to the TCP binding defined in RFC 6120, the XMPP community
has long employed an HTTP binding (XEP-0124 and XEP-0206 published by
the XMPP Standards Foundation). Given that this binding uses HTTP long
polling, which has many known issues (RFC 6202), it is reasonable to
transition to use of the WebSocket protocol (RFC 6455) instead. Work has
begun on defining a WebSocket subprotocol for XMPP
(draft-moffitt-xmpp-over-websocket). The group will complete the
definition of such a subprotocol, and coordinate reviews with the HYBI WG
where appropriate.
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.
Milestones:
Done - Decide upon a direction for server-to-server connection
reuse.
Done - Deliver rfc3920bis and rfc3921bis to the IESG.
Done - Decide upon a direction for end-to-end encryption.
Mar 2012 - Define a solution for server-to-server connection reuse.
Aug 2012 - Define a solution for end-to-end encryption.
Sep 2012 - Define a solution for internationalization of XMPP addresses
(Update of RFC 6122)
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: xmpp WG <xmpp@ietf.org>
Subject: WG Action: Rechartered Extensible Messaging and Presence Protocol (xmpp)
The Extensible Messaging and Presence Protocol (xmpp) working group in
the Real-time Applications and Infrastructure Area of the IETF has been
rechartered. For additional information please contact the Area Directors
or the WG Chairs.
Extensible Messaging and Presence Protocol (xmpp)
------------------------------------------------
Current Status: Active Working Group
Chairs:
Joe Hildebrand <jhildebr@cisco.com>
Ben Campbell <ben@nostrum.com>
Assigned Area Director:
Robert Sparks <rjsparks@nostrum.com>
Mailing list
Address: xmpp@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/xmpp
Archive: http://www.ietf.org/mail-archive/web/xmpp/
Charter of Working Group:
The Extensible Messaging and Presence Protocol (XMPP) is an
technology for the near-real-time exchange of messages and presence
notifications, where data is exchanged over Extensible Markup Language
(XML) streams. The original XMPP working group published 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). Some technologies on which
XMPP depends (e.g., Transport Layer Security and the Simple
Authentication and Security Layer) have undergone modifications of their
own, which XMPP needs to track. Finally, the group needs to define a
sustainable solution to internationalization of XMPP addresses, since
the approach taken in RFC 3920 (based on stringprep profiles) is limited
to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
draft-saintandre-rfc3921bis-* reflect community input so
far regarding these modifications, but the group needs to complete this
work, especially with regard to internationalization. Because of the
scope of changes involved, it is envisioned that these specifications
will be cycled at Proposed Standard.
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.
In addition to the TCP binding defined in RFC 6120, the XMPP community
has long employed an HTTP binding (XEP-0124 and XEP-0206 published by
the XMPP Standards Foundation). Given that this binding uses HTTP long
polling, which has many known issues (RFC 6202), it is reasonable to
transition to use of the WebSocket protocol (RFC 6455) instead. Work has
begun on defining a WebSocket subprotocol for XMPP
(draft-moffitt-xmpp-over-websocket). The group will complete the
definition of such a subprotocol, and coordinate reviews with the HYBI WG
where appropriate.
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.
Milestones:
Done - Decide upon a direction for server-to-server connection
reuse.
Done - Deliver rfc3920bis and rfc3921bis to the IESG.
Done - Decide upon a direction for end-to-end encryption.
Mar 2012 - Define a solution for server-to-server connection reuse.
Aug 2012 - Define a solution for end-to-end encryption.
Sep 2012 - Define a solution for internationalization of XMPP addresses
(Update of RFC 6122)