We're building "transports" to other IM systems to bridge communication, what next?  FINDING users to communicate with!  We like things XML and simple, so let's discuss doing for "directories" what we've done for IM, using the same technologies.

To an individual, what you need to know to find another individual or entity in the real world is well defined: Name (first/last) and Location (address, state, country).  From those two facts an individual most commonly seeks out a form of communication to the other individual or entity, which are also well defined: Internet (URL/Email/IM) and Real World (phone, full address).  Let's use the most common peices and build a common comprehensive system of querying the various available directories.

First, let me mention a few open directories that can be bridged to:

JUD - Jabber User Directory (for Jabber users who have listed themselves)
Internet Email - Yahoo/Bigfoot/etc (LDAP)
Corporate - Internal Company Directories (only available on an internal server of course, LDAP)
ICQ - Reverse Engineered searching ability
Phone Book - Yahoo/Switchboard/etc (LDAP)
Web Based - HTML Forms for searching for users on community sites

Each of these directories has a plethora of other features and characteristics associated with each entry, but overall they all share most of the common traits above.

Now, let's get into the details...

Building on the jabber:iq:agents functionality available, each agent can include a <search/> flag, indicating to the client that this agent is capable of being searched.  The searching process is similiar to the jabber:iq:register registration process, a client sends a jabber:iq:search get IQ to the agent, which responds with a list of fields that are searchable:

<iq type="get"><query xmlns="jabber:iq:search">
<instructions>Search for Users</instructions>

The client then displays a search form with those fields for text entry, and submits an IQ set to the agent with the entered text in those fields.  The timeout field tells the client to timeout waiting for the search after that many seconds.

The search items are returned in the result to the set:

<iq type="result"><query xmlns="jabber:iq:search">
<item jid="jabber:ike@agent.host"><first>Ike</first><last>Toe</last><email>ike@toe.net</email></item>
<item jid="jabber:danbar@agent.host"><first>Ike</first><last>Bar</last><email>dan@bar.org</email></item>

With this scheme, any agent is able to present a consistent searchable directory to the rest of the Jabber architecture, allowing clients to build a common user searching interface alongside of the existing common messaging interface.  Any transport can express it's searching feature to clients and respond at it's control to the queries.

After we have the basics working with the most common individual information, we can easily extend this to the next step, searching for things other than users, and searching based on categories, keywords, or descriptions.