JSF Council 2004 Position Paper
Following the nice example of both pgmillard,
and 
stpeter,
this is my position paper for the Jabber Council.
Background
Recently, I received my Masters in Computer Science, having Distributed Systems as my main subject. Now, I work at the same university, in the Mechanical Engineering department as Scientific Programmer. Since the second half of 2000, I have been involved with Jabber, almost immediately being very interested in the protocol, its (possible) uses and future direction. Ever since, my personal website has been a playground for using Jabber in creative ways and prototyping various Jabber based protocols.
What I did so far
Most of my Jabber protocol related work is concentrated on presence and publish-subscribe related protocols. My contributions to the JSF's protocol work has been prototyping/implementing some of these protocols and being very vocal on the standards-jig mailinglist, occasional protocol discussions in the foundation conference room, and direct correspondence with the authors of such protocols. Also, I've contributed to the IETF XMPP WG discussions.
Following, a list of JEPs I've been involved with:
JEP-0060: Publish-Subscribe. Strong contributer, implementor.
JEP-0080: User Geolocation. Contributer.
JEP-0107: User Mood. Co-author, implementor.
JEP-0108: User Activity. Primary author.
JEP-0118: User Tune. Implementor.
I have been involved with pubsub ever since the first pubsub JEP by DJ Adams and used moods as a test case, even before the User Mood JEP had been written, first using DJ's protocol, later using JEP-0060. Also, I've been using both pubsub protocols for publishing news items to Mimír (see also Mimír's architecture), while implementing Idavoll, a generic pubsub service implementation.
The Council
A number of important JEPs covering pubsub, disco and file transfer have recently advanced to either draft or final status. This is a nice accomplishment. Now, we need to ensure that there are implementations of these protocols, so we can have hands-on data on the protocol's usability and potential problems. This makes it possible to enhance the protocols to be a good bases for writing Jabber based applications, without developers having to reinvent the wheel.
Also, a major focus point this term should be the protocol suites (Basic, Advanced, and Extended Presence). Instead of having implementors specify a potentially very long list of supported JEPs, these protocol suites describe nicely grouped sets of JEPs to be implemented for certain use cases. For now, these are mostly aimed at using Jabber for IM, but we might also need to look for other use cases.
On the other hand, the Council should continue to prevent filling the JEP list with niche protocols. Instead, the focus should be on providing the building blocks for building useful applications, in a generic way. Quality over Quantity.
Finally, I think the Council should regularly have meetings again, and also provide for regular protocol discussions. In my experience, when focussed on well-defined subjects, the protocol discussions have proved very useful and inspiring.
Why me?
I am an active contributor to the JSFs protocol work. Besides commenting on protocol proposals, I also tend to try them out, often asking many questions. Writing code against a specification is the best way to find issues with them, when done with care. On the other hand, I believe that clear, unambiguous, and complete specifications yield better implementations. I think I can be instrumental in bringing those two together.
While XMPP is the basis, the JSF, with the Council at the helm, defines the higher level building blocks for the next generation of distributed systems. I believe I can help the JSF crank out the best protocols we can, through offering my expertises as a member of the Jabber Council.