[Foundation] Council Questions

Peter Millard me at pgmillard.com
Wed Aug 7 18:36:48 CDT 2002


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

I think the JEP process has been probably the most successful part of the
JSF process to this date. It has given us solid foundations for
documentation, good references and has given everyone a single format with
which to discuss new protocol extensions. I think that it would be helpful
if we had more participation on the standards list, or a place where more
focused discussion could take place regarding specific JEPs, but I don't
think we have a large enough developer-base for that at this time (hence the
removal of JIGs). I think that the various states a JEP can be in could be
"tweaked" to give a new jabber developer a better sense of what kind of
active development is still underway for each JEP. For example, most JEPs
are listed as "Experimental" which can be mis-leading.

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

SIP is very good at what it does, which is setting up a session for out of
band transfer. However, it was never meant to be a transport protocol. This
is what SIMPLE tries to morph SIP into. From what I can gather from the
various SIP documents (which approach biblical scale), SIP can never be
guaranteed to use TCP (various SIP components can _CHOOSE_ to use TCP, but
typically use UDP instead); because of this fact, SIP lacks congestion
control, UDP packets are the first packets to be dropped by over-whelmed
routers, and you loose the delivery semantics of TCP. In addition, you also
face packet size limitations because of the use of UDP. Given these facts,
transmitting generic XML packets over SIP would impose many restrictions
that we don't have today. Jabber _COULD_ benefit from a real "framing"
protocol which would make it easier to parse and deal with from a pure
routing standpoint, but there is no way at this point to do this w/out
changing all of the deployed servers and clients. Jabber enjoys "playing
nice" with other network protocols by using TCP and long lived connections,
and doesn't face any packet size limitations.

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

It's necessary for the JSF to develop a pub/sub protocol because there has
been a need for such a protocol, and if a standard protocol is not created,
many splintered efforts will pop up which will be incompatible with each
other. (Witness the plethora of pub/sub JEPs which have been submitted
already). Good pub/sub services and a unified protocol would allow the
jabber community to extend into application areas which have previously been
untapped because we lack the foundational pieces to build custom
applications on top of the "out of the box" jabber server. Such applications
would include: IM features like avatars and public key exchanges, auction
monitoring apps, system monitoring apps, news feeds, sports scores, etc...

I think it's important to note that there is a difference between full scale
message queueing and "traditional" pub/sub. I think while full all out
gauranteed delivery and message queueing is important, we need to address
basic pub/sub with event notification first.

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

I think the JSF needs to continue it's work with Jabber, Inc. to come to an
agreement that all parties can agree to. We need to continue to make sure
that efforts are on-going inside of Jabber, Inc. to eventually migrate the
ownership of the Jabber TM over to the JSF. This migration should only
happen once the JSF has sufficient resources (man-power and money) with
which to actually enforce the TM. TM issues are tricky because once you stop
enforcing a TM, you loose all future standing to enforce it. I would rather
have Jabber, Inc. hold the TM until we're ready to start enforcing it
ourselves.

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

This is a hard and difficult issue to solve :) I believe that one possible
solution is to have the JSF run/be a CA for all jabber servers. Then trusted
servers are those that have been signed by the JSF CA. This is similar to
how SSL works, but I think it would be important for the JSF to
monitor/handle these certs to validate that the server being run works in
accordance to various JEP's and other standards which jabber has.

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

I think it's eventually a good thing for large payloads to be delivered in
band, HOWEVER, this should be something that a server administrator can
control. Open systems (like jabber.org) which see lots of traffic could
easily get over-whelmed by allowing in band tranfers of CD ISO images :)
These payloads could be delivered today using existing servers simply by
encoding payloads so that they become well formed XML. I believe whats more
important is to define standards which clients can implement to decide on
HOW to transfer a file, and make OOB transfers be the preferred choice. In
band transfers are really essential in allowing users to send files from
behind firewalls. This is one of the biggest issues people have with IM
systems (not just jabber). Jabber's ability to "punch through" firewalls
makes it uniquely suited to excel in the file transfer space and compete w/
other IM systems.

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

Jabber is (and should always be) XML based. In my opinion, this is where the
"user friendliness" lies. There are lots of XML tools to use off the shelf,
and it is easily extensible. XML also allows clients to be only as "smart"
as they need to be to perform and be implemented. For example, a jabber
client does not need to implement all possible protocol extensions to be
fully functional. The jabber protocol should always try to maintain the
existing set of core protocol elements, and add new namespaces when new
functionality is needed.

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

Working hand in hand with any IETF standards movement is essential for
driving the ubiquity of jabber forward. We must be active participants in
these standards efforts to make sure that the true spirit of jabber is kept
alive and kicking. We should try to embrace new-comers into the jabber
community, whether it be individuals or entire standards bodies (like the
IETF). Jabber's simplicity is what has gotten us to the point where we are,
and we need to make sure that standards org's don't "corrupt" that
viewpoint.

pgm.




More information about the Members mailing list