XEP-0084

来自Jabber/XMPP中文翻译计划
（版本间的差异）
跳转到： 导航, 搜索
(→发布者禁止头像发布)
(→协议语法)
第253行： 第253行：
  
 
==协议语法==
 
==协议语法==
 +
 +
pubsub的PEP子集要求在命名空间和节点之间将存在一对一的关系. 因为在这里定义的协议规定了两种节点的使用(一个用于头像数据一个用于头像元数据), 我们定义了两个命名空间, 每个都有一个相应的根元素:
 +
 +
:* <data xmlns='urn:xmpp:avatar:data'/>
 +
:* <metadata xmlns='urn:xmpp:avatar:metadata'/>
 +
 +
更多定义如下.
 +
 
===Data元素===
 
===Data元素===
 
===Metadata元素===
 
===Metadata元素===
 
====Info元素====
 
====Info元素====
 
====Pointer元素====
 
====Pointer元素====

2013年7月24日 (三) 02:26的版本


本文的英文原文来自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).

用户发布元数据通知

任何时候发布者希望修改当前头像, 它必须 MUST 更新元数据节点.

以下例子显示的指定可用头像数据的元数据，仅针对一个格式 ("image/png") 并且只可在数据节点访问.

例子 3. 发布头像元数据 

<iq type='set' from='juliet@capulet.lit/chamber' id='publish2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:avatar:metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <info bytes='12345'
                id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                height='64'
                type='image/png'
                width='64'/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

以下例子显示的指定可用头像数据的元数据，对一个 HTTP URL 可用.

例子 4. 发布头像元数据 

<iq type='set' from='juliet@capulet.lit/chamber' id='publish2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:avatar:metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <info bytes='23456'
                height='64'
                id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/gif'
                url='http://avatars.example.org/happy.gif'
                width='64'/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

订阅者接收元数据通知

接着用户的虚拟 virtual pubsub 服务将发送元数据通知给那些订阅了该用户的元数据节点的实体或那些声明拥有接收头像元数据能力的联系人(通过在 实体能力 8 中包含一个"urn:xmpp:avatar:metadata+notify"特性).

例子 5. 订阅者接收头像元数据通知 

<message to='romeo@montague.lit' from='juliet@capulet.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:avatar:metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <info bytes='12345'
                height='64'
                id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                width='64'/>
        </metadata>
      </item>
    </items>
  </event>
  <addresses xmlns='http://jabber.org/protocol/address'>
    <address type='replyto' jid='juliet@capulet.lit/chamber'/>
  </addresses>
</message>

如上所示, 取决于节点配置, 这个条目可以包含关于该发布资源的 扩展的节地址 9 信息(详见 XEP-0060 ).

订阅者获取数据

在接收到该通知后, 每个订阅者应该决定是否有一个该头像的本地缓存副本(它可以通过ItemID搜索一个图像标识符). 如果该订阅者已经有一个该头像的本地缓存副本, 它不能(MUST NOT)获取该图像数据.

如果该订阅者没有该头像图片的本地缓存副本, 它应该获取该数据. 它可以发送一个pubsub的 获取条目 请求给该数据节点, 指定适当的ItemID.

例子 6. 订阅者通过ItemID请求最后的条目 

<iq type='get'
    from='romeo@montague.lit/home'
    to='juliet@capulet.lit'
    id='retrieve1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:avatar:data'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'/>
    </items>
  </pubsub>
</iq>

运行在该用户的服务器上的PEP服务接着应该返回头像数据.

例子 7. PEP服务返回头像数据 

<iq type='result' 
    from='juliet@capulet.lit' 
    to='romeo@montague.lit/home' 
    id='retrieve1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:avatar:data'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <data xmlns='urn:xmpp:avatar:data'>
          qANQR1DBwU4DX7jmYZnncm...
        </data>
      </item>
    </items>
  </pubsub>
</iq>

如果被发送给元数据节点的<info/>元素拥有一个'url'属性, 该头像数据位于一个URL. 所以, 为了获取那一内容类型的头像图片数据, 该请求实体必须发送一个HTTP请求给指定的URL. 干这事的方法超出了本协议的范围(见 RFC 2616 ).

发布者禁止头像发布

为了临时禁止头像发布, 该用户发布一个空的<metadata/>元素给该元数据节点.

例子 8. 临时禁止头像发布 

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

照旧, 该元数据的订阅者将接着收到该通知.

例子 9. 订阅者获取头像元数据通知 

<message to='romeo@montague.lit/home' from='juliet@capulet.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:avatar:metadata'>
      <item>
        <metadata xmlns='urn:xmpp:avatar:metadata'/>
      </item>
    </items>
  </event>
</message>

注意: 在本协议的一个早期版本中, 用户通过发送包含一个<stop/>子元素的<metadata/>元素来表明它想禁止发布. 为了保持和其他PEP载荷格式的一致性, 对<stop/>元素的支持被废弃了.

协议语法

pubsub的PEP子集要求在命名空间和节点之间将存在一对一的关系. 因为在这里定义的协议规定了两种节点的使用(一个用于头像数据一个用于头像元数据), 我们定义了两个命名空间, 每个都有一个相应的根元素:

  • <data xmlns='urn:xmpp:avatar:data'/>
  • <metadata xmlns='urn:xmpp:avatar:metadata'/>

更多定义如下.

Data元素

Metadata元素

Info元素

Pointer元素

来自“http://wiki.jabbercn.org/index.php?title=XEP-0084&oldid=3203”
个人工具