节通用属性
from
识别节的起始JID,from 地址不由发送客户端提供,而是由发送者的服务器添加邮戳,以避免地址欺骗,不建议手动设置。注意:如果客户端-服务器流中接收到的节上没有from属性,就意味着该节来源于服务器自身。
to
识别节的结束JID,与from属性类似。注意:如果客户端-服务器流中没有to属性,那么服务器将假设它是发向服务器自身的消息。
type
type 属性指定了、或节的具体类型。
id
为节指定id属性以辅助识别响应。对于节,这个属性是必需的,但对于其他两个节,该属性则是可选的。如果某节是为响应一个携带 id 属性的节而产生的,那么这个应答节必须包含一个携带相同值的 id 属性。
presence节
<presence>节控制并报告实体的可访问性,有两种主要的出席元素可以表达更丰富的信息,<show/>元素和<status/>元素,<show/>元素有四种预设值,包含“在线”,“离线”,“离开”和“请勿打扰”,<status/>元素允许用户指定自由的格式、易于阅读的文本来在更详细的层次上描述用户可用性。此外,这个节还用来建立和终止向其他实体发布出席订阅。
presence示例
<presence>
<show>away</show>
<status>Having a spot of tea</status>
</presence>
普通presence节
普通<presence>节包含三种 type 属性表示方式
1 type属性值为unavailable
2 type属性值为error
3 不包含type属性项,表示type值为available
扩展presence节
扩展是相比较普通presence定义的,包含更多详细信息,比如当前用户心情或者正在听的歌曲等。presence节信息会通过广播给所有联系人,所以扩展presence节并不推崇
出席订阅
用户的服务器会自动地将出席信息广播给那些订阅该用户出席信息的联系人,同时,用户从所有订阅的联系人那里接收到出席更新信息,所以出席订阅是有方向的,通过通过type标识:subscribe、unsubscribe、subscribed、unsubscribed
定向出席
定向出席是一种直接发给另一个用户或其他实体的普通<presence>节,这种节用来向那些没有进行出席订阅(通常因为只是临时需要出席信息)的实体传达出席状态信息,常被用于加入和离开多用户聊天房间(聊天室)。
下线含义
1 server向user联络列表中的所有人广播user不可用通知
2 server向所有订阅了该user 的实体广播不可用状态的通知
3 停止向user 发送其他实体的presence 通知
4 server停止发送message给user,转为offline message
message节
<message>节用来从一个实体向另一个实体发送消息,消息常被用于IM、groupchat、alerts和notifications 以及其他应用。
message示例
<message from='user1@ejabberd.org/drawing_room'
to='user2@nassue.org'
type='chat'>
<body>Come, User2, I must have you dance.</body>
<thread>4fd61b376fbc4950b9433f031a5595ab</thread>
</message>
message消息通过type属性分为5中类型
1 chat 在一对一聊天对话上下文中发送,主要关注私有的、一对一通信的 IM 应用程序
2 error 用于答复某条导致错误的消息
3 normal
4 groupchat 用于在多人聊天中发送的消息,用来区分多人聊天参与者发送的定向的私有消息与参与者发送给聊天室中所有人的广播消息
5 headline 类型为headline 的消息用于警示和通告
message消息内容
尽管<message>节可以包含任意扩展元素,但<body>和<thread>元素是为向消息中添加内容而提供的正常机制,这两种子元素均是可选的。对话(就像电子邮件一样)可以形成线索,线索中的每条消息都与相同的对话相关联。可以通过向<message>节中添加一个<<thread>元素来创建线索。<thread>元素的内容是一个用来区分不同线索的唯一标识符。应答节应该包含与它所应答的节相同的<thread>元素。
iq节
<iq>节表示的是 Info/Query(信息与查询),它为 XMPP 通信提供请求与响应机制,类似于HTTP 中的 GET、POST、PUT 方法。
<iq>节有四种,通过该节的 type 属性可划分为4中:
1 get 请求实体信息(类似http GET)
2 set 请求实体提供信息或发起一个请求(类似http POST PUT)
3 result 返回一个get信息,或者确认一个set请求
4 error 通知请求实体,无法处理get或set请求
iq示例
<iq from='user1@nassue.org/garden'
type='get'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
</iq>
<iq to='user1@nassue.org/garden'
type='error'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
<error type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
user1 向服务器发送了一个格式错误的花名册请求,服务器使用一个错误提示节作为响应。
<iq from='user1@nassue.org/garden'
type='get'
id='roster2'>
<query xmlns='jabber:iq:roster'/>
</iq>
<iq to='user1@nassue.org/garden'
type='result'
id='roster2'>
<query xmlns='jabber:iq:roster'>
<item jid='user2@longzhu.lit' name='SunWukong'/>
<item jid='user3@huoying.lit' name='MingRen'/>
</query>
</iq>
在重新发送正确的请求之后,服务器将user1的简短花名册返回。
<iq from='user1@nassue.org/garden'
type='set'
id='roster3'>
<query xmlns='jabber:iq:roster'>
<item jid='BeiJita@longzhu.lit' name='Mr. BJ'/>
</query>
</iq>
<iq to='user1@nassue.org/garden'
type='result'
id='roster3'/>
user1试图将BiJita添加到自己的花名册中,服务器用一个空白 IQ-result 节来指出添加成功,如果应答节只是成功确认,那么 IQ-result 节通常是空白的。
error节
所有三种 XMPP 节都有一个 error 类型,而且错误提示节的每种类型的内容都是按照同一模式排列。错误提示节具有定义明确的结构,通常包含原节(肇事节)的内容、通用错误信息以及应用程序特有的错误条件和信息(可选)。
<error>必备type属性,可分为5种:
1cancel 表示不应该重试该动作,这是因为它总会失败
2 continue 代表一条警告信息
3 modify 表示发送的数据需要一些修改才会被接受
4 auth 通知实体在以某种方式进行身份验证之后重试该动作
5 wait 报告服务器临时遇到问题,应该在稍后将原节原封不动地重新发送
<error>子元素还必须包含一个错误条件(从已定义条件列表中选择一个)作为它的子元素,它还可以包含一个<text>元素来进一步指出有关该错误的详细信息。
error示例
<iq from='user1.ejabberd.org'
to='user2@nassue.lit/sitting_room'
type='error'
id='subscribe1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='latest_books'
jid='user2@nassue.lit'/>
</pubsub>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<closed-node xmlns='http://jabber.org/protocol/pubsub#errors'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
You must be on the whitelist to subscribe to this node.
</text>
</error>
</iq>
该错误提示的类型是 cancel,该值表示不应该重试该动作,而条件<not-allowed/>指出了一般性故障,<text/>子元素包含了问题描述。最后,应用程序条件元素<closed-node/>给出了精确的应用程序错误提示信息。