Difference between revisions of "Dave Cridland for Council 2007"
|(One intermediate revision by the same user not shown)|
|Line 1:||Line 1:|
I'm Dave Cridland, with a depressingly short history within the XMPP world, but a long history within messaging - including instant messaging - and standardization. You can refer back to my [[Dave Cridland January 2007|XSF Application]] to find out more detail on this, but I wrote my first instant messaging system in the last century. You ''can'' Google for my involvement back then, by [http://www.google.com/?
I'm Dave Cridland, with a depressingly short history within the XMPP world, but a long history within messaging - including instant messaging - and standardization. You can refer back to my [[Dave Cridland January 2007|XSF Application]] to find out more detail on this, but I wrote my first instant messaging system in the last century. You ''can'' Google for my involvement back then, by [http://www.google.com/?+WhiteGoogling for Diamond White], but this largely predates the web, so Google doesn't work all that well.
|Line 62:||Line 62:|
I'm hoping you agree.
I'm hoping you agree.
Latest revision as of 12:39, 20 August 2007
I'm Dave Cridland, with a depressingly short history within the XMPP world, but a long history within messaging - including instant messaging - and standardization. You can refer back to my XSF Application to find out more detail on this, but I wrote my first instant messaging system in the last century. You can Google for my involvement back then, by Googling for "Diamond White" BBS, but this largely predates the web, so Google doesn't work all that well.
I've tried to make intelligent comments to XEPs under development. So far, I haven't seen a gap worth filling with an additional XEP. In particular, I've concentrated on the low-level functionality, such as XEP 0198 (in order to build highly reliable and fault-tolerant XMPP streams), and bandwidth optimizations such as the recent work on XEP 0115. Although a relative newcomer to XMPP, I have implemented a client and I'm involved with Isode's XMPP server.
I've been an active member of the IETF for a number of years, concentrating first in FTPEXT a decade ago, and then, after a small lapse, moving into roaming configuration in ACAP and then Internet mail, particularly on small devices and bad networks. I started off as an individual - paying my own way to the Paris meeting - but now a certain amount of my IETF work is backed by Isode.
I have one published RFC, RFC 4731, and a few drafts, including the revision of the Lemonade Profile. I'm mentioned in the Acknowledgements section of several published RFCs. I've worked primarily in the Applications area, although I also keep an eye on some working groups in RAI (such as SIMPLE) and SEC (such as SASL). I have designed a SASL mechanism from scratch, and I'm on the Apps Review team. I've also delivered a liason from Lemonade to the OMA.
I am employed by Isode Ltd, a company which has a strong track record of developing and implementing standards.
Isode staff members have published well in excess of 100 RFCs - that's averaging over 5 per person, including LDAP, MIXER, IMAP, SMTP, SNMP, and SASL related standards track documents within the IETF, as well as having a significant presence in the development of X.500 and X.400.
Isode has recently announced its forthcoming XMPP Server, as Peter Saint-Andre commented on his blog, and therefore has an interest in promoting and developing XMPP within the XSF.
I have full backing from Isode Ltd in standing for the Council, although I do so as an individual.
What can I bring to the Council?
I feel that I bring:
- Useful knowledge of the IETF, so I could take some workload from Peter Saint-Andre in this area. (For example, I could act as Shepherd for Peter's documents, or aid in editing them).
- Practical knowledge of protocol design and standards development.
- The ability to call on Isode expertise within relevant fields. (For example, both editors of the SASL specification work at Isode, so I could request either or both of them to review relevant parts of specifications).
- A broad knowledge of existing protocols and specifications which the XSF can leverage in its own.
- The ability to promote work happening within the XSF to relevant areas of the IETF.
Although there's several areas of ongoing work that look interesting, and that the Council should promote - pubsub and whiteboarding spring to mind immediately - I would try to work within the Council to accomplish two specific items as priorities, and there's a couple of general, ongoing items I feel need looking at.
- Further Jingle. I believe, given the recent movement on ICE and other underlying technologies, that it may be possible for us to complete Jingle in this term, and it's strategically important for the XMPP community to gain momentum in this area, in order to gain market share against proprietary systems such as Skype.
- Complete revisions of the IETF base specifications. I believe we are relatively close on this. Prior to publication as RFCs, we should consider whether XMPP might be advanced to Draft Standard within the IETF, which would both improve visibility of XMPP within the IETF, and send a clear signal to the community that we believe the technology is stable - and the IETF thinks so too.
- Examine how well our standards process is working, and how it might be improved. I think it's important that we offer an effective and realistic standards process, and this needs constant reviews.
- Keep moving XEPs from Draft to Final (or Historic). Again, this is really something that ought to be happening continuously, so we need to examine how we can make this better.
- See if we can leverage existing IETF support for some things, such as the Security Directorate and Apps Review team. I've no idea how they'd react to being asked to review XEPs instead of Internet Drafts, but I'm sure it's worth trying to get broader expert review.
Why I'm standing
If there's a pattern to my standardization work, it's that a considerable amount of my work goes into enabling communication. Internet Mail is about - fundamentally - people talking to each other. ACAP is about making that easier, as well as helping people share information between each other. The stuff I used to do with the old telnet BBSs was, again, directly about letting people talk to each other. I personally think it's the single most important aspect of the Internet - all this web stuff just fails to excite me at all.
Standardization - particularly open standards - interest me because they're more secure (for a number of reasons) and lower barriers to entry - this makes it better and more accessible to the end user.
XMPP in particular interests me because it's another communication medium, one that's increasingly important - and rightfully so. I use it daily, for talking with my mother, my brother, work colleagues, friends, and IETF contacts. It's a vital protocol to me on a personal basis, as well as being a core part of my employer's strategy.
By standing for Council with the backing of my employer, I get to spend a considerable amount of time working on XMPP standardization that otherwise I'd have to do in my spare time - and being married and a father of two, there's other demands there.
In short, I have strong personal and professional reasons to want to benefit XMPP, I think I can provide clear benefits, and I think the best way of doing so is by becoming a Council member.
I'm hoping you agree.