[xmppwg] possible charter text

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 23 00:57:47 CDT 2009


Based on some preliminary discussions and off the list, I've revised my
proposed text...


***

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.

The end-to-end signing and encryption technology defined in RFC 3923 has
not been implemented to date. Another goal of the group is to develop a
replacement for RFC 3923, preferably based on well known and widely
deployed security technologies such as Transport Layer Security (TLS).

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 can
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 frameworking for SIP-XMPP interworking.

- Define a solution for end-to-end encryption.

- Define a solution for server-to-server connection reuse.

***

Further bashing is welcome.

You will note that this draft removes certificate management and some of
the SIP-XMPP work from this phase -- perhaps they would be brought back
in the future if the group is rechartered (well, that's assuming that a
group is chartered in the first place).

Peter

On 3/20/09 9:47 AM, Peter Saint-Andre wrote:
> Here is some possible text describing a reconstituted XMPP working group.
> 
> ***
> 
> 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.
> 
> The end-to-end signing and encryption technology defined in RFC 3923 has
> not been implemented to date. Another goal of the group is to develop a
> replacement for RFC 3923, preferably based on well known and widely
> deployed security technologies such as Transport Layer Security (TLS),
> as outlined in draft-meyer-xmpp-e2e-encryption.
> 
> 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 the exchange of a
> subsequent TLS handshake and SASL authentication over an existing XML
> stream.
> 
> The group will also define best practices for the use of SASL EXTERNAL
> over client-to-server streams, perhaps including methods by which a
> client can perform server-side management of its certificates as
> outlined in draft-meyer-xmpp-sasl-cert-management.
> 
> 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
> series of Internet-Drafts (draft-saintandre-sip-xmpp-*) has been
> produced. The group will complete reviews of these documents in order to
> prepare them for standards actions.
> 
> 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.
> 
> ***
> 
> Let the bashing begin. :)
> 
> Peter
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/xmppwg/attachments/20090322/32bf75af/attachment-0001.bin 


More information about the xmppwg mailing list