XEP-0045 - 版本历史

Zyhserry: /* 服务端 */

2014-01-02T06:01:09Z

服务端

Zyhserry: /* 服务端 */

2014-01-02T06:00:37Z

服务端

Zyhserry: /* 随后的房间配置 */

2014-01-02T03:17:26Z

随后的房间配置

Zyhserry: /* 默认角色 */

2013-12-27T07:27:50Z

默认角色

Zyhserry: /* 默认角色 */

2013-12-27T07:25:53Z

默认角色

Zyhserry: /* 默认角色 */

2013-12-27T07:24:56Z

默认角色

Broodingimu: /* 通用术语 */

2013-07-17T01:53:44Z

通用术语

2012年8月27日 (一) 07:46 Zoeyyoung

2012-08-27T07:46:14Z

Zoeyyoung: /* 角色和岗位 */

2012-08-27T07:05:30Z

角色和岗位

Zoeyyoung: /* 人物 */

2012-08-27T06:57:54Z

人物

@@ 第5,547行： / 第5,547行： @@
 # 在处理一个被主持的房间里游客发送的消息时, 一个MUC服务可以 MAY 通过一个主持人让每个消息排队等待批准并且可以 MAY 通知发送者消息正在等待批准; 然而, 这一行为是可选的 OPTIONAL, 并且一个消息批准协议的定义 (例如, 使用'''XEP-0004'''定义的数据表单) 超出了本文的范围.
-# 对于一个 MUC 服务来说，在特定事件发生时提供房间内的消息是很常见的, 例如当标题变更时, 当一个房客加入或退出时, 或当一个房间被销毁时. 这类消息完全是可选的 OPTIONAL 并且留给实现或布署来决定, 但如果使用了，则必须 MUST 是从房间JID本身(<room@service>) 而不是从一个特定的
+# 对于一个 MUC 服务来说，在特定事件发生时提供房间内的消息是很常见的, 例如当标题变更时, 当一个房客加入或退出时, 或当一个房间被销毁时. 这类消息完全是可选的 OPTIONAL 并且留给实现或布署来决定, 但如果使用了，则必须 MUST 是从房间JID本身(<room@service>) 而不是从一个特定的房客(<room@service/nick>)发送的类型为 "groupchat" 类型的消息. 无论如何, 通常接收的客户端倾向于基于房间的事件以及MUC提供的特定状态码来生成类似的消息(例如, 用户加入或退出) ; 这将帮助确保这类消息的正确的本地化.
-房客(<room@service/nick>)发送的类型为 "groupchat" 类型的消息. 无论如何, 通常接收的客户端倾向于基于房间的事件以及MUC提供的特定状态码来生成类似的消息(例如, 用户加入或退出) ; 这将帮助确保这类消息的正确的本地化.
 # 出于礼貌, 一个MUC服务可以 MAY 发送一个房间外的 <message/> 给一个被踢的或被禁止的房客, 并且可以 MAY 广播一个房间内的 <message/> 给所有剩余的房客通知他们该房客已被该房间踢出或禁止. 无论如何, 这类消息是可选的 OPTIONAL, 并且事实上是多余的，因为接收的客户端生成这类消息所必需的信息已经通过MUC服务发送的出席信息节(特别是状态码)得到了.
 # 出于礼貌, 如果一个用户的岗位变更了而该用户不在房间里，一个MUC服务可以MAY发送一个房间外的 <message/> ; 这消息应该 SHOULD 被从房间发送给该用户的纯JID, 可以 MAY 包含一个 <body/> 元素描述岗位变更, 并且必须 MUST 包含一个状态码 101.

@@ 第5,547行： / 第5,547行： @@
 # 在处理一个被主持的房间里游客发送的消息时, 一个MUC服务可以 MAY 通过一个主持人让每个消息排队等待批准并且可以 MAY 通知发送者消息正在等待批准; 然而, 这一行为是可选的 OPTIONAL, 并且一个消息批准协议的定义 (例如, 使用'''XEP-0004'''定义的数据表单) 超出了本文的范围.
-# 对于一个 MUC 服务来说，在特定时间发生时提供房间内的消息是很常见的, 例如当标题变更时, 当一个房客加入或退出时, 或当一个房间被销毁时. 这类消息完全是可选的 OPTIONAL 并且留给实现或布署来决定, 但如果使用了，则必须 MUST 是从房间JID本身(<room@service>) 而不是从一个特定的
+# 对于一个 MUC 服务来说，在特定事件发生时提供房间内的消息是很常见的, 例如当标题变更时, 当一个房客加入或退出时, 或当一个房间被销毁时. 这类消息完全是可选的 OPTIONAL 并且留给实现或布署来决定, 但如果使用了，则必须 MUST 是从房间JID本身(<room@service>) 而不是从一个特定的
 房客(<room@service/nick>)发送的类型为 "groupchat" 类型的消息. 无论如何, 通常接收的客户端倾向于基于房间的事件以及MUC提供的特定状态码来生成类似的消息(例如, 用户加入或退出) ; 这将帮助确保这类消息的正确的本地化.
 # 出于礼貌, 一个MUC服务可以 MAY 发送一个房间外的 <message/> 给一个被踢的或被禁止的房客, 并且可以 MAY 广播一个房间内的 <message/> 给所有剩余的房客通知他们该房客已被该房间踢出或禁止. 无论如何, 这类消息是可选的 OPTIONAL, 并且事实上是多余的，因为接收的客户端生成这类消息所必需的信息已经通过MUC服务发送的出席信息节(特别是状态码)得到了.

@@ 第4,134行： / 第4,134行： @@
 </source>
-如果没有其他所有者，服务不能 MUST NOT 允许一个所有者撤销他或她自己的所有权; 如果一个所有者企图这么干, 服务必须 MUST 返回一个 <conflict/> 错误给这个所有者. 然而, 如果没有其他所有者，服务应该 SHOULD 允许一个所有者撤销自己的所有者权限.
+如果没有其他所有者，服务不能 MUST NOT 允许一个所有者撤销他或她自己的所有权; 如果一个所有者企图这么干, 服务必须 MUST 返回一个 <conflict/> 错误给这个所有者. 然而, 如果有其他所有者，服务应该 SHOULD 允许一个所有者撤销自己的所有者权限.
 如果一次房间配置变更导致一个用户获得所有者权限，而这个用户正在房间里, 房间必须 MUST 为那个用户发送更新的出席信息给所有房客, 表明状态的变更，通过包含一个遵循 'http://jabber.org/protocol/muc#user' 名字空间的的 <x/> 元素以及一个 <item/> 子元素，该 <item/> 子元素的 'affiliation' 属性值为 "owner" 或 'role' 属性值为根据岗位和房间类型确定的适当的值(推荐为"moderator").

@@ 第289行： / 第289行： @@
 ====默认角色====
-服务必须（SHOULD）根据用户的岗位信息来设置房客在房间里的初始角色（没有与岗位（“outcast”）关联的角色，因为outcast用户不允许进入房间）。下表对每个岗位对应的初始角色进行了总结。
+服务必须（SHOULD）根据用户的岗位信息来设置房客在房间里的默认角色（没有与岗位（“outcast”）关联的默认角色，因为outcast用户不允许进入房间）。下表对与每个岗位关联的默认角色进行了总结。
-表4: 基于岗位的初始角色
+表4: 基于岗位的默认角色
 {|border="1" cellspacing="0"

@@ 第291行： / 第291行： @@
 服务必须（SHOULD）根据用户的岗位信息来设置房客在房间里的初始角色（没有与岗位（“outcast”）关联的角色，因为outcast用户不允许进入房间）。下表对每个岗位对应的初始角色进行了总结。
-Table 4: 基于岗位的初始角色
+表4: 基于岗位的初始角色
 {|border="1" cellspacing="0"

@@ 第125行： / 第125行： @@
 Occupant(房客) -- 一个房间里的任何Jabber用户 (这是一个 "抽象类" 并且不对应任何特定的角色).
 Outcast(被排斥者) -- 一个被某个房间禁止的用户. 一个被排斥者的岗位是 "outcast".
@@ 第140行： / 第142行： @@
 Room ID(房间ID) -- 一个房间JID的节点标识符部分, 它可以是不透明的因而对人类用户没有什么含义(见  语法的商业规则Business Rules for syntax); 与之相对的是房间名.
-Room JID(房间JID) -- 在一个房间上下文中的一个房客，以 <room@service/nick> 来标识; 与之相对的是纯JID和全JID.
+Room JID(房间JID) -- 房间地址，如 <room@service>
 Room Name(房间名) -- 一个用户友好的, 自然语言的房间名字, 由房间所有者配置并在服务查询中展示; 与之相对的是房间ID.

←上一版本		2012年8月27日 (一) 07:46的版本
第284行：		第284行：

	*** 主持人不能(MUST NOT)从一个管理员或所有者收回发言权.		*** 主持人不能(MUST NOT)从一个管理员或所有者收回发言权.
		+
		+	====默认角色====
		+
		+	The following table summarizes the initial default roles that a service SHOULD set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are not allowed to enter the room).
		+
		+	Table 4: Initial Role Based on Affiliation
		+
		+	{\|border="1" cellspacing="0"
		+	!Room Type !!None !!Member !!Admin !!Owner
		+	\|-
		+	\|Moderated \|\|Visitor \|\|Participant \|\|Moderator \|\|Moderator
		+	\|-
		+	\|Unmoderated \|\|Participant \|\|Participant \|\|Moderator \|\|Moderator
		+	\|-
		+	\|Members-Only \|\|N/A * \|\|Participant \|\|Moderator \|\|Moderator
		+	\|-
		+	\|Open \|\|Participant \|\|Participant \|\|Moderator \|\|Moderator
		+	\|}
		+	* Entry is not permitted.

	====变更角色====		====变更角色====

@@ 第204行： / 第204行： @@
 |}
-==角色和岗位==
+==角色(Roles)，岗位(Affiliations)和权限(Privileges)==
 有两个尺度我们可以用来衡量一个用户的连接或在一个房间的地位. 一个是用户和一个房间的长期的联系 -- 例如, 用户的状态是一个所有者或一个被排斥者. 另一个是当用户驻留于一个聊天室的时候的角色 -- 例如, 一个房客的地位是主持人,有权踢出游客和与会者. 这两个尺度各自都是唯一的, 因为一个岗位是跨越访问的, 而一个角色只存在于一次访问期间. 另外, 在角色和岗位之间没有一对一的对应关系; 例如, 某个不从属于某房间的人可能成为一个(临时的)主持人, 一个成员可能在一个被主持的房间中是一个与会者或游客者. 这些概念以下全面解释.
@@ 第216行： / 第224行： @@
 !名称 !!支持
 |-
-| 主持人   ||必需的
+| 主持人Moderator   ||必需的
 |-
-| 无       ||缺少角色
+| 无None       ||缺少角色
 |-
-| 与会者   ||必需的
+| 与会者Participant   ||必需的
 |-
-| 游客     ||推荐的
+| 游客Visitor     ||推荐的
 |}

@@ 第188行： / 第188行： @@
 Unsecured Room(非保密房间) -- 任何人不需要提供密码就可以进入的房间; 反义词: 密码保护房间.
-===人物===
+===登场人物===
-本文的大部分例子使用了 the scenario of the witches' meeting held in a dark cave at the beginning of Act IV, Scene I of Shakespeare's Macbeth, 在这里代表"darkcave@macbeth.shakespeare.lit"聊天室. 人物如下:
+本文的大部分例子使用了莎士比亚的《麦克白》中第四幕第一场开头女巫在黑洞中开会的场景，在这里使用"coven@chat.shakespeare.lit"代表聊天室. 人物如下:
 '''表1: 剧中人'''
 {|border="1" cellspacing="0"
-!房间昵称 !!全 JID !!岗位
+!Room Nickname !!Full JID!!Affiliation
 |-
-|firstwitch ||crone1@shakespeare.lit/desktop ||所有者
+|firstwitch ||crone1@shakespeare.lit/desktop ||Owner
 |-
-|secondwitch ||wiccarocks@shakespeare.lit/laptop ||管理员
+|secondwitch ||wiccarocks@shakespeare.lit/laptop ||Admin
 |-
-|thirdwitch ||hag66@shakespeare.lit/pda ||无
+|thirdwitch ||hag66@shakespeare.lit/pda ||None
 |}