These are my (Zarf's) notes to myself about the Jabber protocol. Feel free to improve.
Jabber is a simple client-server communication protocol based on XML. It doesn't quite transmit complete XML documents back and forth; there is an XML-style header, followed by an indefinite number of XML stanzas.
The Zen of Jabber, as I understand it, is to be very restrictive about syntax, but to also provide "sandboxes" -- well-specified areas of the syntax -- which have complete flexibility.
For example, the top-level XML stream allows just three kinds of stanzas: <message>, <presence>, and <iq>. The <message> tag contains information you are offering to a channel (or service or whatever). The <presence> tag contains information about you joining, leaving, or changing state. The <iq> ("info/query") tag contains queries to some other service, or a reply to such a query.
If you're defining a new Jabber protocol, you don't get to invent new top-level tags. You have to use those three, and decide which is appropriate at each point in the protocol. However, you do get to decide what goes into each stanza. The "sandboxing" works by putting a namespace attribute (xmlns="...") onto the lower-level tag that you are inventing. The namespace defines the rules by which that tag is interpreted. So you can invent a <unionized> message sub-element for your political-argument protocol, without interfering with the <unionized> element that Steve's molecular-model protocol uses.
(Okay, strained example. Sorry.)
Jabber also gets grumpy about the notion of inventing new attributes for existing tags. Don't do that. Instead, create child tags which have your namespace attribute.
Jabber is definitely against the idea of "free-form" tags. For example, an arbitrary key-value list might be represented as
<list xmlns='yournamespace'>
<key1><value1/><key1> <key2><value2/><key2>
...
</list>
But that would be unZen. Better to have a well-defined tag structure with arbitrary data:
<list xmlns='yournamespace'>
<field name='key1'> <value>value1</value> </field>
...
</list>
Always try to layer your protocol on top of the highest-layer existing protocol that fits. For example, Volity doesn't define new <message> or <iq> stanzas for game commands. Volity is built on Jabber-RPC, which uses <iq> in a regular way. (Specifically, <iq></iq> containing <query xmlns='jabber:iq:rpc'> child tags.)
So, in fact, you wouldn't want to use the <list> format I mentioned above for your key-value list. You'd want to use Jabber Data Forms, which are already in the spec.