[Council] Extension Proposals

Paul Curtis pcurtis at terrapin.com
Fri Oct 24 17:52:52 CDT 2003

Extension Proposals

As was stated to me during the last Council meeting, the current enhancement proposals
will not be a part of the IETF standard XMPP protocol. It is because of the statements of
Peter Millard and Peter St. Andre, that I took some time to determine what, if any, the
role of the Council, enhancement proposals, and the process will become after the XMPP
core and IM Internet Drafts become RFCs. By placing the XMPP portion of the protocol into
the hands of the IETF, the role of the JSF as the 'definer' of the protocol will
essentially disappear.

 From a wider point of view, there will be nothing stopping a developer from creating
extensions to the XMPP protocols. While we would view this as sub-optimal, it is going to
happen with or without the input of the JSF and the JSF Council. This realization needs to
be addressed and examined as we define how enhancement proposals should be handled in the
future. The growth of XMPP will no longer be dictated by the JSF, but rather by those who
are implementing.

The JSF has an opportunity to become the authoritative source of documented extensions. By
fulfilling this role, the Council can participate in the creation of new extensions. The
Council (and other JSF members) can become sounding boards for the ideas. While we do this
now, we do it after the fact. Rather than ruling on a proposal, we should be helping to
develop those proposals. Since the JSF cannot be the 'owner' of the protocol, we need to
position ourselves as the best resource for extensions: from their creation through their

In light of all this, I suggest the Council pursue several changes in the process to
leverage the up coming XMPP RFCs.

Categorize the proposals as Final, Draft, and Deprecated. The 'Final' proposals will be
those proposals that have completed the process, and have been voted on by the membership.
Proposals that are currently 'Final' would remain so, while those that have not completed
the process will be marked as 'Draft'. The 'Draft' status indicates that the proposal has
been entered with the editor, and is currently under review and revision. The proposals
that are marked as 'Deprecated' are maintained by the editor for informational purposes
only, and are not recommended for use in current projects. The 'Humorous' indication can
be added if the Council feels this would be appropriate.

I broke the list into three catagories to eliminate any ambiguity surrounding the
proposal's status. Implementors can quickly determine which of the proposals are 'safe'
for implementation, while those marked as 'Draft' status are subject to change before
becoming 'Final'. By having a single designation ('Deprecated') for those proposals that
are no longer recommended, the Council and the JSF can keep the information for future
implementors to use in those cases where older software may still use these extensions.
Looking forward, the Council should realize that the process must be more proactive as has
been suggested. By this I mean that the Council should help to develop the proposal before
it is submitted formally.

The concepts of 'informational' and 'standards' have been removed from the discussions of
extensions. As was pointed out to me, proposals are not to be included nor submitted to
become a part of the standards. Because the official standards for XMPP are the IETF
Internet Drafts, the Council will be involved only with additions to XMPP. By taking this
view, all proposals that are not part of the XMPP RFCs are 'extensions' and not
'standards'. While the JSF and the Council may view them as 'standards', I feel that
future implementors will not. By avoiding any confusion between the 'standards' and the
proposals, the Council defines it's role as the arbitor of 'extensions' to XMPP.

Further, as many have pointed out, the proposals are not 'Jabber' in the way that many are
accustomed to referring to it. I will not take a position on such things as foundation
name changes, but I will suggest that proposals be called 'Extension Proposals' or even
'XMPP Entension Proposals' rather than JEPs.

You may have noticed that until the last paragraph, I replaced the term 'JEP' with either
enhancement proposal or extension proposal. As you can see, the term is not what matters
here, but the process and the role the JSF and Council will play in the future.

As an excerise, I will be taking two of the most important question in this missive,
renaming proposals and proposal statuses, and creating two "rotisseries" for questions and
rebuttals. The "rounds" will be found under "Council" at http://jabber.terrapin.com/h2o. I
will set the start date in the future (Sunday) to allow everyone to register. Make sure
you join the "Council" project to receive the "rounds". You have to be registered and in
the project to receive the questions.



More information about the Council mailing list