x5334.htm

Its a xmpp protocol book

> namespaces. If clients
support this software update information request, it will be
usually in the form of a "silent" request that it sends out
at startup. The sending out of this request can be often switched
on and off in the client's configuration.</P
><P
>The conversation starts with the requester sending a special
availability packet to the information repository. Currently,
there are two such public repositories: one running at
<TT
CLASS="LITERAL"
>jabber.org</TT
> covering a wide range of Jabber
software, and the other running at <TT
CLASS="LITERAL"
>jabber.com</TT
> covering
certain clients including <I
CLASS="EMPHASIS"
>Jabber Instant Messenger</I
> (JIM).</P
><P
>This special availability packet looks like this:</P
><P
><PRE
CLASS="SCREEN"
>SEND: &#60;presence to='[e-mail]/1.6.0.3'/&#62;</PRE
></P
><P
>This is a <I
CLASS="EMPHASIS"
>directed</I
>
<TT
CLASS="LITERAL"
>&#60;presence/&#62;</TT
> packet because it has a
<TT
CLASS="LITERAL"
>to</TT
> attribute. What's even more interesting is that if we breakdown the JID, we're left with <TT
CLASS="LITERAL"
>959967024</TT
> as the
username, <TT
CLASS="LITERAL"
>update.jabber.org</TT
> as the
hostname, and <TT
CLASS="LITERAL"
>1.6.0.3</TT
> as the
resource. This doesn't mean that the availability is
destined for a user called <TT
CLASS="LITERAL"
>959967024</TT
> registered on the <TT
CLASS="LITERAL"
>update.jabber.org</TT
> Jabber server.
While most presence packets are destined for users (within
the presence subscription model), this one is destined for a service.</P
><P
>The service is running with the identification
<TT
CLASS="LITERAL"
>update.jabber.org</TT
>&mdash;a component connected to the
<B
CLASS="COMMAND"
>jabberd</B
> server backbone running at
<TT
CLASS="LITERAL"
>jabber.org</TT
>. Therefore, the <TT
CLASS="LITERAL"
>&#60;presence/&#62;</TT
>
packet will be routed to that service. Unlike the JSM, the
<TT
CLASS="LITERAL"
>update.jabber.org</TT
> service has no concept of
users or sessions. Instead, it receives the complete
<TT
CLASS="LITERAL"
>&#60;presence/&#62;</TT
> packet and disassembles
the JID in the destination address and interpret component parts as it sees
fit.</P
><P
>The service uses the <TT
CLASS="LITERAL"
>username</TT
> portion of the JID to
identify the piece of software for which new version information is
being requested. In our example, this is <TT
CLASS="LITERAL"
>959967024</TT
>. This value actually
represents
the JIM client, and is the key to the client database
kept on
<A
HREF="http://www.jabbercentral.org"
TARGET="_top"
>http://www.jabbercentral.org</A
>.
Using a unique client database key to represent the piece of software allows
the client's name to be changed without causing problems in the retrieval
of version information by the Auto-Update service.</P
><P
>The version information stored in the repository is compared to the
current version of the requesting piece of software; in this case our
JIM version 1.6.0.3. If a new version isn't available,
nothing will happen. Because the initial part of the request was a
<TT
CLASS="LITERAL"
>&#60;presence/&#62;</TT
> packet, no official response
is expected (unlike a situation where the initial part of the request
was an <TT
CLASS="LITERAL"
>&#60;iq/&#62;</TT
> <TT
CLASS="LITERAL"
>get</TT
> packet).</P
><P
>If there <I
CLASS="EMPHASIS"
>is</I
>, however, information stored in the repository
about newer versions of the software, the query is replied to using a
<TT
CLASS="LITERAL"
>&#60;message/&#62;</TT
> element, with an autoupdate
<I
CLASS="EMPHASIS"
>attachment</I
>:</P
><P
><PRE
CLASS="SCREEN"
>RECV: &#60;message to='[e-mail]/Work' from='[e-mail]'&#62;
        &#60;subject&#62;Upgrade available for Jabber Instant Messenger&#60;/subject&#62;
        &#60;body&#62;
          There is an update available for Jabber Instant Messenger.
          If your client supports the iq:autoupdate namespace then
          you should see something in the client that will list the
          available files. If not, then goto http://www.jabbercentral.com
          and grab the new version.
        &#60;/body&#62;
        &#60;x xmlns='jabber:x:autoupdate'&#62;[e-mail]&#60;/x&#62;
      &#60;/message&#62;</PRE
></P
><P
>The reply contains some text (in the <TT
CLASS="LITERAL"
>&#60;subject/&#62;</TT
>
and <TT
CLASS="LITERAL"
>&#60;body/&#62;</TT
> tags) that could be displayed to
the user.</P
><P
>Furthermore, the autoupdate <I
CLASS="EMPHASIS"
>attachment</I
>&mdash;an <TT
CLASS="LITERAL"
>&#60;x/&#62;</TT
>
subelement qualified by the <TT
CLASS="LITERAL"
>jabber:x:autoupdate</TT
> namespace&mdash;contains information on where further information can be obtained in a
programmatic way.

<A
NAME="XANDIQ"
HREF="#FTN.XANDIQ"
>[3]</A
>&#13;</P
><P
>This &ldquo;programmatic way&rdquo; sends an empty <TT
CLASS="LITERAL"
>&#60;iq/&#62;</TT
>
query, qualified by the <TT
CLASS="LITERAL"
>jabber:iq:autoupdate</TT
> namespace, to
the address given in the <TT
CLASS="LITERAL"
>jabber:x:autoupdate</TT
>
<TT
CLASS="LITERAL"
>&#60;message/&#62;</TT
> attachment:</P
><P
><PRE
CLASS="SCREEN"
>SEND: &#60;iq type="get" id="id_3" to="[e-mail]"&#62;
        &#60;query xmlns="jabber:iq:autoupdate"/&#62;
      &#60;/iq&#62;&#13;</PRE
></P
><P
>We're back on familiar ground; the Auto-Update service responds to the
request by sending version information for that piece of software:</P
><P
><PRE
CLASS="SCREEN"
>RECV: &#60;iq type='result' to='[e-mail]/Work'
                        from='[e-mail]' id='id_3'&#62;
        &#60;query xmlns='jabber:iq:autoupdate'&#62;
          &#60;release priority='optional'&#62;
            &#60;url&#62;http://www.jabber.com/download/jabbersetup.exe&#60;/url&#62;
            &#60;version&#62;1.7.0.14&#60;/version&#62;
            &#60;desc/&#62;
          &#60;/release&#62;
        &#60;/query&#62;
      &#60;/iq&#62;</PRE
></P
><P
>The response contains information about the latest software release that prompted the version request. The release is either
<I
CLASS="EMPHASIS"
>required</I
> or <I
CLASS="EMPHASIS"
>optional</I
> (as in
this example). The tags within the <TT
CLASS="LITERAL"
>jabber:iq:autoupdate</TT
>
qualified query are fairly self-explanatory; note that the version
description is empty in this example.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5A-SECT-2.5"
><TT
CLASS="LITERAL"
>jabber:iq:browse</TT
></A
></H2
><P
>The <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> namespace is relatively new and
could almost be seen as a departure from the traditional namespaces found
elsewhere in Jabber. While namespaces such as
<TT
CLASS="LITERAL"
>jabber:iq:agents</TT
> and
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> define very strict content
using specific tag names, <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> allows
a more free-form containment of information. Both forms of <I
CLASS="EMPHASIS"
>tight</I
> and
<I
CLASS="EMPHASIS"
>loose</I
> namespaces have a place in Jabber.</P
><P
>The real world contains countless types and classifications of information
far more than you could ever reasonably cover with a finite collection of
namespaces. And even if you did, that coverage would be out of date as soon
as it was completed. The Jabber concept of <I
CLASS="EMPHASIS"
>browsing</I
>, introduced in
<A
HREF="c445.htm"
>Chapter 2</A
> is an approach to being able to classify and
exchange information of all kinds without the definitions being previously
cast in stone.</P
><P
>More or less any hierarchical information can be represented in the
<TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> namespace.
It can be seen as an open-ended way of describing structures in an
almost ad-hoc way. That said, the namespace comes with some general
rules and some predefined classifications.</P
><P
>Information represented and described in a <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
>
extension is subject to classification. This classification is in two
levels: <I
CLASS="EMPHASIS"
>categories</I
> and <I
CLASS="EMPHASIS"
>subtypes</I
>.
The <I
CLASS="EMPHASIS"
>category</I
> is used to define the general area or
type of information being represented. The <I
CLASS="EMPHASIS"
>subtype</I
>
is to give a more specific definition of that category.
<A
HREF="x5334.htm#JABTDG-CH-5-TAB-5"
>Table 5a-1</A
> shows a list of initial categories.</P
><DIV
CLASS="TABLE"
><A
NAME="JABTDG-CH-5-TAB-5"
></A
><P
><B
>Table 5a-1. <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> Categories</B
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><THEAD
><TR
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Category</TH
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Description</TH
></TR
></THEAD
><TBODY
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>application</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Applications addressable via a JID can be described in this category.
Initial suggestions for such application subtypes include
<TT
CLASS="LITERAL"
>calendar</TT
> (calendar/schedule services),
<TT
CLASS="LITERAL"
>whiteboard</TT
> (collaborative whiteboard tools), and
<TT
CLASS="LITERAL"
>game</TT
> (multiplayer games).</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>conference</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Used to describe elements in the conferencing (talk between three or more entities)
world, such as private and public rooms. Subtypes of this category include
<TT
CLASS="LITERAL"
>private</TT
> (private chat rooms), <TT
CLASS="LITERAL"
>irc</TT
> (IRC
rooms), and <TT
CLASS="LITERAL"
>url</TT
> (for web-based conferences).</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>headline</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Stock-ticker-style notification systems can be described using this
category. Subtypes already defined include <TT
CLASS="LITERAL"
>rss</TT
>,
<TT
CLASS="LITERAL"
>logger</TT
>, and <TT
CLASS="LITERAL"
>notice</TT
>.</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>item</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>A category placeholder, to effect hierarchies and lists in a
<TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> structure. You can fall back to the
this category for representation of pretty much any type of information
in a navigable drill-down fashion.</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>keyword</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>IRC-style utilities that are invoked from a chat-input command line; so-called
<I
CLASS="EMPHASIS"
>keyword</I
> services such as dictionary lookups (subtype
<TT
CLASS="LITERAL"
>dictionary</TT
>), DNS resolution (subtype
<TT
CLASS="LITERAL"
>dns</TT
>), and FAQ answers (subtype
<TT
CLASS="LITERAL"
>faq</TT
>) have their category in the
<TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> world.</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>render</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Translation services such as English to French (subtype
<TT
CLASS="LITERAL"
>en2fr</TT
>), or spelling tools
(subtype <TT
CLASS="LITERAL"
>spell</TT
>) are defined in this category.</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>service</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Maps to traditional Jabber services, such as IM transports and gateways
to other systems, user directories, and so on. Typical subtypes within this
category are <TT
CLASS="LITERAL"
>irc</TT
> (IRC gateway), <TT
CLASS="LITERAL"
>aim</TT
>