[Foundation] Council Questions
theo at theoretic.com
Tue Aug 6 23:30:50 CDT 2002
First I'd like to say I much prefer this way of doing debates through
the members list instead of a live chat. It really allows for more
> 1. What do you think is working and not working with regard to the JEP
> process? What suggestions do you have for improvement?
One idea that has occurred to me while reading so many JEPs in the past
few weeks is that the format should be better standardized. What I mean
is that there is an amazing difference in the styles in how examples are
done (some JEPs use SEND & RCVD to designate what entity is speaking the
example, others use S & C, some don't even use anything), if the
document is structured along use-cases or features, some read like RFC's
while others use stream-of-consciousness.
While it may be argued that JEPs are all written by different people
(which is a good thing!), I believe that there should be standards or at
least guidelines on the "style" of JEPs, covering such above issues.
I would also like to see a seperate process for deciding Foundation
process and management changes, like the JEP process, but non-protocol.
> 2. From a purely technical standpoint, what differentiates Jabber from
> SIP, SIMPLE, and related technologies? Why (or why not) is XMPP a better
> choice for many applications than transporting XML/MIME payloads via SIP?
As others have pointed out, SIP (and therefore SIMPLE) are
plaintext-based. However, I would like to point out this makes them much
less manipulatable than Jabber. One of the strengths of XML is that it
can be easily converted and altered into other text-based formats, as we
easily see with Jabber's Transports to other IM systems. Even
transporting XML via SIP is not as good a solution because you would not
have important meta-data as XML to be easily converted into those
> 3. Why do you think it is necessary to develop a pub/sub protocol for
> Jabber? Please provide specific examples. In particular, it seems that
> there should be some useful synergy among pub/sub, message queueing, and
> presence. How do you see this fleshing out in specific applications?
A powerful, flexible pub/sub mechanism is necessary to Jabber's growth.
I'm not talking about something that acts merely as a newsfeed solution,
but something that can potentially replace groupchat, presence, mailing
lists, and newsletter subscriptions. With that, Jabber can be applied in
a wide variety of corporate and industrial environments in creative and
unique ways. Executives and IT departments would thank us.
> 4. How do you think ownership of the trademark on the Jabber term should
> be handled?
It should eventually be purchased from Jabber, Inc at a fair price by
the JSF when the JSF deems itself to be able to protect and promote the
> 5. How do we establish trust between servers on an Internet scale?
I think this is a sticky issue. I have heard PKI, I've also heard Web of
Trust, I've also read Mike Lin's good suggestion about PKI with Web of
Trust, but I think ultimatly it will need to be something which does not
enforce a client/server model, allowing the Jabber protocol at least to
remain open to the possability of a p2p architecture in the future. PKI
may be good as long as it not forced to come from the server in the
user's JID or mandated to come from the JSF or "JANA".
> 6. Do you think we should build a mechanism for in-band transport of large
> payloads within Jabber? If not and you think an out-of-band transport is
> sufficent, how do you see that as different from SIP?
Yes! Jabber should be built with low-level functionality in mind, able
to potentially do everything without relying on outside transport
protocols. It should of course remain very modular, allowing people to
use and support only what they want to.
> 7. How can the growing complexity and functionality of the Jabber protocol
> be balanced with simplicity and developer-friendliness?
I think the best way is to find the bare-bones lowest common denominator
as Mike Lin said. But that is only half the solution. <plug
topic="Jabber Environments" xmlns="http://theoretic.com/?Jabber_2.0">We
also need a way to organize and categorize the higher-level
functionality that will exist. This should be done with Jabber
Environments, which are neat, labeled packages of features,
requirements, and protocols that run on top of the bare-bones Jabber
platform. Also, a reasonable set of open protocols should be designed to
provide low-level functionality such as authorization, pubsub, feature
discovery, and others that is often duplicated in many other protocols.
You can learn more about this at http://www.theoretic.com/?Jabber_2.0
> 8. How can the JSF and the Jabber technical community best work with other
> standards organizations, specifically the IETF and any possible Working
> Group the IETF forms to to pursue standardization of the core Jabber
I at first opposed the IETF effort because I see the IETF "community" as
fairly incompetant when it comes to designing protocols. Many of their
products have a very "designed by committee" design, and have more or
less failed because of it (BEEP, SIP, APEX, and many others that
promised much, but no-one bothers to impliment).
I have realized that my past bad experiences are likely just my own, and
others are very eager and happy for the IETF to take change control over
the core of the Jabber protocol. And while I do feel there is an
established developer base and bias at the IETF that may not be good for
Jabber, I feel confident now that with so many Jabber developers
interested and hopefully active in the process, the protocol will not be
taken in a destructive or suicidal direction.
I do feel, however, that the IETF should not be high on our priority
list. There are so many other more important issues we need to resolve
first before spending energy with the IETF. Documentation needs serious
work, client and server code bases need to be matured, and more sponsors
need to be found for the JSF.
I don't believe that the IETF would do Jabber much good, either. Jabber
already has more than the IETF could ever provide: a strong developer
community with an amazing range of implimentations under a wide variety
of licensing terms, programming languages, and computing platforms. This
is something that many IETF-created protocols never have ever come close
to managing, notably BEEP, SIP, SIMPLE, and APEX, among many, many
others you can find by just browsing the list of IETF WG's. We also have
a kick-ass protocol that has been built through trial and error, tested
in the real world.
Companies are already accepting Jabber, and all it takes for bigger and
badder companies to jump aboard is a powerful advocacy effort that
wouldn't even take any $$ to finance. That is why I'm running for the
Board as well, BTW, to build this strong advocacy effort on our own.
Now, as Mike Lin has also pointed out, this doesn't mean the IETF effort
should not be done. I realize that now. It just means it should not be
high on our list while so many other issues of much greater importance
/me steps off the soapbox.
/\ Adam Theo, Age 23, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ Pager: (850) 709 7738
// || \\ Theoretic Solutions: http://www.theoretic.com
|| "Building Ideas by Bringing them Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Next Generation Communications Protocol"
|| "A Free-Market Socialist Patriotic American Buddhist"
More information about the Members