[Foundation] Council Questions

[Adam Theo]

First I'd like to say I much prefer this way of doing debates through 
the members list instead of a live chat. It really allows for more 
well-composed responses.

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

One idea that has occurred to me while reading so many JEPs in the past 
few weeks is that the format should be better standardized. What I mean 
is that there is an amazing difference in the styles in how examples are 
done (some JEPs use SEND & RCVD to designate what entity is speaking the 
example, others use S & C, some don't even use anything), if the 
document is structured along use-cases or features, some read like RFC's 
while others use stream-of-consciousness.

While it may be argued that JEPs are all written by different people 
(which is a good thing!), I believe that there should be standards or at 
least guidelines on the "style" of JEPs, covering such above issues.

I would also like to see a seperate process for deciding Foundation 
process and management changes, like the JEP process, but non-protocol.

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

As others have pointed out, SIP (and therefore SIMPLE) are 
plaintext-based. However, I would like to point out this makes them much 
less manipulatable than Jabber. One of the strengths of XML is that it 
can be easily converted and altered into other text-based formats, as we 
easily see with Jabber's Transports to other IM systems. Even 
transporting XML via SIP is not as good a solution because you would not 
have important meta-data as XML to be easily converted into those 
foreign formats.

> 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 powerful, flexible pub/sub mechanism is necessary to Jabber's growth. 
I'm not talking about something that acts merely as a newsfeed solution, 
but something that can potentially replace groupchat, presence, mailing 
lists, and newsletter subscriptions. With that, Jabber can be applied in 
a wide variety of corporate and industrial environments in creative and 
unique ways. Executives and IT departments would thank us.

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

It should eventually be purchased from Jabber, Inc at a fair price by 
the JSF when the JSF deems itself to be able to protect and promote the 
trademark.

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

I think this is a sticky issue. I have heard PKI, I've also heard Web of 
Trust, I've also read Mike Lin's good suggestion about PKI with Web of 
Trust, but I think ultimatly it will need to be something which does not 
enforce a client/server model, allowing the Jabber protocol at least to 
remain open to the possability of a p2p architecture in the future. PKI 
may be good as long as it not forced to come from the server in the 
user's JID or mandated to come from the JSF or "JANA".

> 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! Jabber should be built with low-level functionality in mind, able 
to potentially do everything without relying on outside transport 
protocols. It should of course remain very modular, allowing people to 
use and support only what they want to.

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

I think the best way is to find the bare-bones lowest common denominator 
as Mike Lin said. But that is only half the solution. <plug 
topic="Jabber Environments" xmlns="http://theoretic.com/?Jabber_2.0">We 
also need a way to organize and categorize the higher-level 
functionality that will exist. This should be done with Jabber 
Environments, which are neat, labeled packages of features, 
requirements, and protocols that run on top of the bare-bones Jabber 
platform. Also, a reasonable set of open protocols should be designed to 
provide low-level functionality such as authorization, pubsub, feature 
discovery, and others that is often duplicated in many other protocols. 
You can learn more about this at http://www.theoretic.com/?Jabber_2.0 
</plug>

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

I at first opposed the IETF effort because I see the IETF "community" as 
fairly incompetant when it comes to designing protocols. Many of their 
products have a very "designed by committee" design, and have more or 
less failed because of it (BEEP, SIP, APEX, and many others that 
promised much, but no-one bothers to impliment).

I have realized that my past bad experiences are likely just my own, and 
others are very eager and happy for the IETF to take change control over 
the core of the Jabber protocol. And while I do feel there is an 
established developer base and bias at the IETF that may not be good for 
Jabber, I feel confident now that with so many Jabber developers 
interested and hopefully active in the process, the protocol will not be 
taken in a destructive or suicidal direction.

I do feel, however, that the IETF should not be high on our priority 
list. There are so many other more important issues we need to resolve 
first before spending energy with the IETF. Documentation needs serious 
work, client and server code bases need to be matured, and more sponsors 
need to be found for the JSF.

I don't believe that the IETF would do Jabber much good, either. Jabber 
already has more than the IETF could ever provide: a strong developer 
community with an amazing range of implimentations under a wide variety 
of licensing terms, programming languages, and computing platforms. This 
is something that many IETF-created protocols never have ever come close 
to managing, notably BEEP, SIP, SIMPLE, and APEX, among many, many 
others you can find by just browsing the list of IETF WG's. We also have 
a kick-ass protocol that has been built through trial and error, tested 
in the real world.

Companies are already accepting Jabber, and all it takes for bigger and 
badder companies to jump aboard is a powerful advocacy effort that 
wouldn't even take any $$ to finance. That is why I'm running for the 
Board as well, BTW, to build this strong advocacy effort on our own.

Now, as Mike Lin has also pointed out, this doesn't mean the IETF effort 
should not be done. I realize that now. It just means it should not be 
high on our list while so many other issues of much greater importance 
need work.

/me steps off the soapbox.

-- 
     /\  Adam Theo, Age 23, Tallahassee FL USA
    //\\   Email & Jabber: theo at theoretic.com
   //  \\  Pager: (850) 709 7738
=//====\\=
//  ||  \\  Theoretic Solutions: http://www.theoretic.com
     ||         "Building Ideas by Bringing them Together"
     ||      Jabber Protocol: http://www.jabber.org
     ||         "The Next Generation Communications Protocol"
     ||  "A Free-Market Socialist Patriotic American Buddhist"