[Foundation] Position paper: Robert Norris

Robert Norris rob at cataclysm.cx
Wed Jul 24 18:21:14 CDT 2002


This is also available at http://cataclysm.cx/jabber/jsf-position-2002.html,
for those who prefer glorious colour. :)

Rob.


Background

My name is Robert Norris. I'm 22, recently married and residing in Melbourne,
Australia. I work for a major university, as the system administrator of
messaging (email, news) and scheduling (calendaring) services for staff and
students (some 80000 users).

I originally got involved with Jabber shortly after the v1.4.1 release, and
spent some months teaching myself the details of the server architecture, and
writing several server modules in the process.

Since then, I've become involved in the protocol standards process, and am the
co-author of a number of JEPs, including the SASL profile (#34). I'm also
heavily involved in the development of jabberd 1.5.

For more information, I have a website of Jabber-related things at http://
cataclysm.cx/jabber/. There is also a JSF interview with me (available at http:
//www.jabber.org/people/interviews/robnorris.html) which further outlines my
involvement with Jabber.


Primary issues - publish/subscribe and service discovery

The JSF has done a great job in the past year. We've developed and refined
processes for standardisation; we've discussed and documented much of the
"core" protocol, as well as producing a number of Internet Drafts. The protocol
is fairly stable, and the few places where it is ambiguous are rapidly being
identified and corrected.

Now that our documentation has caught up with the implementations, its time to
move forward. As people are quickly beginning to see uses for Jabber outside of
IM, they are running into two stumbling blocks:

  * lack of a publish/subscribe mechanism
  * lack of a service discovery mechanism

These two mechanisms are essential for Jabber to progress any further, and many
people have realised this fact themselves. We have four proposals related to
publish/subscribe (JEPs #21, #24, #28 and #36), and two related to service
discovery (JEPs #11 and #30).

(Admittedly, JEP #11 is informational and has been approved, but there is much
debate as to its suitability for many applications).

There has been a lot of discussion on both of these topics, and much of what
has been discussed has been incorporated into the various JEPs. However, I know
from experience that discussion can go on forever without a decision ever being
made.

Both publish/subscribe and service discovery protocols are being used today,
even though the standards are in draft. JEP #24 has implementations and is
performing well, from what I hear. Browsing has been implemented in many pieces
of software, including jabberd. It is my firm belief that the time for
discussion is over, and we must now make a decision and approve protocols for
each of these systems. That may mean that people will have to set aside their
pet feature for the moment, in favour of getting something out of the door.
Without both of these protocols in place, the future for Jabber protocol
development is severely limited.

If elected to the council, my initial goal will be to get these protocols
standardised.


Secondary Issues - environments and advocacy

Once we have standardised protocols for publish/subscribe and service
discovery, there will be considerably less pressure on the JSF to produce
standards, which will give us a chance to consolidate somewhat.

As part of this, I would like to see work on the specification of
"environments", that is, sets of protocol elements (namespaces) that are
required to be implemented by a node in order to be classified as a particular
type of service (eg "client", "transport", "server", "lightweight server",
etc). Whether this is something formalised (eg Adam Theo's Jabber Environments
), or something simpler, such as the namespace tables proposed early in the
JSF's life, I don't know at this point.

However, I think that once these specifications exist, it will be substantially
easier for developers to know what protocols they should support. It should
also ensure that implementations act in similar ways to each other, necessary
to prevent fragmentation of the protocol.

In addition to this, I'd like to have a hand in producing more higher-level
documents that help inform the world at large as to what exactly Jabber is
about. People need to know how Jabber can help them and why they should use it
over some other system. This goes for specific applications such as IM, and for
more generic middleware-style applications.

I've learnt from various discussions and articles that there is outside
interest in Jabber, but there is also alot of misunderstandings about it. While
I (and others) work hard to dispel the myths, I believe a more unified and
coordinated approach is required. I would like to be involved in the
coordination of such an effort.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://jabber.org/pipermail/members/attachments/20020725/bad8d5e4/attachment.pgp


More information about the Members mailing list