While the IQ namespaces are used in exchanging structured information in semi-formalized conversations, the X namespaces are more ad-hoc extensions that add value, context, and information to any type of packet.
The jabber:x:autoupdate namespace is used to carry information on where new version information can be found. Details and an example of this namespace's usage can be found in the description for the IQ version; jabber:iq:autoupdate in the section called jabber:iq:autoupdate.
Just as jabber:x:autoupdate is related to its big brother jabber:iq:autoupdate, so too is the jabber:x:conference namespace related to jabber:iq:conference. The <x/> version of the IQ conference namespace is used to convey information about a conferencing room, usually attached to a message:
SEND: <message id='2113' to='robert@company-a.com'>
<subject>Design Meeting</subject>
<body>Robert - you're supposed to be at the meeting now!</body>
<x xmlns='jabber:x:conference' jid='meeting1@meetings.company-a.com'/>
</message>
If supported by the receiving client, this will be interpreted as an invitation to the room and the procedure for joining the room (in this case identified with the JID meeting1@conf.company-a.com) can be automatically initiated:
SEND: <iq type='get' id='c4' to='meeting1@meetings.company-a.com'>
<query xmlns='jabber:iq:conference'/>
</iq>Packets—those conveying messages and presence—are sometimes sent to entities that aren't available at that particular moment. If they are stored offline, they are timestamped, in the jabber:x:delay namespace, so that when they are finally received, the recipient can use this information to determine when the packets were originally sent.
RECV: <message to='sabine@yak/Work' from='yak'>
<subject>Weekend at last!</subject>
<body>Don't forget Father's Day on Sunday!</body>
<x xmlns='jabber:x:delay' from='yak/announce/motd'
stamp='20010615T09:00:01'>Announced</x>
</message>In this Message Of The Day (MOTD) announcement, we see that as well as the stamp attribute showing that the announcement was sent out on the Friday morning before Father's Day, a short text description Announced is included.
The namespace is also used by the xdb component to timestamp various fragments of data. Here, we see that Sabine updated her user registration (using a jabber:iq:register query during her session) at the beginning of March.
<query xmlns='jabber:iq:register' xdbns='jabber:iq:register'> <name>S. Reitz-Adams</name> <email>sabine@reitz-adams.org</email> <x xmlns='jabber:x:delay' stamp='20010302T12:15:42'>updated</x> </query>
The relatively new jabber:x:encrypted namespace can be used to implement message-level security. It allows for the attachment of encrypted data Public Key Infrastructure (PKI) techniques, meaning that the data is encrypted using the message sender's private key, and decrypted by the recipient using the sender's public key.
SEND: <message to='john@company-a.com' id='m221'>
<subject>Top Secret!</subject>
<x xmlns='jabber:x:encrypted'>
hQEOA7ucqu53AhlPEAP/ZbU6oPnRAbIcUxMK1XRVnkgZ/Agtq1tcTQuEZxbpZLl4
lkKJlkjkJjghyri(*8ygHbkjaja09Ja09sajkls8aj1h0J/a=ajhsa9A1ska191l
</x>
</message>The Jabber server itself does not currently provide any mechanisms for key management or exchange; the namespace is for the time being purely a marked container to hold encrypted data.
There are no components in the Jabber server that can encrypt or decrypt using PKI tools (such as PGP or GPG); this namespace can be seen as enabling pure P2P-encrypted communication in an Out Of Band (OOB) style, in the same way that the jabber:iq:oob namespace enables P2P file exchange.
The jabber:x:envelope namespace is used to describe more complex message addressing details than the simple from and to attributes in the <message/> packets.
The first area where this namespace is used is in server-side filtering, a service provided by the JSM's mod_filter module. For example, when a user sets a filter rule to forward all messages to someone else while he's not around: [1]
<rule name="absent"> <show>xa</show> <forward>john@company-b.com</forward> </rule>
a message such as this:
<message id='284' to='janet@company-b.com'> <body>Can you give me the sales figures for last quarter?</body> </message>
will be passed on to john@company-b.com in this form:
<message id='284' to='janet@company-b.com'>
<body>Can you give me the sales figures for last quarter?</body>
<x xmlns='jabber:x:envelope'>
<forwardedby jid='janet@company-b.com'>
<from jid='mark@company-b.com'>
<cc jid='john@company-b.com'>
</x>
</message>to add context information on where the message has come from.
Message events allow clients and servers alike to add information about the receipt and handling of messages at various stages of delivery. There are currently four types of events supported in this namespace:
The composing event, represented by the <composing/> tag within the <x/> extension qualified by the jabber:x:event namespace, can be set by clients and signifies that the user is composing a reply to the message just sent.
When a message is received by a client, it can set the <delivered/> flag to signify that the message has been received.
The displayed event is used to indicate that the message sent has been displayed to the user. This event is set, using the <displayed/> tag, by clients.
When a message recipient is not connected, the JSM module mod_offline will store the message and send it to the recipient when he is next available. This offline storage event can be set by the server, using the <offline/> tag, to notify the sender that the message has been stored offline.
The <composing/>, <delivered/> and <displayed/> events are client events and are only appropriate to be set by the client. The <composing/> event is a server event and only appropriate to be set by the server. In all cases, the events are only set if the message originator requests that they are. Adding a jabber:x:event extension to a message like this:
SEND: <message to='sabine@yak' id='M31'>
<subject>Where are you?</subject>
<body>Let me know when you get back</body>
<x xmlns='jabber:x:event'>
<displayed/>
<offline/>
</x>
</message>is the way to request that we get notified:
If and when the message is stored offline by the server in the eventuality that sabine is not connected.
When the message is eventually displayed to Sabine.
The former event will be set by the server, the latter by Sabine's client.
Setting an event is similar to requesting one, and uses the jabber:x:event namespace. Here is what we would receive if the server did store our message to Sabine offline:
RECV: <message to='dj@yak/Work' id='M31' from='sabine@yak'>
<x xmlns='jabber:x:event'>
<offline/>
<id>M31</id>
</x>
</message>That is, the <offline/> tag is sent back to the originator, along with an <id/> tag which contains the id of the message that was stored offline.
Example 5a-5 shows the receipt of a chat message and the <composing/> event being raised as Sabine starts to type her reply.
Example 5a-5. Raising and cancelling the <composing/> evevent
DJ sends a quick chat message to Sabine, and requests that his client be notified when she starts typing her response.
RECV: <message to='sabine@yak/Work' from='dj@yak/home' id='122' type='chat'>
<body>hey, want a coffee?</body>
<thread>ABAF6FC6521546A2B65B19EA391CB72A</thread>
<x xmlns='jabber:x:event'>
<composing/>
</x>
</message>Sabine starts to type, which fires the <composing/> event:
SEND: <message from='sabine@yak/Work' to='dj@yak/home'>
<x xmlns='jabber:x:event'>
<composing/>
<id>122</id>
</x>
</message>Sabine is distracted, and her client decides she's abandoned the reply, and sends a cancellation of the <composing/> event, containing only the message id included when the event was originally raised.
SEND: <message from='sabine@yak/Work' to='dj@yak/home'>
<x xmlns='jabber:x:event'>
<id>122</id>
</x>
</message>The jabber:x:expire is a simple namespace to add an 'use by' or 'read by' stamp to a message. If you wish to send a message impose a finite lifetime upon it, attach an expiry extension thus:
SEND: <message to='piers@pipetree.com' id='M24'>
<subject>Eccles cakes!</subject>
<body>
I've got some fresh Eccles cakes here, pop
round for one before they all disappear!
</body>
<x xmlns='jabber:x:expire' seconds='1800'/>
</message>If John was not connected when the message was sent, the mod_offline module would hold the message ready for when he reconnects. But before storing it, an extra attribute (stored) is added with the current time. Example 5a-6 shows what the relevant section of John's spool file would look like.
Example 5a-6. Storage of an offline message with the jabber:x:expire extension
<foo xmlns='jabber:x:offline' xdbns='jabber:x:offline'>
<message to='piers@pipetree.com' id='M24' from='dj@pipetree.com/kitchen'>
<subject>Eccles cakes!</subject>
<body>
I've got some fresh Eccles cakes here, pop
round for one before they all disappear!
</body>
<x xmlns='jabber:x:expire' seconds='600' stored='993038415'/>
<x xmlns='jabber:x:delay' from='dj@pipetree.com' stamp='20010620T12:00:15'>
Offline Storage
</x>
</message>
</foo>When John reconnects, mod_offline retrieves the message and compares the current time with the value in the stored attribute. If the difference exceeds the desired lifetime of the message, as specified in the seconds attribute, the message is discarded. Otherwise, the seconds attribute value is reduced to reflect the amount of time the message sat in storage, the stored attribute is removed, and the message is sent to John.
Furthermore, if John's client supports it, a further check of the message's lifetime can be made before display, in case the message was stored in an inbox-style mechanism. (With John's luck, he probably missed out on the Eccles cake.)
We've already seen the jabber:x:oob in action earlier in the book. It is used in a similar way to its big brother the jabber:iq:oob namespace. Attaching URLs to messages, typically done by mechanisms that delivery news and alert style headines, is done like this:
SEND: <message type='headline' to='qmacro@jabber.org/laptop' id='h12'>
<subject>Jabber Foundation Public Conference</subject>
<x xmlns='jabber:x:oob'>
<url>
http://www.jabbercentral.com/news/view.php?news_id=989358658
</url>
<desc>
Tomorrow, May 9th, a meeting regarding the Jabber
Foundation will be held.
</desc>
</x>
</message>Multiple attachments can be made to a message.
The RSS Punter, described in the section called RSS punter in Chapter 8 and the Headline Viewer, described in the section called Headline viewer in Chapter 8 both use the jabber:x:oob namespace.
The jabber:x:roster namespace is related to its big brother jabber:iq:roster; it is used to carry roster information as message attachments. This makes it straightforward for users to exchange contact information between themselves:
SEND: <message id='M91' to='shiels@jabber.org'>
<body>Hi Robert - this is that fool I was telling you about...</body>
<x xmlns='jabber:x:roster'>
<item jid='qmacro@jabber.org' name='DJ Adams'>
<group>Fools</group>
</item>
</x>
</message>Note that it is inappropriate to send the subscription related attributes (subscription and ask, described in the section called jabber:iq:roster). Instead, it is up to the recipient to negotiate their own presence subscription arrangements with the contact, or contacts (more than one item can be sent in such an attachment) listed.
The jabber:x:signed namespace is related to the jabber:x:encrypted namespace and is used to stamp <presence/> and <message/> packets with a PKI-based signature, thus providing reliable identification of the packet originator.
In generating the signature block, some relevant data must be used to pass into the signing algorithm so that an electronic signature is produced. [2] In the case of <presence/> packets, the contents of the <status/> tag are used, and in the case of <message/> packets, the contents of the <body/> tag are used.
The presence of a jabber:x:signed signature in a <presence/> packet is intended to signify that the client sending the packet supports such PKI infrastucture and, for example, is able to decrypt messages encrypted in the jabber:x:encrypted namespace.
Here's a <presence/> packet containing a signature; the data All present and correct is what is fed into the algorithm.
SEND: <presence from='piers@jabber.org' to='qmacro@pipetree.com'>
<status>All present and correct</status>
<x xmlns='jabber:x:signed'>
aslkjlksjdf jsfkjk23jskdfskjdfksjdf
</x>
</presence>| [1] | The filter service is described in the section called Filter Service in Chapter 4. |
| [2] | Typically, when signing an email message electronically, the body of the email is passed into the signing algorithm to generate the signature. |