XEP-0084

来自Jabber/XMPP中文翻译计划
2010年7月1日 (四) 17:42How (讨论 | 贡献)的版本
跳转到: 导航, 搜索


本文的英文原文来自XEP-0084

XEP-0084: 用户头像

摘要: 本文定义了一个XMPP协议扩展,用于交换用户头像,一个小的和自然人用户相关的图像或图标. 该协议定义了头像元数据和图像数据本身的承载格式. 承载格式典型地使用定义于XEP-0163的 XMPP发布-订阅个人事件脚本 协议来传输

作者: Peter Saint-Andre, Peter Millard, Thomas Muldowney, Julian Missig

版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.

状态: 草案

类型: 标准跟踪

版本: 1.1

最后更新日期: 2008-11-05


注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.


目录

绪论

很多通讯应用允许那个应用的用户拥有一个相关的小图片或图标. 通常, 这样一个 "avatar" 不一定是一个用户的真正长相的图片, 而可能是一个用户期望的自己的图像 (经常很怪诞) 或该用户暂时的状态 (例如心情或活动). 本文定义一个方法来把头像合并到目前的 Jabber/XMPP 系统,即把该功能架在 XMPP发布-订阅 1 扩展 ("pubsub")之上, 特别是 个人事件协议 2 子集 ("PEP"), 它被定义用于符合 RFC 3921 3的 XMPP 即时消息和出席信息系统的场景.

本协议在这里定义使用两种 pubsub 节点(nodes): 一个 node 用于元数据 "metadata",关于头像状态的 (称为 元数据节点 "metadata node") ;另一个是用于头像数据本身 (称为 数据节点 "data node"). 这个从数据中分离出来的元数据 metadata 节省了带宽,并且使发布者和订阅者能够缓存头像数据. (例如, 一个用户可能在两个或三个头像之间切换, 这种情况下用户的联系人们可以显示这些图片的一个本地缓存版本而不用每次检索或接收完整的图片.)

这个协议也允许头像数据存储在一个可通过HTTP (见 RFC 2616 4) 访问的 URL 上. 5 如果一个 pubsub-aware 数据仓库不可用,作为一个回退机制这是有帮助的. 它也使头像图片能被托管在公共的网站上 (例如, 一个面向终端用户的社区网站) 并从那个网站检索到而不是直接由发布的客户端以任何方式来处理.

最后, 本协议也使 XMPP 应用能选择性地和托管了用户头像的第三方服务(例如, 在线游戏系统和虚拟世界)集成.

一旦 XMPP 发布-订阅 的 PEP子集被足够广泛地实现和布署,本协议准备将来取代 基于IQ的头像 6基于vCard的头像 7.

需求

本文涉及以下的头像发布的用例:

  1. 发布头像数据
  2. 更新当前头像的元数据
  3. 禁止头像

本文涉及以下头像订阅的用例:

  1. 发现头像可用性
  2. 接收头像变更通知
  3. 通过pubsub获取头像数据
  4. 通过HTTP获取头像数据

基本处理流程

发布和更新用户头像的流程如下:

  1. 用户用 "image/png" content-type 格式发布头像数据到数据节点 data node,并可选的地发布其他格式 content-types 到 HTTP URLs.
  2. 用户发布已更新头像通知到元数据节点 metadata node, 伴随 ItemID ,它是"image/png" content-type 的图像数据的 SHA-1 哈希值 (注意: 这是该图像数据本身的一个哈希, 而不是base64编码过的那个版本).
  3. 订阅者接收通知.
  4. 可选的 (且如果必要), 订阅者使用 pubsub retrieve-items 特性 (或通过 HTTP)从数据节点 data node 获取由 ItemID 标识的头像数据.
  5. 可选的, 用户禁止头像显示.

这个处理流程在随后的章节描述得更加完整.

注意: 在发布头像数据和元数据之前, 用户必须 MUST 根据定义于 XEP-0163 的流程确定是否他或她的服务器支持pubsub的PEP子集,因为这个支持简化了头像发布. 以下例子假定PEP服务可用.

用户发布数据

在更新头像元数据节点之前, 发布者必须 MUST m确保头像数据在数据节点或URL是可用的. 当发布头像数据到数据节点时, 发布者必须 MUST 确保 pubsub ItemID 是该"image/png" 格式数据的 SHA-1 哈希值 (这被订阅者用于决定是否可以使用本地缓存副本来显示).

以下例子展示发布头像数据到数据节点时发送的 XML 结构.

例子 1. 发布头像数据到数据节点

<iq type='set' from='juliet@capulet.lit/chamber' id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:avatar:data'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <data xmlns='urn:xmpp:avatar:data'>
          qANQR1DBwU4DX7jmYZnncm...
        </data>
      </item>
    </publish>
  </pubsub>
</iq>

例子 2. Pubsub服务应答成功

<iq type='result' to='juliet@capulet.lit/chamber' id='publish1'/>

如果头像将通过 HTTP 而不是 pubsub 数据节点可用, 发布者必须 MUST 要么检查这个 HTTP URL 是否存在头像数据,要么通过标准的 HTTP 方法发布它 (这些方法超出了本协议的范围; 反考 RFC 2616).

用户发布元数据通知

订阅者接收元数据通知

订阅者获取数据

发布者禁止头像发布

个人工具