[Foundation] David Waite Council Question Answers
mass at akuma.org
Tue Aug 6 23:34:10 CDT 2002
Peter Saint-Andre wrote:
>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
-multi-user environments like a groupchat, forums, or bulletin board system.
-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
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
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.
More information about the Members