[Foundation] Iain Council Questions Answers

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Aug 7 10:57:01 CDT 2002


Here's my 2 cents on the issues. :)


> 1. What do you think is working and not working with regard
> to the JEP process? What suggestions do you have for improvement?


JEPs are focusing discussions.  It is moving issues along well known
processes towards "standards status".  Good ideas aren't getting lost due to
a "what do I do now" problems.

Forcing people to produce strawman proposals (JEPs) helps turn ideas into
concrete terms that can be debated and voted on.

Not working

Losing the forest in the trees - the focus on particular protocols
(individual JEPs) has drawn attention away from the big picture.  How
individual protocols interact and exploit each other is getting lost.  The
original cohesive design is starting to fragment.

Slow - for open source it is taking too long to pass JEPs.


The council should be moving the JEPs through the process.  The first
council was hamstrung with the normal startup problems.  The next council
needs to push for faster adoption (stress evolution of standards so the fear
of passing JEPs doesn't prevent fast approval).  I'd also like to see more
work/emphasis either in the council or in the community in holistic design
of Jabber as it evolves.  Individual JEPs are fine but it is essential that
they are shown in the context of the overall Jabber system.

> 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?

I don't know much about SIP/SIMPLE so can't really answer.  I'm not entirely
sure however that the current Jabber system is the best way to transport
XMPP packets.  I'm definitely looking for alternatives in JNG.

> 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?

Pub/sub could form a unifying messaging model for Jabber.  It is possible to
design everything as applications of pub/sub.  This can have great
advantages for implementing a scalable, reliable, easy to understand system.

I'm also hopeful that a unified pub/sub design could help unify security by
tying security to the pub/sub foundation.  This would allow the protocols
built on top of the foundation to inherit its security.

A good answer to the question of how it fits in with the existing protocols
and how an application built on it may look is a bit beyond a short answer.
I would point to the Java Messaging Service (JMS) systems like SonicXQ
(www.sonicsoftware.com) for a flavor of what I'm envisioning.

> 4. How do you think ownership of the trademark on the Jabber
> term should be handled?

Jinc owns it and can use it.  The real issue in my mind is the fact that
Jinc appears to be straddling the fence trying to encourage its use by the
community without giving away the trademark.  I say they should either keep
it and use it commercially, or donate it in full to the community.  Either
would be acceptable, I just wish they would do it sooner rather than later.

At some point, if they don't make a decision, I think it is imperative for
the community to simply create a new free name for the protocol so we can
move on to more important issues.

> 5. How do we establish trust between servers on an Internet scale?

Through reputation.  I think it has to work the way email servers do.  You
trust or don't trust a server based on how paranoid you are, and the
reputation or past behavior of the server administrator.  For the paranoid,
establishing trust through out of band channels is the only way to go.
Probably PKI using established CA such as Verisign certificates.

> 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 sufficient, how do you see
> that as different from SIP?

I think there should be a standard option for doing so (an optional
protocol).  I don't believe any server should be forced to support in-band
bulk data transports in order to comply with Jabber standards.  Alternative
out-of-band protocols should also be standardized but optional.

> 7. How can the growing complexity and functionality of the
> Jabber protocol be balanced with simplicity and
> developer-friendliness?

We need to move feature negotiation (disco) to the forefront of the protocol
and make the process simple to support.  I'm a bit reluctant to back the
full scale browsing protocol being promoted in the disco JEP for this
purpose.  I think it is too complex for the task of creating a simple,
developer friendly feature negotiation protocol.  I would suggest that we
need a simplified, bootstrap, feature negotiation protocol designed so that
it is very simple to implement.  Disco can then be used later on (support
for it is a feature to be negotiated).

I like the way Wireless-Village (www.wireless-village.org) does bootstrap
feature negotiation.  In their system, you can hard code support for your
particular client, making it trivial to implement in the trivial case (easy
things are easy).

> 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 protocol?

I think IETF standardization is important.  I don't know whether the timing
is that great but I think it is essential.  As Jinc has been willing to
spearhead the effort, I don¹t see any problem with riding their coat tails
and getting larger standards work going.  If Jabber is to move out of
strictly IM, it will have to use larger standardization bodies to do it.


More information about the Members mailing list