[Foundation] Council Answers - Julian Missig

[Julian Missig]

Peter Saint-Andre wrote:
> 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 seems to be working as far as documentation goes. The 
protocol extensions now at least have some form of documentation. I 
couldn't say that before JEPs. The major problems with the JEP process 
seem to be in the communication and decision-making areas. The Council 
members really need to voice their opinions on JEPs earlier. 0 and +1 
need to be different -- the fact that everyone is at least apathetic 
toward a JEP is no reason to accept it.


> 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

The major advantage of Jabber is that it is actually simple. You take a 
TCP socket and you feed some XML over it. SIP was not designed for 
transportation. Transporting messages over it therefore does not make 
much sense to me. I don't think the argument that one should accept 
SIMPLE just because one is accepting SIP holds. "Jabber is more than 
just IM" we say -- well, it is. Jabber is a transportation medium for 
XML. SIP isn't.

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

One-to-many messaging is probably going to be one of the more common 
uses of pub/sub. It would be pretty simple to set up a "mailing list" in 
Jabber with pub/sub. I could imagine extending that, though. Imagine a 
"mailing list" over Jabber for Gabber (just to pick one of the clients 
at random ;) ). The users who are interested in Gabber could join the 
group, and when there are updates I can send them messages. Combine that 
with x:data, however, and I can quickly have users take a poll or fill 
out a survey -- using the actual GUI widgets like drop-down boxes and 
radio buttons for the responses, then have my software collect all the 
answers and analyze them. The pub/sub specification we accept should 
definitely support messages and iqs -- both with optional 
store-forwarding based on x:delay.

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

It would be nice if the foundation at least had the option to decide who 
can and cannot use the trademark based on compliance issues and the like 
-- but then, we still haven't fleshed out "JabberPowered".

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

I would really like to experiment with trust metrics (advogato-ish or 
google pagerank-ish) at some point. Even if not for all-out server 
trust, it could be really useful for spam prevention.

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

Yes, it would definitely be nice to be able to transport non-XML 
payloads in band if the server allows it. I still see out-of-bound 
transport as different from SIP because application calls (XML-RPC, 
SOAP) and extended data can still be sent over the transport, while SIP 
is not a transport at all.

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

We need to continue to focus on keeping the client simple. Clients 
should be able to communicate on the Jabber network without a lot of 
work. Yet, if a client wants to be more intelligent, it should be 
allowed to be so.

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

The same way that Jabber developers learned to work within the rules of 
the Jabber Software Foundation -- participate directly.

Julian
-- 
email: julian at jabber.org
jabber:julian at jabber.org