[Foundation] Julian Missig's Candidate Position Paper 2002

[Julian Missig]

I have posted my position paper at 
http://missig.org/julian/jabber-position.html

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):


Julian Missig

    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 
platforms.


    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.

Julian Missig
Last modified: Tue Jul 23 01:11:31 EDT 2002
-- 
email: julian at jabber.org
jabber:julian at jabber.org