XEP-0019: Streamlining the SIGs

Abstract:This document proposes to streamline the existing Special Interest Groups (SIGs).
Author:Peter Saint-Andre
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Last Updated:2002-03-20

NOTICE: This Procedural document defines a process or activity of the XMPP Standards Foundation (XSF) that has been approved by the XMPP Council and/or the XSF Board of Directors. The XSF is currently following the process or activity defined herein and will do so until this document is deprecated or obsoleted.

Table of Contents

1. Introduction
2. The Problem
3. Analysis and Possible Solutions
4. Proposed Solution

    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

The XMPP Standards Foundation is a continuing experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Special Interest Groups (SIGs). [1]

2. The Problem

Special Interest Groups (XEP-0002) [2] defined a SIG as "a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a SIG is to "produce acceptable enhancements to XMPP within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a SIG after a defined period of inactivity on the SIG's mailing list (normally six months).

Unfortunately, it is widely recognized in our community that the SIGs are not working. Ten SIGs have been approved by the XMPP Council, eight of them over six months ago in July and August of 2001. Two of the special-purpose SIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose SIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in XEP-0002. Only the two "standing" SIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards SIG has assumed the role of discussion forum for specifications before they are submitted to the XMPP Council.

In perhaps the best measure of success or failure, only one SIG has produced a specification for submission to the XMPP Council, and that specification (Jabber-RPC (XEP-0009) [3]) was essentially created outside the SIG structure at JabberCon 2001. Perhaps most ominously, no other SIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the SIGs.

In other words, an honest assessment forces us to conclude that the SIGs are not working.

3. Analysis and Possible Solutions

I see several possible solutions to the SIG problem:

  1. "Crack the whip" -- encourage and cajole the existing SIGs into becoming more active, and energetically manage them so that they produce specifications.
  2. "Wait and see" -- immediately disband the SIGs that are clearly inactive but keep the existing SIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).
  3. "Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to XMPP.

Given the lack of activity in the SIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing SIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the SIGs and find a better way of working.

But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current SIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good XMPP-based software. Nor do I think it's that members of the XMPP community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.

I see several reasons why the SIGs are not working:

  1. The XMPP community right now is too small to be split up successfully into smaller interest groups.
  2. We have tried to overlay too much structure too quickly. The Jabber/XMPP community has traditionally been a fairly anarchic project (or set of projects), and creating ten SIGs right away was at odds with that successful lack of structure.
  3. Good specifications, like good software programs, are usually created by at most a few interested people, not a formal group. Formal groups are not needed to move Jabber/XMPP technologies forward.

If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards SIG, which contains everyone who is strongly interested in XMPP. Finally, we notice that the special-purpose SIGs have not played any appreciable role in our success so far.

4. Proposed Solution

My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of XMPP. Specifically, I propose that we take the following steps:

  1. Immediately disband all but the Standards SIG. [4]
  2. Rely on individuals and small, ad-hoc groups to create specifications.
  3. Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.
  4. If the Standards SIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards SIG. [5]

There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. [6]


Appendix A: Document Information

Series: XEP
Number: 0019
Publisher: XMPP Standards Foundation
Status: Active
Type: Procedural
Version: 1.0
Last Updated: 2002-03-20
Approving Body: XSF Board of Directors
Dependencies: None
Supersedes: None
Superseded By: None
Short Name:
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Appendix C: Legal Notices


This XMPP Extension Protocol is copyright © 1999 - 2014 by the XMPP Standards Foundation (XSF).


Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion by the membership of the XSF might also be appropriate (see <http://mail.jabber.org/mailman/listinfo/members> for details).

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. The proposal contained in this document formalizes some conclusions reached during a weekly discussion forum held by the XMPP Standards Foundation on 2002-01-23. A log of that discussion was formerly available at http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html. Further discussion within the Standards SIG has been helpful in clarifying the argument presented here.

2. XEP-0002: Special Interest Groups <http://xmpp.org/extensions/xep-0002.html>.

3. XEP-0009: Jabber-RPC <http://xmpp.org/extensions/xep-0009.html>.

4. In an earlier version of this document, I proposed that we retain the Security SIG. However, since there is a security aspect to all protocols, I now think it is best if security-related topics are discussed within the Standards SIG, not in a separate Security SIG.

5. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). Unlike the current SIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the XMPP Council.

6. Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at http://www.jabber.org/bylaws.html.)

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 1.0 (2002-03-20)

Changed status to Active. (psa)

Version 0.2 (2002-03-06)

Minor revisions. (psa)

Version 0.1 (2002-02-24)

Initial release. (psa)