XEP-0016
小 (→语法和语义) |
小 (→语法和语义) |
||
第96行: | 第96行: | ||
<item/>元素可以包含一个或多个子元素使得一个实体能够定义对各种需要屏蔽的节的更细微的控制(即, 不只是屏蔽所有节). 允许的元素有: | <item/>元素可以包含一个或多个子元素使得一个实体能够定义对各种需要屏蔽的节的更细微的控制(即, 不只是屏蔽所有节). 允许的元素有: | ||
− | + | :* <message/> -- 屏蔽进来的 message 节 | |
− | + | :* <iq/> -- 屏蔽进来的 IQ 节 | |
− | + | :* <presence-in/> -- 屏蔽进来的 presence 通知 | |
− | + | :* <presence-out/> -- 屏蔽出去的 presence 通知 [[XEP-0016#附录G:备注|5]] | |
− | + | ||
− | + | ||
在'jabber:iq:privacy'命名空间中, 一个类型为"set"的IQ节<query/>子元素不能(MUST NOT)包含多个子元素(即, 该节必须只包含一个<active/>元素, 一个<default/>元素, 或一个<list/>元素); 如果发送实体违反了这个规则, 接收实体必须返回一个<bad-request/>节错误. | 在'jabber:iq:privacy'命名空间中, 一个类型为"set"的IQ节<query/>子元素不能(MUST NOT)包含多个子元素(即, 该节必须只包含一个<active/>元素, 一个<default/>元素, 或一个<list/>元素); 如果发送实体违反了这个规则, 接收实体必须返回一个<bad-request/>节错误. |
2012年11月29日 (四) 03:29的版本
本文的英文原文来自 XEP-0016
XEP-0016: 隐私列表
摘要: 本文定义了一个XMPP协议扩展, 用于启用和禁用与网络上其他实体的通讯.这个协议,最早在RFC 3921的第十单元被标准化,被用于封锁与未知或不良实体的沟通.封锁能够基于Jabber标识符,订阅状态或者花名册群组.被封锁的节点可以是messages,IQs,进入或者输出的presence节点,或者所有节点.本协议也允许实体创建,修改或者删除它的隐私列表,使得不同的列表可以应用到不同的连接资源上,定义一个默认列表,在特定会话期间拒绝隐私列表的使用.
作者: Peter Millard,Peter Saint-Andre
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.
状态: 草案
类型: 标准跟踪
版本: 1.6
最后更新日期: 2007-02-15
注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
目录 |
绪论
几乎所有的即时通讯应用都已经发现,为用户提供一些方法,用来锁定接收自其他用户的消息和数据包是必要的(对于这些封锁的根本原因是取决于一些个别用户的需求).这个文档定义了一个灵活的方法用于锁定通讯.
注释:在此定义的协议可以用来与简单通讯锁定协同,详情请参阅XEP-0191
协议
本章节是被从RFC 3921的第十章节拷贝过来的,而且没有修改,除了message节点在处理阻止实体试图与用户通讯的订阅方面.
大部分即时通讯系统发现,为用户提供一些锁定来自一些特殊用户通讯的方法,是必要的(这在RFC 2779 [3]的5.1.5, 5.1.15, 5.3.2, 和5.4.10 章节也是被要求的).在XMPP协议中,这些工作被采用'jabber:iq:privacy'命名空间的管理个人隐私列表的操作来完成.
服务器端隐私列表成功的完成了以下用例:
- 获取一个人的隐私列表.
- 添加, 删除, 并且编辑一个人的隐私列表.
- 设置, 改变, 或者撤除激活的列表.
- 设置, 改变, 或者撤除缺省的列表(即, 缺省激活的那个列表).
- 基于JID, 群组, 或者订阅类型(或者全部)允许或阻止messages.
- 基于JID, 群组, 或者订阅类型(或者全部)允许或阻止入站的presence通知.
- 基于JID, 群组, 或者订阅类型(或者全部)允许或阻止出站的presence通知.
- 基于JID, 群组, 或者订阅类型(或者全部)允许或阻止IQ节.
- 基于JID, 群组, 或者订阅类型(或者全部)允许或阻止所有通讯.
注释:Presence通知不包括presence订阅,只包括那些已经被订阅了用户presence信息的,并且被广播到实体的presence信息.所以,它只包括了没有'type'属性或者type属性是'unavailable'的presence节.
语法和语义
一个用户可以定义一个或多个隐私列表,并且被存储在用户服务器上.每个<list/>元素在以<item/>元素形式里包含了一个或多个规则,并且每个<item/>元素用属性来定义来定义隐私规则类型,一个特别的值来表示哪个规则应用,相关动作,和项目处理的顺序中.
语法如下所示:
<iq> <query xmlns='jabber:iq:privacy'> <list name='foo'> <item type='[jid|group|subscription]' value='bar' action='[allow|deny]' order='unsignedInt'> [<message/>] [<presence-in/>] [<presence-out/>] [<iq/>] </item> </list> </query> </iq>
如果type是'jid','value'的属性必须包含一个合法的JID.JIDs应该符合如下的法则.
- <user@domain/resource> (仅匹配那个资源)
- <user@domain> (匹配任何资源)
- <domain/resource> (仅匹配那个资源)
- <domain> (匹配域本身, 以及任何 user@domain 或 domain/resource)
如果type是"group", 那么'value'属性应该包含该用户名册中的一个组的名称. (如果一个客户端尝试从一个不存在于该用户名册中的组中更新, 创建, 或删除一个列表条目, 服务器应该给客户端返回一个<item-not-found/>节错误.)
如果type是"subscription", 那么'value'属性必须是如 RFC6121定义的 "both", "to", "from"之一, 或者 "none" , 这里 "none" 包括那些该用户完全不知道因而根本不在用户名册中的实体. 这些值是精确匹配的, 所以 "both" 意味着双向订阅(不是只有 "from" 或 "to" ).
如果没有包含'type'属性, 规则提供 "fall-through" 用例.
必须包含'action'属性并且它的值必须要么是"allow"要么是"deny". 4
必须包含'order'属性并且且它的值必须是一个在列表所有条目中具有唯一性的非负整数. (如果一个客户端尝试以不唯一的序号值来创建或更新一个列表, 服务器必须给客户端返回一个 <bad-request/> 节错误.)
<item/>元素可以包含一个或多个子元素使得一个实体能够定义对各种需要屏蔽的节的更细微的控制(即, 不只是屏蔽所有节). 允许的元素有:
- <message/> -- 屏蔽进来的 message 节
- <iq/> -- 屏蔽进来的 IQ 节
- <presence-in/> -- 屏蔽进来的 presence 通知
- <presence-out/> -- 屏蔽出去的 presence 通知 5
在'jabber:iq:privacy'命名空间中, 一个类型为"set"的IQ节<query/>子元素不能(MUST NOT)包含多个子元素(即, 该节必须只包含一个<active/>元素, 一个<default/>元素, 或一个<list/>元素); 如果发送实体违反了这个规则, 接收实体必须返回一个<bad-request/>节错误.
当一个客户端添加或更新一个privacy list, <list/>元素应该至少包含一个<item/>子元素; 当一个客户端移除一个privacy list, <list/>元素不能(MUST NOT)包含任何<item/>子元素.
当一个客户端更新一个privacy list, 它必须包含所有期望的条目(即, 不是一个"增量").