Jabber Browsing

Jeremie Miller

The Jabber.org Project

414 DeLong St.
Cascade IA



The basic idea is this: the jabber world is a diverse place, with lots of services, transports, software agents, users, groupchat rooms, translators, headline tickers and just about anything that might interact on a real-time basis with conversational messages or presence. Every jid is a node that can be interacted with for messages, presence, and special purpose iq namespaces. Some jids are parents (transports), and often many jids have relationships with other jids (a user to their resources, server to it's services, etc). We need a far better way to structure and manage this culture of jid stew. The answer: BROWSING


People are comfortable identifying file types with "mime-types", in the format category/subtype. The first concept in browsing is a "jid-type", or simple similiar heirarchy for identifying the role of any Jabber ID. A jid-type, after discovered, is to be used in the same way that a mime-type would be for a file, to alter the UI representing that jid or provide alternative functionality for interacting with it (either automatically or UI-driven). The following is a first-pass at a list of the possible categories and subtypes. Additional type extensions can always be specified as category/x-subtype.

service/		To identify which "world" they map into, often another IM network or messaging gateway
service/jabber		Jabber Server
service/icq		ICQ Transport
service/aim		AIM Transport
service/msn		MSN Transport
service/yahoo		Yahoo! Transport
service/irc		IRC Gateway (user)
service/smtp		SMTP Gateway
service/pager		Pager Gateway
service/jud		Jabber User Directory
conference/		To identify the type of conference server or characteristics of a specific conference.
conference/private	Private dynamically-generated conference rooms
conference/irc		IRC Rooms
conference/topic	Topic-based conferences
conference/url		URL/Web-based conferences
conference/list		Mailing list style conference
user/			Users
user/client		Client Connection
user/forward		Forwarding alias
user/device		Portable or other device
user/inbox		Alternate inbox
user/voice		Phone or voice access
application/		Specific applications running on a user@host/resource id
application/calendar	Calendaring/Scheduling Service
application/whiteboard	Whiteboard Tool
application/editor	Collaborative Editor
application/game	Multiplayer Game
application/fileserver	Files Available
application/bot		Automated Conversations
headline/		Recognize different sources of headlines, gui hints
headline/rss		Rich Site Summary (cumulative/replaceable)
headline/stock		Stock symbol (ticker)
headline/logger		Log Messages (scrolling)
headline/notice		Alerts/Warnings (popups)
render/			Automated translation services (YTBD)
render/en2fr		English to French
render/*2*		Other standard *lang to *lang
render/jive		Jive Style
render/tts		Text To Speech
render/grammer		Grammer Checker
render/spell		Spell Tool
keyword/		Keyword Lookup Services
keyword/dictionary	Dictionary Lookups
keyword/thesaurus	Thesaurus Lookups
keyword/faq		FAQ Bot
keyword/web		Web search
keyword/software	Software search
keyword/dns		DNS resolver
keyword/whois		Whois Query

Namespace jabber:iq:browse

There is a new namespace containing the browsing data: jabber:iq:browse. The elements within this namespace are identified by the categories listed above, with a few generic attributes. For example:

<user jid="jer@jabber.org" name="jer">
  <user jid="jer@jabber.org/home" type="client" name="Home Desktop"/>
  <application jid="jer@jabber.org/chess" type="game" name="XChess"/>

The required jid attribute is the full Jabber ID of the entity described. Type is the subtype for the category as defined above, and is required. Name is a friendly name that may be used in a GUI, and is optional. (uri="" for web links?) Any element may contain any other element as a child, describing the relationship between the two. This relationship my be represented as a "link" in a wizard or page-based GUI, or as a branch in a tree as it's expanded. When a jid is browsed to, the result may contain children or be empty. An empty result means there is no further relationships or links for that jid, a dead-end, which may be represented as a page that contains a list of functions available for it (vcard, message, register, etc). When the result contains children, they may also be empty (as in the example above). An empty child does not mean anything, and to determine if there are more children of it it must be browsed to directly.

When requesting this namespace with iq *get*, the jid attribute in the iq result must match the jid in the root node of the browsing namespace (if any).


Ontop of the browsing framework, a simple form of "feature advertisement" can be built. This allows any entity to advertise which features they support, based on namespaces. An additional allowed element within a browse result is <ns/>. This element contains a single namespace that the entity supports, and multiple ns elements can be included in any result. For a connected client this might be <ns>jabber:iq:oob</ns>, or for a service <ns>jabber:iq:search</ns>. This list of namespaces should be used to present available options for a user, or for an application to automatically locate functionality.

The children of a browse result may pro-actively contain a few ns elements (such as the result of the service request to the home server), which advertises the features that particular service supports. This list may not be complete, and the jid should be browsed to for a complete list, it is only for first-pass filtering by simpler clients.

Clients should answer incoming browsing requests to advertise which namespaces they support, such as file transfers (jabber:iq:oob), crypto/signatures, xhtml, etc.

Supplanting jabber:iq:agents

The first important use of jabber:iq:browse is to replace the iq:agents namespace. When a client connects, it may optionally browse to the server it connected to to retrieve a list of available services. The resulting iq might look like:

<service type="jabber" jid="jabber.org" name="Jabber.org Public Development Server">
  <service type="icq" jid="icq.jabber.org" name="ICQ Transport">
  <conference type="private" jid="conference.jabber.org" name="Private Chatrooms"/>
  <application type="bot" jid="jabber.org/help" name="Assistance Agent"/>

To determine any further details from this list, each individual child would have to be browsed to. The elements within the icq service are only hints for a client when building GUI menu items or in wizzards, icq.jabber.org would still need to be browsed to to determine any relationships or additional namespaces. This top-level list is the master "services" list available from the server, and should be used for any default functionality when available. This list may also serve as the "home page" for a page-based browsing GUI.


It is also useful to arrange entities hierarchially, which implies nodes or parents that don't really exist except to be browsed to and contain a list of children or relationships. These generic nodes are simply items, and represented by a <item jid="server/abc/def" name="DEF Zone"/>. It has no sub-type, and is a special purpose entity that is only for arranging browsing in a heirarchy. They can be used whenever the type of jid isn't pre-set (and needs to be browsed to directly), or serve as a placeholder for a node in a heirarchy of other jids. This is most useful for representing unknown jids, arranging a company directory, list of chat rooms, or browsing any heirarchially-arranged jabber entities.

Live Browsing

This is Jabber, it's a real-time platform, and browsing is a relatively static activity. So to take full advantage of browsing within Jabber, browse data can be live and pushed similiar to presence. This is useful for any browseable data that might change regularly (participants in a conference, bluetooth devices, or custom application uses) which can be tracked in real time and have updates pushed out to all those interested in receiving them.

Live Browsing right now is used for specific purposes or services, and not a generalized framework. The client side implementation is dependent upon the specific purpose (such as conferencing), and typically requires a context-specific GUI (list of participants) or an outside event (joining a room) to be enabled. Once in operation, it works very similiarly to roster pushes, the remote side will send iq set requests containing updated browse information. These subsequent sets must arrive from the original jid and will contain additional children or updates to existing children (type="remove" removes a child like in editing below). The root node of the iq:browse namespace in the iq set will contain the jid of the updated item. This is an important and non-obvious note, that the push requests may only contain the updated "children", but arrive from the authorative "parent", and that if the root node does not contain a jid attribute (defaulting to the from jid in the iq as with an iq get) or contains the sending jid, it replaces all browse data for that jid.

<iq type='set' from='room@conferencing'>
  <user xmlns='jabber:iq:browse' jid="room@conferencing/a08e..." name="randy"/>


Any jid may be stored in the roster. The roster's role for storing jid's a user is interested in, can expand into a bookmark role not only storing them for presence information but also for browsing. This would expand the namespace of the roster to include the standard jid-types. Additionally to an "item" element, any of the above categories could be stored as an element in the roster with an optional type attribute. The name and all other roster/presence related attributes apply equally as if it were an item, but intelligent clients can use the jid-type to make additional user-stored bookmarks available. The client could store favorite chat rooms, always-enabled renders, headlines, or special remote transports that you want made available in addition to the default server ones. In a GUI, clients could optionally merge this list from the roster with the list from the server, or make it available as part of the roster directly.


When an iq set is used, and when there are sufficient priveleges (such as a user to thier jid), the included browse namespace data should be stored. When setting, the root browse element will not replace the entire contents of the parent it was sent to, but simply be inserted. To remove any child, use type="remove".

<iq type='set' to='jer@jabber.org'>
  <user type='device' xmlns='jabber:iq:browse' jid="jer@jabber.org/palm" name="Palm Pilot"/>

Implementation Notes (rough)

A client shouldn't just blindly follow browse-to-jids and keep requesting, but instead it should maintain an internal list of all the returned browse results for a jid for efficiency. Any display or use of the browse data should then be returned from the internal list. This is a similiar model to presence. All jids should always have the following options: message/chat, browse Hostname jids should also always have the options: time, vcard, last, version Users should also have: vcard, last User resources should have: time, version, oob