[Foundation] Iain Shigeoka Candidate Position Paper - 2002

Iain Shigeoka iain.shigeoka at messaginglogic.com
Mon Jul 22 12:34:45 CDT 2002


Position Paper for Iain Shigeoka

Introduction and Biography

Hello Jabber community.

This position paper briefly describes myself and outlines what I hope to
accomplish during my term as Jabber council member if elected.

I have been actively involved in Jabber for about a year now, primarily in
the standards process.  My principle interests are in security and
"enterprise" uses of Jabber technology.  I am currently a Java software
developer and author.  I recently published a book on programming Jabber
systems in Java (http://www.manning.com/shigeoka).

In general, I feel Jabber is headed in the right direction.  However, I
believe strongly about several unresolved or neglected issues that I hope to
address.

Major Issue

I have one primary area I would like to focus on if elected.

JABBER: NEXT GENERATION

There has been much discussion and subsequent tabling of any work on a next
generation Jabber protocol (JNG).  I realize that many people are highly
focused on where Jabber is going tomorrow and meeting customer needs today.
However, I strongly feel that serious work should begin on discussing and
defining JNG.

As a council member, I would like to push an agenda of parallel, active
development of JNG while the current Jabber standards process continues to
refine and expand the current Jabber framework.  I have some potentially
controversial views on what JNG could or should be and am interested in
discussing and developing JNG.

I anticipate that most council members will be focused on the short term
standardization and refinement of Jabber.  This is essential for Jabber to
continue to grow and develop.  However, I think it is crucial that we begin
to think about where Jabber will be going next.

Lesser Issues

JABBER ENVIRONMENTS AND STANDARD CONFIGURATIONS

With the new proliferation of standards, I think new developers are bound to
face a daunting challenge in identifying and selecting the "correct" mix of
standards to implement in any particular piece of Jabber software.

In addition, I believe there is potential for a broad mix of interaction
problems with all Jabber standards being "optional" as defined today.  I
have personally run into this as readers of my Jabber book have used the
included minimal Jabber software in a mix of configurations ("standard"
Jabber clients connecting to the the book's minimal Jabber server, the
book's minimal Jabber client connecting to the jabberd server, etc).

I think that part of the JEP process should be an increased effort to define
"Jabber Environments" as proposed by Adam Theo (another council member
candidate).  Jabber Environments sets well-defined suites of protocols that
should be supported by Jabber implementations in order to comply with a
certain "Jabber Environment configuration".  This can't be handled by disco
or similar protocols since disco itself is optional at this point.

I also believe that Jabber Environments or a similar standard configuration
effort will also help to reduce the confusion surrounding what protocols
should be implemented, how they should interact, and what one should do when
a client with one environment logs into a server that supports another.

JABBER DOCUMENTATION

The focus on JEPs has been great in moving Jabber standardization forward
and has resulted in better documentation.  However, I think this focus has
been detrimental to the overall Jabber documentation effort.  The Jabber
client writer guides have been neglected and the overviews of the Jabber
protocols (especially the core protocols) have fallen out of step with the
reality of implementations.

I would like to drive some effort back towards documenting the Jabber
protocols as a whole (perhaps taking the IETF submissions and expanding upon
them).  In addition, I think revising a Jabber client writer's guide is
essential to keeping Jabber development active and open.

NEW JABBER DEVELOPMENT

I think the current focus on Jabber development around a single C server
implementation (jabberd) has been helpful in keeping Jabber implementations
interoperable.  Now that the JEP process promises to better define and
standardize the protocols independent from any particular implementation, I
feel it is important for the Jabber community to create other
implementations of the server.

My initial thinking is that a Java Jabber server would be a significant step
in widening the reach of Jabber and provide useful feedback on what features
in the current Jabber server implementation are implementation specific and
which are standard features that should be documented as Jabber standards.
Whether such a server effort would be best applied to the current Jabber
standards, or part of the JNG work would be something I'm very interested in
discussing with developers.

Conclusion

Thank you for your time. I welcome your feedback on my platform, and I
strongly encourage you to vote in the forthcoming election.

Iain Shigeoka




More information about the Members mailing list