[JDEV] Council Position Paper: Peter Millard

[Peter Millard]

You can view this file in HTML format at:
http://www.pgmillard.com/jabber-pos-2002.html
Enjoy & thanx for reading :)

                                  Background

   I am a developer who also likes to do stuff in the outdoors ([1]
   http://www.pgmillard.com for more personal stuff). I recently got
   married, and I'm currently employed by [2]Jabber, Inc., and live in
   Denver, Colorado, USA. My interest in jabber started when I was
   working for own company ([3]Vantek Corp.) while I was researching XML
   as a possible file storage medium for our data files, at the same time
   I was getting pissed off at having to run four different IM clients. I
   am a developer at heart, and believe that Jabber has the power to
   become true internet infrastructure.

                      What cool Jabber stuff have I done?

   I am most well known for my Windows clients ([4]Winjab, and [5]Exodus)
   as well as the JabberCOM library. I also had a hand in both of the
   commercially available clients from Jabber, Inc (JabberIM and the
   Webclient). During the early development of Winjab and JabberCOM, I
   helped in the development of the core jabber protocol, and had early
   implementations of many of the current extension protocols. For the
   past year, I've served on the Jabber Council and helped to iron out
   the JEP process as well as the Council process.

   I've either authored, or had hand in the following [6]JEPS:
     * JEP-008: Avatars (Currently idle, pending pub/sub).
     * JEP-016: Server Side Privacy (Adding whitelisting into JEP, then
       send to Council)
     * JEP-020: Feature Negotiation (Need to remove last security
       references, and re-send to Council).
     * JEP-030: Service Discovery (Needs more work, under development)
     * JEP-032: Jabber URIs (Under development)
     * JEP-036: Jabber Pub/Sub (Really just a recap of discussions of
       from JabberCONF EU).

                                Primary Issues?

   I think the past year has been an interesting year for the JSF. It's
   fun and "exciting" to be involved with an organization during it's
   infancy. Much of the this year was spent trying to find the balance
   between having enough process around the JSF to maintain control, but
   also to not have too much process such that inovation is hindered.

   As a standing Council member for the past year, I have some opinions
   about what was good and what was bad about the past year. Being first
   time council members, we spent a fair amount of our time (early on)
   just trying to figure out what we were supposed to be doing. This was
   time well spent since we now have a relatively well defined process
   for getting things done. Serving as a Council member is an important
   "obligation" to the jabber community, and we have to be willing to
   take on the time commitment which it requires. I believe going
   forward, the council will be more productive since we have a well
   defined process for the tasks we are to do (we also know what those
   tasks are), and we will have people that are willing to spend the time
   necessary for being a council member.

   Some important JEP's are currently being discussed on the various
   mailing lists, and I think it's important that the council be willing
   to take these issues head-on. We need to help drive conensus on these
   issues. I believe that some of the difficulty the foundation has had
   coming to consensus on the following issues is two-fold:
    1. All of these "Primary issues" are semanticly linked together..
       Meaning that they all could use the other protocols to enhance the
       overall usefulness of one the protocols.
    2. It's hard to make generic protocols that will be as future-proof
       as possible.

   I would place the highest importance on establishing a single pub/sub
   standard, then addressing the service discovery issues. However, it is
   my feeling that we're going to have to flesh out pub/sub, discovery,
   and feature negotiation protocols simultaneously, since they are
   inherently linked together. I believe that the council probably needs
   to be more proactive in helping the community come to consensus on
   these various issues through possibly organized groupchat meetings. I
   am not a security expert, but I'd also like to work on seeing some of
   the security JEP's standardized and implemented in the clients that
   I'm working on.

Pub/Sub

   Many different opinions have been offered on the subject of Pub/Sub,
   and there is still quite a bit of work to be done. I firmly believe
   that having a standardized pub/sub protocol is ESSENTIAL for lots of
   other work to be done in the jabber space. We need to strive to find
   some common ground amongst the three proposed JEPs, and try to work
   together to compromise on a single solution that will satisfy as many
   interested parties as possible.

Disco, Browse, Feature Negotiation

   The whole concept of service and/or feature discovery and then
   following it on with feature negotiation is something jabber has tried
   to perfect since the early jabber:iq:agent protocol days. I believe
   that browse is a good step forward over the old agents protocol, but
   it was more of a stepping stone to something like pure generic service
   and feature discovery.

Security

   I think the jabber community has done an adequate job so far at
   defining and solving security issues. However, what we've accomplished
   so far is just the tip of the ice berg. I think that we have a lot
   less "controversy" over the various security JEPs, we just have lots
   of actual leg work to do and to start implementing some of the
   ideas/proposals put forth.
     * JEP-031 is an excellent framework JEP. We need to have more people
       get their heads wrapped around this framework and start to
       critique it. I think that this kind of framework will eventually
       allow Jabber to provide IM users a quick and easy way to get
       end-to-end encryption without having the overhead of having to
       install and deal with PGP/GPG. (Which has a high cost of entry for
       "Joe Six Pack IM user").
     * JEP-035 is also an excellent idea for having a better integration
       with SSL and obviates the need for CCM's (Client Connection
       Managers) to have to deal with multiple listening ports.
     * JEP-034 is important for integrating Jabber into other
       applications as well as allowing us to embrace more "approved"
       IETF technologies.

                            Other Thoughts & Issues

   There are some other issues that I am interested in and want to work
   to have some of these issues cleared up.. These are in no particular
   order, but just indicate that they are on my "radar"
     * Jabber.org website, and cohesiveness with JabberStudio.org
     * Client guidelines and checklists. Do we have "JSF
       Approved/Endorsed" clients?
     * Protocol development guidelines, and possible versioning.
     * Next generation framing protocol. How do we co-exist with the
       existing stream:stream implementations?
     * Can we (or will we) ever use namespaces properly?
     * Integration with other open-source projects (apache).

References

   1. http://www.pgmillard.com/
   2. http://www.jabber.com/
   3. http://www.vantek-corp.com/
   4. http://winjab.sf.net/
   5. http://exodus.sf.net/
   6. http://www.jabber.org/jeps/