[standards-jig] Core Tool Protocols

Adam Theo theo at theoretic.com
Tue Aug 6 21:20:09 UTC 2002

After some discussion in jdev at conference.jabber.org, I have decided to 
write up my ideas for "Core Tool Protocols" and spearhead an effort to 
begin building them in the current Jabber platform.

Core Tools Protocols are one of three layers for Jabber 2.0 (or Jabber 
NextGen as it has been called in the past). For reference, it is the 
middle layer, with the Routing layer underneath it and the Environments 
layer building on top of it. The Core Tools Protocols are a set of XML 
protocols that each do a specific task well, and rely on the others to 
enhance or extend those tasks. It attempts to bring the UNIX philosophy 
of many small, highly specialized programs that work together to produce 
some greater task, instead of a handful of monolithic programs that 
often overlap or duplicate functionality. These Core Tool Protocols 
would be used by applications and other protocols to build Environments 
such as Instant Messaging, chat rooms, digital identity, e-receipts, and 
many others.

I had planned to carefully build them as the start to Jabber 2.0, but 
after some good advice from dizzyd, I have realized that Jabber 2.0 
should not be a hard break from the current protocols. It should instead 
be a gradual, evolutionary progress that results in a whole new 
generation for the Jabber protocol. Instead of being built specifically 
for this new generation, the Core Tool Protocols should be built for the 
current one, and fixed/improved/de-bugged over time until the world is 
ready for Jabber 2.0.

With this recent talk of Disco, Packet Headers, generic 
select/navigation, and Feature Negotiation, now is the time for us to 
settle on this Core Tool model and plan around it as we finalize these 
various efforts. I will start by listing possible Core Tool Protocols, 
what other Core Tool Protocols they could rely on, and what specialized 
functionality they would provide.

* Discovery ("iq:disco") - Would query an entity about supported 
features and related entities associated with it. Could use Search to 
refine/filter results.
* Negotiation ("iq:negotiation"?) - Would choose one out of many 
presented options based on defined rules. Could use Discovery to get the 
list of options in the first place.
* Authentication ("iq:auth") - Would make sure entities are who they 
claim to be. Could be used by Permissions and Discovery to ensure security.
* Permissions ("iq:perm"?) - Would control access to certain actions and 
data of the user. Could be used by Discovery or Storage to make sure 
sensitive data is not revealed to the wrong users.
* Subscribe ("iq:pubsub") - Would allow users to subscribe to select 
content sent or updated by the publisher. Could be used by...
* Headers ("iq:headers"?) - Would be used to provide extensible 
addressing, threading, trace routes, time stamps, and other meta-data. 
Could be used by Subscribe to define topics.
* Storage ("iq:profiles"?) - Would provide a common yet powerful 
interface for management of all user data in a distributed and generic 
manner. Could be used by Subscribe to archive publishings.
* Search ("iq:select"?) - Would refine and filter results and options 
based on user-defined criteria. Could be used by Discovery to limit the 
number of results returned or return only certain types of features or 

We should start working on Core Tool Protocols by expanding and refining 
the above list. Do you think anything from above should be removed or 
altered? Can you think of any other specific functionality that should 
be added to the above list?

     /\  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"

More information about the Standards mailing list