Earlier in this chapter we saw how a basic message was embellished with a structured and parseable 'attachment' in the form of a jabber:x:oob qualified <x/> tag, and its child tags:
<x xmlns='jabber:x:oob'> <url>http://www.megacorp.co.uk/earnings3q.html</url> <desc>Third Quarter Earnings for Megacorp</desc> </x>
How does this actually work in practice? Well, partly by requirement, partly by convention.
All three of the elements <message/>, <iq/> and <presence/> can carry these attachments.
These attachments usually server one of two purposes
to bring primary (or secondary) meaning to the element that contains it
to act as the driving force behind the element, such as that the element really only exists to carry the attachment
This distinction is rather subtle, so let's look at a couple of examples.
Example 2-2. A jabber:x:delay extension adds meaning to a <presence/> element
<presence from='jim@company-a.com/home' to='john@company-b.com'>
<show>chat</show>
<status>having a break from work</status>
<priority>1</priority>
<x xmlns='jabber:x:delay' from='jim@company-a.com/home'
stamp='20010611T13:13:04'/>
</presence>Example 2-2 shows an attachment in the jabber:x:delay namespace. This works like a timestamp, and in this context indicates when that presence element appeared, in other words, from what time Jim started on his break.
Example 2-3. A jabber:x:oob extension is the heart of a <message/> element
<message type='headline' from='jabbercentral@news.company-b.com'
to='john@company-b.com'>
<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>Example 2-3 shows us a message element containing a URL attachment. In this case the element serves to carry the URL attachment; there is not really any other purpose to it. Delivering the <message type='headline'/> carrier without the payload wouldn't make much sense.
The outermost tag of each attachment, by convention, is either <x/> or <query/> although they can be any valid XML tag name. The Jabber namespaces that are used to qualify these <x/> and <query/> attachments follow a convention, beginning
jabber:x:
for those qualifying the <x/> attachments, and
jabber:iq:
for those qualifying the <query/> attachments.
<x/> is used as a generic extension mechanism to add information to any of the Jabber elements, and <query/> is used to extend the <iq/> element.
Chapter 5 lists the standard namespaces used in Jabber to qualify the <x/> and <query/> attachments. But we're not restricted to just those namespaces - we're free to build our own attachments qualified by our own namespaces, if we think that what we want to achieve isn't covered by anything 'out of the box'. In this situation, there are two things to note:
the namespaces cannot begin 'jabber:'
the receiving recipient of the extended element must be able to appropriately interpret the attachments (!)