[Foundation] I wish there was no Foundation

David Waite dwaite at jabber.com
Fri Jun 29 21:43:38 CDT 2001

----- Original Message -----
From: "Iain Shigeoka" <iainshigeoka at yahoo.com>
To: <members at jabber.org>
Sent: Friday, June 29, 2001 9:50 AM
Subject: RE: [Foundation] I wish there was no Foundation
> Against
> The reason I wish there was no Foundation is the risk (I think HUGE risk)
> that the Foundation's bureaucracy is going to hamstring Jabber innovation
> just at the time when Jabber must be the most fluid and quick to
> react.  Now is the time for a strong dictator to make hard decisions
> quickly and concisely.  I have a feeling that this kind of leadership is
> going to be impossible with the Foundation.
> For example, what if we decide that some critical advancement requires
> completely restructuring major parts of the Jabber protocol?  These
> are necessary for moving forward.  With the Foundation, it must go to a
> JEP, get a JIG, get discussed, have a reference implementation built, get
> voted on, etc etc.  These delays can add up if several changes must occur
> at once but the Foundation process requires them to occur in series (for
> proper discussion and exploration of consequences).

Of course this is all my personal opinion, but..

I would actually say this is *required* for a major change in the Jabber
protocol. Most of the protocol decisions have come down in the past to a
consortium of five people, without even having a mechanism for public
feedback. If you start having large-scale commercial involvement with
Jabber, you can't simply say 'things will now work like this' and expect
people to react - they will ignore you. Without a compliance test, there is
also the huge risk that people will add large, incompatible changes to a
commercial server implementation and insist that even without compatibility
or documentation, the thing should be called 'Jabber'.

You need a way to have the community at large, including all parties with a
vested interest to decide a large-scale change is best. If this takes
longer, that is ok. But the other way simply didn't work; people would get
angry when all of a sudden some protocol feature was replaced out of the
blue. Other parties would add new namespaces for communication and have no
method of indicating this to other people for compatibility.

> And how flexible will the foundation process be in allowing such major
> rewrites?  As an example, I have been thinking about the current JID
> format.  Every way I turn it, there does not seem to be any reason to have
> a JID address that contains resource information.  The function it is
> trying to serve (multiple devices for a single logical "user") does not
> seem to warrant having the resource in the JID... except perhaps in the
> that the current jabberd server implementation uses this information for
> internal routing.  But this implementation issue should be kept clear from
> the standard... If I submit a JEP to remove the resource from the JID how
> quickly can I get this through (if ever)?  What if one member of the
> council that loves the idea of the resource in the JID sits on a -1 for a
> few weeks while trying to turn around public opinion (e.g. politics)?

I think it would wind up being the decision of the membership at large if
they wanted changes such as this to be wrapped up in an evolutionary or
revolutionary change in the Jabber Protocol and existing implementations.
Several things that can be proposed and which IMO would greatly help the
overall robustness of the server would basically break every client out
there. Without an agreement among the parties involved, I would say that
this would never get done. I would also say that up to this point, there
haven't been enough commercial companies interested in Jabber for this to be
a problem. This won't hold up for long

And yes, I would argue that the resource is still needed for representation
within non-User systems. For instance, it would be very difficult to
represent conference rooms in any protocol without resources, as well as any
sort of directory-based discovery method. For email-like functionality, you
don't want resources; but for something like http, it would be next to
impossible to have a functional website without the ability to distinguish
resources within the entity. It could be argued that the current system has
considerable flaws in representing multiple resources, but you would need
considerable justification to change the existing system - that would go
with or without a Foundation.

> I think eventually the Foundation will eventually work things out and the
> "best" decisions will be made.  My worry is simply how much of a delay is
> this going to incur.

Just to summarize what I said above - I think that making these sorts of
decisions will be slower than before, but hopefully the end decision will be
much futher documented out, thought out, argued and agreed upon. And with
large, evolutionary decisions, having an open process for deciding these
things will reduce the chance of someone who didn't have voice in the
process from forking at the protocol level.

-David Waite

More information about the Members mailing list