[Foundation] Council Questions

Robert Norris rob at cataclysm.cx
Wed Aug 7 20:11:50 CDT 2002

Better late than never :)

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

The JEP process, for the most part, seems to be working well. Having a
publically-available list of things that people are working on and are
interested in is a huge help, and addresses the problem we had where
noone knew what anyone else was doing. It also helps to ensure that good
ideas don't just disappear into the ether, but instead get recorded and

I think that usefulness and quality of JEPs can be improved by making
sure that approved JEPs are far less ambiguous about their exact
functionality and requirements. Even just the usage of common words (ala
internet drafts - MAY, MUST, SHOULD, NOT, etc) would be a good start.

The other thing that would help is better specifying relationships and
dependencies between JEPs. Of course, this will be much easier once
certain essential protocol extensions are completed, such as
disco/browse and pub/sub.

Both of these points have been addressed on a somewhat ad-hoc basis in
certain JEPs, but there should probably be a much greater emphasis on
this for future JEPs.

> 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 will admit that my knowledge of SIP and SIMPLE is somewhat sketchy,
mostly because I haven't found a good overview on the subject, and I
can't stomach the ~250 pages of SIP spec.

However, as I understand it:

 - SIP is, as its name suggests, used for the creation and management of
   logical sessions between two entities. It is intended to be a control
   protocol - the actual data transmission is handled by other means.
 - SIMPLE is a hack on top SIP to provide instant messaging services. It
   does this in-band (ie as extensions to the control protocol).

So, if we were to use SIP to transmit XML payloads, we would have three

1. Use SIP to negotiate sessions, and use some other mehanism to
   transport the XML payloads themselves.
2. Use SIMPLE, and encapsulate the XML payloads in some way (how, I'm
   not sure - I don't know enough about SIMPLE).
3. Create our own extensions to SIP (much like SIMPLE) which are
   explicitly for transporting XML payloads.

Option 1 seems somewhat redundant, since we'd have to establish
something akin to an XML stream, and we already do that in XMPP anyway.
Option 2 is probably not ideal, because we'd be hacking a solution on
top of SIMPLE, which itself is a hack on top of SIP. Option 3 is
redundant, since we'd effectively be reproducing SIMPLE, and still using
SIP for a purpose that it was never intended for.

Also, its important when deciding between XMPP and something else to
consider that XMPP has several solid server implementations, client
libraries for most languages, and a large installed base. It's also
quite simple to get started with, and program for. SIP can claim none of

However, there are places where SIP (or a similar protocol) could be
useful withing XMPP - P2P file transfer being one of them. However,
because of the complexity of SIP, we're unlikely to see implementations
in clients anytime soon. However, we can probably learn things from SIP
when considering the type of tasks that it is suited to.

> 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 pub/sub system is effectively a mechanism for sending broadcasts, that
is, sending a single object to meny recipients at once. This is useful
for many applications:

 - Conferencing
 - News feeds
 - Event notifications
 - Presence
 - Distribution of user data (avatars, public keys, etc)

In fact, normal one-to-one messaging can be considered a broadcast as
well - one with a single recipient. In this way, the entire architecture
could be refactored in terms of pub/sub, which is an interested idea.

As for message queuing, I'm actually not familiar enough with the
concept (though I can imagine what is probably meant) to be able to
comment on it. However, lets not try to do everything at once - we're
already bogged down in debate about pub/sub. We should try to get
something simple and extensible standardised, and then work from there.

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

As others have said, this question relates more to the Board than to the
Council. However, I personally think that the trademark should
eventually be administered by the JSF, but not yet - we simply do not
have the resources for it at this time.

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

Global trust is next to impossible - how do you establish trust between
humans the world over?

Obviously some kind of global database that every server agrees on is
necessary. Currently, we use the DNS for this purpose. It would also be
quite easy, implementation-wise, to use certificates from a trusted CA,
a web of trust, or something else.

Ultimately though, the question of trust comes back to the server
administrator. Who do you trust? When a server called jabber.org
connects to your server, it sends you messages from its users, which it
trusts. However, if you need to decide if you trust jabber.org to make
that assertion. In a similar way, you need to decide if you trust the

Ultimately, we can only provide the mechanisms for establishing trust
between parties. We are unable (at some level) to actually decide who is
trustworthy, because that requires server administrators to trust our
ability to make that judgement, which they may not.

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

Honestly, I don't know. There are pros and cons for each. The obvious
advantage of transporting large payloads in-band is that the (logical)
connection to the recipient is already established - there are no
additional hassles with firewalls and such, except those that already
affect the normal connection.

However, transporting large payloads in-band means that the client's
connection to the server is effectively blocked until the transfer is
complete. On slow links this can be a problem. Also, it requires more
intelligence in the server to handle large packets, since it is
sub-optimal to run the XML parser across the entire packet. This is an
implementation detail, of course, but it does need to be considered.

Of course, it is difficult to develop a scalable and portable
out-of-band transport, because of the various types of networks that

In all honesty, the existing mechanisms that some clients have
implemented using HTTP is quite elegant, I think, since HTTP is a file
transfer protocol. Of course, there are problems with proxies and
firewalls, but does this matter? Organisations put firewalls and proxies
in place for a reason - should we be delaying our standardisation process
until we can figure out a way to circumvent them?

As to the question of using SIP for out-of-band transport, I'll make the
same point I did earlier - SIP may be useful for negotiating a
connection between two clients for the transport of a large payload,
however, SIP is not a transport protocol, so something else would be

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

Mostly by being careful. When we design extensions to the protocol, we
need to consider the impact it will have on other parts of the protocol.
In particular, we should strive to maintain keep the requirements for
the Jabber protocol as simple as "a TCP connection and an XML parser."

And in the event where we do need to change some fundamental part of the
protocol, or make a particular extension a requirement, we need to
carefully consider the effects that such a change would make.

And of course, good documentation is the key. We're in the fortunate
position of having a protocol that _is_ simple and friendly. It also has
the bonus of being quite difficult to stuff up. By documenting any
quirks or inconsistencies, and documenting them well, we ensure that
they will continue to be understood.

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

As I've said before, I think that standardising the protocol under the
IETF would be a good thing. Despite what people's personal feelings
about the IETF are, noone can dispute that they have a wealth of
knowledge about protocol engineering, particularly in the areas where we
lack (such as security).

Additionally, the IETF has corporate mindshare. To get the
mega-corporations to notice Jabber, it needs to have the IETF stamp. The
JSF alone, while we do work hard and produce some good things, simple
doesn't have the strength or the influence to make a difference. Maybe
this will change in the future, but we don't have the luxury of waiting -
eventually, the IETF will standardise an IM protocol, and if its not us,
then we remain in a niche.

Interesting questions people - thank you :)


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/20020808/43f2aa23/attachment.pgp

More information about the Members mailing list