The Jabber Project: Info/Query Proposal

The Jabber Project:
Info/Query Proposal
by Jeremie <jeremie@jabber.org>

Introduction

As it exists currently, Jabber lacks any convienent or standard way of accessing or setting user meta-information such as name, email address, location, etc. This proposal provides an easy and clean way add that functionality while also providing a new means of solving other needs within Jabber and providing a new class of features.

The <info> packet

To add this functionality I'm proposing that a new packet is needed within the protocol. This packet would be the container for any info/query functions and can be ignored by clients or transports that do not support any info/query functionality.

A sample packet might look like:
    <info>
	<to>jeremie</to>
	<target>user</target>
	<id>public</id>
	<query><name/><address/><email/></query>
    </info>
And a response from the server to this query might be:
    <info>
	<target>client</target>
	<type>public</type>
	<result>
	    <name>Jeremie Miller</name>
	    <address>Some Street, City, State, 55555</address>
	    <email>jeremie@jabber.org</email>
	</result>
    </info>

Definitions

<target>***</target>
The target contains characters identifying what "area" this info is related to. Possible values are:

user User specific information, addresses, preferences, etc. Handled by the server modules.
client Delivered directly to the client socket, for special feature negotiation and queries.
server Server specific information, version, administrator, URL, help, etc.
search Searching for a user or other types of searches

<type>***</type>
This is the specific item that the query/result is directed at. You can think of it as a "namespace" but not in the official XML sense, it's just a way of separating different common terms that are queried. Possibile values:

public Publically accessible information
admin Administrative or protected information
feature Feature Negotiation
private Priavte only data

<query>***</query>
Contains empty XML tags expressing the queried items.

<result>***</result>
Contains the queried empty XML tags filled in with the correct data, (which might itself be XML).

This takes care of a simple data query/result situation, let's add in the ability to change data also.
    <info>
	<target>user</target>
	<type>public</type>
	<set><email>jer@jeremie.com</email></set>
    </info>
By simply changing the <query> to a <set>, the data can be updated/stored. (This would of course only be allowed by an authenticated session from the correct user account)

Discovery

When an empty query is sent, a reply of all of the possible fields would be returned:
    <info>
	<to>jer</to>
	<target>user</target>
	<type>public</type>
	<query/>
    </info>
Would be the "discovering" query, with a possible reply of:
<info>
	<to>jer</to>
	<target>client</target>
	<type>public</type>
	<result><name/><email/><zip/></result>
</info>

Discussion

There are lots of ways this functionality could be used for various purposes besides just handling user information:

Servers and transports should be required to provide a standard set of public queryable variables such as help, register, admin, about, url, which return user-readable information about the variable.
A standard set of public user-level queryable terms such as name, email, zip, etc, should be agreed upon.
Servers can offer administrative variables that can be updated on the fly via set queries by administrators.
Servers should support a client-specific set/query (type='ClientName') so that client software can store it's own variables on the server.
Feature Negotiation between clients (via type='feature')

This document isn't attempting to force or even propose any standard queries or uses for the info packet, simple propose it's existence. Hopefully there is enough functionality expressed in this proposal to handle many of the needs of the Jabber project. Essentially, a database model is expressed in any query: target represents the database name, type represents the table, and the XML tags within the query/set represent the column names.

Plan: Assuming there are no major flaws or issues with this approach, it will start being implemented and tested in the 0.7 codebase. As it is developing, discussions should be started on standard queries for servers and clients and documenation updated to reflect this new packet and standard queries that are agreed upon.

Any specific questions about this document or Jabber can be directed to the Jabber Development Team at <team@jabber.org>.