[Foundation] David Waite Council Question Answers

David Waite mass at akuma.org
Tue Aug 6 23:34:10 CDT 2002

  Peter Saint-Andre wrote:

>Council Candidates:
>Here are the debate questions submitted so far, sorry for sending them out
>late in the day. You Council candidates have until next Wednesday to
>answer them. (Yes, I know, the message from reatmon said there would be
>only 6 questions but since 8 came in I figured I'd post them all. Note
>that I've rephrased/shortened a fwe of them...)
>1. What do you think is working and not working with regard to the JEP
>process? What suggestions do you have for improvement?
Most of our processes have been fine, except for lack of participation. 
I preferred the original 'JIG' formation to be honest. because it 
encouraged more discussion before an initial proposal was put in front 
of the membership at large. It also could stand to reduce conflicting 
work, such as we have with the plethora of pub/sub JEPs.

As far as improvements go, we need to:
1. Establish a plan of what we would like to see created and 
standardized over the course of the next year
2. Encourage constructive discussion around individual concepts and 
3. Increase participation of the technical council in these discussions. 
The council should be comprised of people who are agreed upon as being 
most capable to lead the technical direction taken by the JSF, and 
should have an obligation to fill that role.

>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 a signalling protocol - for the purpose of out of band 
transmissions, SIP is an equivalent choice.

XMPP is a better choice when actually communicating data, as you cannot 
be guaranteed that SIP is using TCP as a transport mechanism through the 
whole delivery path.

MIME vs. XMPP is really comparing apples and oranges. MIME would provide 
a strong separation between routing and  content, whereas with XMPP the 
routing _is_ content, and the overall protocol imposes limits on the 
content which can be transported over it.

>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?
The neccessity of pub/sub for Jabber lies in the neccessity to 
communicate to groups rather than one-on-one. Some examples of 
communcation which may benefit from pub/sub:

-extensions to presence like 'currently listening' music notification 
and avatars
-multi-user discussions
-multi-user environments like a groupchat, forums, or bulletin board system.
-news feeds
-group calendar notifications

Presence itself could become exposed via a new pub/sub system, if it 
were not already exposed under its own mechanism already. However, 
extensions to presence should be pushed over a pub/sub system so that 
the information is only sent to interested parties.

A Jabber pub/sub system will be decidedly different than most other 
pub/sub systems, as they are mostly based on MOM 
(Message-Oriented-Middleware) concepts. Because of the lack of any 
delivery guarantees in Jabber, the published messages may not be seen by 
a client for any number of reasons. For example the client may be 
offline, or the link between servers may go down.  

I believe the final pub/sub proposal will need to suggest or implement 
workarounds for these delivery limitations in order to provide an 
environment where applications can comfortably work.

>4. How do you think ownership of the trademark on the Jabber term should
>be handled?
I think it should be handled by the Board, and not by the technical 
council. I have my own feelings on the issue, but nothing changes from a 
technical standpoint which cannot be solved via a regexp.

>5. How do we establish trust between servers on an Internet scale?
That really is a matter of what you are trusting them for.

Its usually safest to assume that for methods of communication not 
secured via a shared secret, web of trust, or a trusted third party, 
your communication can be intercepted and read, and possibly changed. 
Encrypting and signing messages is one way around this, securing the 
transport layer is another.

If your communication MUST be secure, one of these mechanisms is 
required. Most communication does not need to be secure against active 
attacks, nor does it need to be kept safe from eavesdropping.

So first response is "we don't". Endpoints need to determine whether 
they trust the identity of other endpoints, and to properly secure data 
flowing between them. This is the mechanism which scales best, and
requires the least number of trusted third parties. We need to make sure 
we provide the framework so that the individual endpoints can decide 
what level of security they need and adapt to that level.

Things such as limiting the connection mechanisms for clients and 
servers, as well as limiting the servers which your host can connect to 
is a mechanism for the server administrator to enforce the policy of the 
organization hosting the particular service. I have yet to see a reason 
to expose this sort of information to applications on top of the system.

>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?
It would be nice to be able to transport large payloads, as well as 
non-XML data. To efficiently route this information will require a large 
amount of complexity in the client, and to efficiently transmit this 
information within Jabber probably will require fundamental changes to 
the protocol.  

In the end, it becomes a matter of deciding if expanding the vision of 
Jabber as an XML-based asyncronous messaging protocol to one allowing 
larger and/or non-XML messages is worth the complexity and level of 
required changes, just as the original vision has slowly been expanded 
from one for 'just' Instant Messaging.

SIP (the Session Initiation Protocol) is just as good as Jabber for 
initiating out of band transfers. The reasoning for providing a method 
_within_ Jabber for creating these sessions is to not require clients to 
also support the quite non-simplistic SIP for simple file transfer.

>7. How can the growing complexity and functionality of the Jabber protocol
>be balanced with simplicity and developer-friendliness?
It is still just as simple to connect to a server running Jabber and 
send a message out as it was two years ago. Growing functionality will 
always require developers to write more code to support that 
functionality. The ways we can make that simpler are quite simple

1. Don't "require" new features unless it is considered absolutely 
neccessary. For example, once we have settled on a feature negotiation 
protocol, we can still say that it is optional and that the default 
behavior of a client on receiving a feature negotion request - returning 
501 Not Implemented - requires the other client to assume lack of 
support for all non-core features.
2. We have three new features on the table now which will be used most 
additional functionality in the future - feature negotiation, 
introspection/discovery, and publish/subscribe. We need to make sure the 
proposals we standardize on for each of these are simple enough that 
they can be widely implemented, but extensible enough that we will not 
need additional protocols for each in the future.

>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
If the JSF membership decides it is worth supporting standardization, 
the knowledge of the technical community will be the greatest aid we 
could provide. Making sure the technical council and 
standards-interested members participate in and offer their knowledge to 
any working group will help in guiding such a standards effort.

-David Waite

More information about the Members mailing list