414 DeLong St.
Cascade IA
52033
US
jeremie@jabber.org
01/25/2001
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
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"/> </user>
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.
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">
<ns>jabber:iq:register</ns>
<ns>jabber:iq:search</ns>
<ns>jabber:iq:gateway</ns>
</service>
<conference type="private" jid="conference.jabber.org" name="Private Chatrooms"/>
<application type="bot" jid="jabber.org/help" name="Assistance Agent"/>
</service>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.
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"/> </iq>
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"/> </iq>
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