[xmppwg] possible charter text

Kurt Zeilenga kurt.zeilenga at isode.com
Mon Mar 23 11:34:24 CDT 2009


It would be nice to have some statement of what out-of-scope for this  
WG.

On Mar 20, 2009, at 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.

Can new features be added?  If so, what might they be?

I'd like to narrow this work to "a revision effort", with new features  
being handled via extensions.

(I think this is what's intended, but I rather charter be a bit more  
explicit on this.)

>
>
> 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,

That meets the requirements specified in RFC 3923, or some other set  
of requirements?
That is, are we going to reconsider the requirements?

> preferably based on well known and widely
> deployed security technologies such as Transport Layer Security (TLS),
> as outlined in draft-meyer-xmpp-e2e-encryption.

TLS is stream based.  RFC 3923 is a message based.  I think we still  
need a per message-based security solution.

(Note: I don't object do engineering a method for securely tunneling  
data over XMPP, I just don't think of it being a replacement for  
message-based security solution.)


>
>
> 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.

Peter suggested dropping this work item.  I'm support dropping this as  
well.  I think the XSF might be a better forum for pursuing work in  
this area (as well as the general "credential management" area).

>
>
> 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.

First, I note that I don't care to spend any of my time on this.

Second, I don't think such documents should be on the Standards Track,  
Informational is more appropriate here.

I would rather such documents simply be pursued on an individual  
basis, and WG members reviewing the work as they so choose.

>
>
> 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
>
> -- 
> Peter Saint-Andre
> https://stpeter.im/
>



More information about the xmppwg mailing list