[Foundation] Julian Missig's Candidate Position Paper 2002
julian at jabber.org
Tue Jul 23 00:58:20 CDT 2002
I have posted my position paper at
It is highly recommended that you view my paper at the above address if
a capable browser is at hand. It comes complete with links, emphasis,
and decent formatting. However, for convenience, here is a plaintext
version (no need to read this one if you visit the above address):
1. Who Are You?
My name is Julian K. Missig, but I am often known as x-virge. The
rumors are true, I just graduated high school and will be attending
Carnegie Mellon University to study psychology starting this fall. I
joined Jabber around server release 0.7 to help out with the protocol
and make Jer more correctly support XML Namespaces. Somehow I have
managed to stick around ever since.
2. Work History
I spent quite a bit of time as a web site designer/developer, so
design holds a special place in my heart. It was through my interest in
XML that I found Jabber and helped correct some issues with compliance.
I currently am employed by IBM as a Software Engineer.
3. Area of Contribution to Jabber
My primary area of contribution to Jabber has been with the
protocol. The past two years I have been better known for Gabber, which
I helped Dave Smith create and then took over when he left. My name is
on several JEPs, and I can be blamed for XHTML Basic finding its way
into Jabber messages.
4. Primary Issues
First and foremost, I would like to see the Browse v. Discovery
issue resolved. We must pick one of the two and make it into the
standard requirement for all Jabber nodes. I feel this is crucial for
Jabber to move forward.
The publication/subscription problem should be resolved. I have
seen great uses for publication/subscription, and things such as music
information and avatars simply cannot be implemented properly without
it. In order for Jabber to become accepted by any members of the general
public, we do need to have some focus on features such as these.
After these two issues are resolved, the ideas formulated in the
Standards Jabber Interest Group for namespace tables should be further
investigated. Creating tables of which namespaces should be supported
for a "Lightweight Jabber Client" versus a "Jabber Transport" will give
implementors a starting guide and assist greater consistency across
5. Secondary Issues
While the current Jabber protocol is pretty good for what it
does, the protocol must move forward. Simply getting up and writing a
whole new protocol then expecting everyone to move to it is unrealistic,
while retaining full backwards compliance will keep us back. I think we
should take an approach somewhere in the middle--slowly incorporting the
new ways of doing things while phasing out the older ways. This is the
only way that I can see us keeping our current userbase while purging
ourselves of early mistakes.
One of the first "new ways of doing things" I would like to push
is proper support for XML Namespaces. My first steps with XML Namespaces
were just to ensure that Jabber does not completely break the
specification. However, this is far from good enough now that more and
more applications are using XML. Parsers now exist which can properly
handle namespace prefixes and all the other oddities of the full XML
Namespace specification. Properly supporting XML Namespaces will help
those who are coming from other XML communities use Jabber, and in turn
help us gain support from those communities.
Last modified: Tue Jul 23 01:11:31 EDT 2002
email: julian at jabber.org
jabber:julian at jabber.org
More information about the Members