两个基本概念，使得xmpp实体之间的小的结构化信息有效载荷能快速地进行异步交换：xml流和xml节。这些术语的定义如下。
<dl></dl>
<dd></dd>
<dl><dd></dd></dl>
或用于 xml节. "发起流" 是从发起方实体 (通常是一个客户端或服务器) 到接收方实体 (通常是一个服务器), 也可视为对应发起方 "连接到" 或 "和......开启会话" 接收方实体. 发起流允许从发起方实体到接收方实体的单向通讯; 为了让接收方实体能够向发起方实体发送节, 接收方实体必须(must) 协商一个相反的流 ("应答流").
xml节是一个xmpp中的基本语义单位. 一个节就是一个第一层元素 (在流的深度=1)，它的元素名是 "message", "presence", 或 "iq" ，而它的合格命名空间是 'jabber:client' 或 'jabber:server'. 相比之下, 任何其他命名空间限定的第一层元素都不是一个xml节 (stream errors, stream features, tls相关的元素, sasl相关的元素, 等等.), 由'jabber:client' 或 'jabber:server' 命名空间限定的
从本质上讲, 一个xml流作为会话期间发送的xml节的信封, 而另一个xml流作为会话期间接收的xml节的信封. 我们可以用如下的简化模型做一个展示.
下表总结了根元素<stream/>的属性。
<presence/>节是一个特定的"广播"或"发布-订阅"机制, 这里多个实体接收关于他们订阅的一个实体的信息(在这个案例中, 是网络可用性信息). 通常, 发布客户端应该发送一个不带有'to'属性的联机状态节, 这种情况下该客户端连接的那个服务器将广播那个节给所有已订阅的实体. 然而, 发布客户端也可以发送一个带有'to'属性的联机状态节, 这种情况下该服务器将路由或递送那个节到期望的接收者. 尽管<presence/>节大部分情况下是由xmpp客户端使用, 它也可能被服务器, 附加服务, 以及任何其他类型呃xmpp实体使用.
发出请求的实体使用'id'属性来跟踪交互过程. 所以, iq交互沿用了结构化数据交换的常见模式，类似 get/result 或 set/result (尽管适当的时候对于某个请求会返回一个error):
<dd>1. 'id'属性对于iq节是必需的.</dd>
get -- 该节请求信息, 查询需要什么数据以完成更多操作, 等等.
set -- 该节为完成某个操作提供需要的数据, 设置新值, 取代旧值, 等等.
result -- 该节是对成功的get或set请求的应答.
<dd>3. 接收到类型为"get"或"set"的iq请求的实体必须返回一个类型为"result"或"error"的iq应答. 该应答必须保留请求中的'id'属性(或为空，如果生成的节没有包含'id'属性).</dd>
<dd>4. 接收到类型为"result"或"error"节的实体不能(must not)发送更多的类型为"result"或"error"的iq应答来应答; 然而, 请求实体可以发送另一个请求(例如, 一个类型为"set"的iq对之前在get/result对中查询到的信息提供特定的信息).</dd>
<dd>5. 类型为"get"或"set"的iq节必须严格地包含一个子元素, 它定义特定请求的语义.</dd>
<dd>6. 类型为"result"的iq节必须包含零或一个子元素.</dd>
jabber:iq:private -- 私有数据存储，用于本地用户私人设置信息，比如用户备注等。
jabber:iq:conference -- 一般会议，用于多个用户之间的信息共享
jabber:x:encrypted -- 加密的消息，用于发送加密消息
jabber:x:expire -- 消息终止
jabber:iq:time -- 客户端时间
jabber:iq:auth -- 简单用户认证，一般用于服务器之间或者服务器和客户端之间的认证
jabber:x:roster -- 内部花名册
jabber:x:signed -- 标记的在线状态
jabber:iq:search -- 用户数据库查询，用于向服务器发送查询请求
jabber:iq:register -- 注册请求，用于用户注册相关信息
jabber:x:iq:roster -- 花名册管理
jabber:x:conference -- 会议邀请，用于向参加会议用户发送开会通知
jabber:x:event -- 消息事件
vcard-temp -- 临时的vcard,用于设置用户的头像以及昵称等
这是从xmpp学习——2、登陆的例子 截取的协议传输过程图。
