[JDEV] A query regarding <iq/> element

[Ritu Khetan]

Hello all, 

I am studying the Programming Jabber book wherein I was
studying about the \"to\" attribute in the <iq/> element.
I found  some explanation there which I do not
understand, I am thoroughly confused...

Here is what it says.. [Page 163, CHapter 5 - Jabber
Building Blocks]

to attribute - Optional

Synopsis
<iq to=\'jdev at conference.jabber.org\'/>

This attribute is used to specify the intended recipient
of the info/query action or response.
If no to attribute is specified, the delivery of the
packet is set to the sender, as is the case for
<message/> packets. However, unlike the case for
<message/> packets, <iq/> packets are usually dealt with
enroute and handled by the JSM.

What does that mean? Packets sent from a client travel
over a jabber:client XML stream and reach the Jabber
server, where they\'re routed to the JSM. [7]

A large part of the JSM consists of a series of packet
handlers whose job it is to review packets as they pass
through and act upon them as appropriate; some of these
actions may cause the packet to be deemed to have been
?delivered? to its intended destination (thus causing
the packet routing to end for that packet) before it
gets there.

So in the case of <iq/> packets without a to attribute,
the default destination is the sender\'s JID, as we\'ve
already seen with the <message/> element. But because
JSM handlers that receive the packet may perform some
action to handle it and cause that packet\'s delivery to
be terminated (marked complete) prematurely, the effect
is that something sensible will happen to the <iq/>
packet that doesn\'t have a to attribute and it won\'t
appear to act like a boomerang.

Here\'s an example:

The namespace jabber:iq:browse represents a powerful
browsing mechanism that pervades much of the Jabber
server\'s services and components. Sending a simple
browse request without specifying a destination (no to
attribute):

SEND: <iq type=\'get\'>
<query xmlns=\'jabber:iq:browse\'/>
</iq>

will technically be determined to have a destination of
the sender\'s JID. However, a JSM handler called
mod_browse which performs browsing services gets a
look-in at the packet before it reaches the sender and
handles the packet to the extent that the query is
deemed to have been answered and so the delivery
completed. The packet stops travelling in the sender\'s
direction, having been responded to by mod_browse:

RECV: <iq type=\'result\' to=\'dj at yak/sjabber\' from=\'dj at yak\'>
<user name=\'DJ Adams\' xmlns=\'jabber:iq:browse\'
jid=\'dj at yak\'/>
</iq>

And while we\'re digressing, here\'s a meta-digression: We
see from this example that a browse to a particular JID
is handled at the server. The client doesn\'t even get a
chance to respond. So, as one of browsing\'s remits is to
facilitate resource discovery (the idea is that you can
query someone\'s client to find out what that client
supports?whiteboarding or XHTML text display, for
example), how is this going to work if the client
doesn\'t see the request and can\'t respond? [8]

The answer lies in the distinction of specifying the
recipient JID with or without resource. As a resource is
per-client connection and often represents that client,
it makes sense to send a browse request to a JID
including a specific resource:

SEND: <iq type=\'get\' to=\'qmacro at jabber.org/sjabber\'>
<query xmlns=\'jabber:iq:browse\'/>
</iq>

This time the destination JID is resource-specific and
the packet passes by the mod_browse handler to reach the
client (sjabber), where a response can be returned: [9]

RECV: <iq type=\'result\' to=\'piers at jabber.org/WinJab
                      from=\'qmacro at jabber.org/sjabber\'>
<user type=\'client\' xmlns=\'jabber:iq:browse\'
                         jid=\'qmacro at jabber.org/sjabber\'>
<whiteboard/>
<videochat/>
<PGP/>
</user>
</iq>


Can someone explain why does the iq result come in the
form of <user name...DJ Adams ...jid=\'dj at yak\'/>

Further, what is this funda about the client nothing
getting a chance to respond..I do not understand this...

Thanks in advance.

Regards,
Ritu