XEP-0153

2011年3月4日 (五) 06:34的最后版本

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

XEP-0153: 基于电子名片的头像

摘要: 本文提供了一个基于电子名片的历史文档用于交换用户头像.

作者: Peter Saint-Andre

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

状态: 活跃的

类型: 历史的

版本: 1.0

最后更新日期: 2006-08-16

注意: 这个历史的规范提供了目前在Jabber/XMPP社区中使用的一个协议.本文不是XMPP标准化基金会标准跟踪过程中的标准跟踪协议,无论如何,将来它可能被转化为标准跟踪,也可能被一个更新的协议取代.

绪论

有好几种中建议的协议可以通过Jabber/XMPP交流用户的头像信息(参考 基于IQ的头像 1 和 用户头像 2)。本文档描述了另一个目前在Jabber/XMPP网络中使用的协议。本文是历史的并且没有意图建议一个标准跟踪协议。然而，未来的协议可能会改进本文档。

需求

在此描述的协议，在设计时需要满足以下要求

• 允许用户在vCard中存储图像信息

• 在<presence/>节中标识图像信息的变更。

• 允许联系人获取用户的图像信息，即使用户处于离线状态。

• 允许联系人不用向用户的特定客户端发出请求而获取用户的图像信息，从而节省带宽。

用例

用户发布个人头像

在通知联系人有关用户的图像信息前，用户的客户端首先根据在vcard-temp 3 定义的协议发布用户公开的vCard信息。

例子1 用户客户端在vCard中发布头像信息

<iq from='juliet@capulet.com' 
    type='set'
    id='vc1'>
  <vCard xmlns='vcard-temp'>
    <BDAY>1476-06-09</BDAY>
    <ADR>
      <CTRY>Italy</CTRY>
      <LOCALITY>Verona</LOCALITY>
      <HOME/>
    </ADR>
    <NICKNAME/>
    <N><GIVEN>Juliet</GIVEN><FAMILY>Capulet</FAMILY></N>
    <EMAIL>jcapulet@shakespeare.lit</EMAIL>
    <PHOTO>
      <TYPE>image/jpeg</TYPE>
      <BINVAL>
        Base64-encoded-avatar-file-here!
      </BINVAL>
    </PHOTO>
  </vCard>
</iq>

例子2. 用户服务器承认收到发布信息

<iq to='juliet@capulet.com' type='result' id='vc1'/>

接下来，用户客户端根据RFC 3174 4 计算用户图像的SHA1哈希值(不是base64编码)。此哈希值包含在用户的出席信息中，该出席信息包含了'vcard-temp:x:update'命名空间限定的<x/>元素及其<photo/>子元素，就如下例子显示：

例子3. 用户客户端在出席信息广播中包含了图像信息的哈希值

<presence from='juliet@capulet.com/balcony'>
  <x xmlns='vcard-temp:x:update'>
    <photo>sha1-hash-of-image</photo>
  </x>
</presence>

用户服务器广播该出席信息给所有订阅了用户出席信息的联系人。

联系人获取头像

当接收者客户端获得图像的哈希值，它就应该(SHOULD)检查该哈希值确定是否有该图像的缓存副本。如果没有，它根据 XEP-0054 中的协议获取发送者的完整vCard(注意该请求发送给用户的纯JID，而不是全JID)：

例子4. 联系人客户端请求用户的vCard信息

<iq from='romeo@montague.net/orchard' 
    to='juliet@capulet.com'
    type='get' 
    id='vc2'>
  <vCard xmlns='vcard-temp'/>
</iq>

例子5. 服务器根据用户的行为返回vCard信息

<iq from='juliet@capulet.com' 
    to='romeo@montague.net/orchard' 
    type='result'
    id='vc2'>
  <vCard xmlns='vcard-temp'>
    <BDAY>1476-06-09</BDAY>
    <ADR>
      <CTRY>Italy</CTRY>
      <LOCALITY>Verona</LOCALITY>
      <HOME/>
    </ADR>
    <NICKNAME/>
    <N><GIVEN>Juliet</GIVEN><FAMILY>Capulet</FAMILY></N>
    <EMAIL>jcapulet@shakespeare.lit</EMAIL>
    <PHOTO>
      <TYPE>image/jpeg</TYPE>
      <BINVAL>
        Base64-encoded-avatar-file-here!
      </BINVAL>
    </PHOTO>
  </vCard>
</iq>

业务规则

在出席信息中包含更新

下面的规则应用于在广播的出席信息中包含更新的子元素(<x xmlns='vcard-temp:x:update'/>：

1. 如果客户端支持此处的协议，它必须(MUST)在它发送的每个广播信息中包含update子元素而且应该(SHOULD)在直接出席信息中也包含update子元素(比如，在加入多用户聊天 5 室时直接发送的出席信息)

2. 如果客户端没有准备发布图像，它必须(MUST)发送空的update子元素，比如：

例子6. 用户没有准备发送图象

<presence>
  <x xmlns='vcard-temp:x:update'/>
</presence>

3．如果没有图像要被发布，photo元素必须(MUST)为空，例如：

例子7. 没有图像被发送

<presence>
  <x xmlns='vcard-temp:x:update'>
    <photo/>
  </x>
</presence>

如果客户端随后获得图像(比如，通过更新或者查询vCard)，它就应该(SHOULD)发布一个新的，包含字符的<photo/>元素的出席信息。

注意：这可以让接收者能够识别是缺少头像(空的photo元素)还是不支持本协议(空的子元素)。

下载和更新vCard

下列的规则适用于下载和更新vCard：

1. 客户端不能(MUST NOT)在从未下载过当前vCard的情况下声明一个图像。一旦它这样做，它有可能(MAY)是在发布一个图像。无论如何，客户端必须(MUST)在上传了新的图像后声明新的头像信息。在这种情况下，客户端可以(MAY)选择不重新下载vCard以验证此photo的内容。
2. 在给定的会话中，客户端不能(MUST NOT)多次上传同一个头像。客户端可以(MAY)在登陆后上传图像到vCard，但是不能(MUST NOT)再次上传，除非用户改变了头像。
3. 客户端不能(MUST NOT)为确定是否更新图像的哈希值而去调查用户的vCard的新版本

多资源

Jabber/XMPP允许同一个JID同时有多个资源被验证。这就导致了在多个资源关注同一个图像时发生冲突的可能。当客户端从同一个JID的不同资源收到出席广播信息时，将适用下列规则：

1. 如果从另一个资源收到的出席信息节点没有包含update子元素，那表示另一个资源不支持vCard-base avatars。那个资源可以修改vCard文本的信息(包括photo元素)；因为调查vCard update是不允许的，客户端必须(MUST)停止发布图像哈希值。然而，客户端可以(MAY)在所有不兼容的资源下线之后重置图片的hash。
2. 如果从其他资源受到的出席信息中包含update子节点，那么其他资源是遵循vCard-based avatars协议的。那么有3种可能的情况。

• 如果更新子元素是空的，那么其他资源支持该协议但是没有自己的图像。因此。客户端可以忽略其他资源，继续以现有的图像哈希值广播出席消息。

• 如果更新子元素里包含一个空的photo元素，那么其他元素使用一个空的<BINVAL>更新了vCard。因此客户端必须(MUST)查询vCard。如果查询到的结果包含一个空的BINVAL元素，那么客户端必须(MUST)停止广播旧的图像。

• 如果该更新的子元素包含非空的photo元素，那么客户端必须(MUST)比较该哈希。如果哈希值是相同的，那么客户端能忽略其他资源继续广播现存的图像的哈希值。如果哈希值不同，那么客户端不能(MUST NOT)企图通过再次上传图片来消除冲突，它必须(MUST)遵循最新收到的vCard内容并据此重置头像的哈希值，在以后的出席信息中使用该新的哈希值。

重置图片的哈希值

重置图像的哈希值包括以下几步：

1. 立即发送包含了空元素的出席信息(不包含photo元素)
2. 从服务器下载vCard
3. 如果BINVAL是空的，或者没有该元素，那么之后就发送photo为空的出席信息。
4. 如果BINVAL包含图像元素，那么就计算该图像的哈希值并且在以后广播的出席信息中包含该值。

XML语法

以下规则适用于XML语法：

1. <PHOTO/>元素应该(SHOULD)包含<BINVAL>子元素，该元素的值为图像的Base64编码的值。
2. <PHOTO/>元素不应该(SHOULD NOT)包含<EXTVAL/>元素，该元素指向了图像的URI
3. <PHOTO/>元素不能(MUST NOT)包含图像本身。
4. <PHOTO/>元素应该(SHOULD)包含<TYPE/>子元素，该子元素的XML字符制定了图像的类型。关于图像类型的XML字符应该(SHOULD)为"image/gif", "image/jpeg", 或者 "image/png"。
5. <PHOTO/>元素不能(MUST NOT)拥有'mime-type'属性。

图像限制

以下规则适用于图像：

1. 图像应该(SHOULD)小于8k；这个限制应该由发布信息的客户端限制。
2. 图像的高度和宽度应该(SHOULD)在32到96之间；推荐的大小是高度为64像素，宽度为64像素。
3. 图像应该是(SHOULD)正方形的。
4. 图像内容类型 6 应该(SHOULD)是image/gif, image/jpeg, 或者 image/png；对"image/png"的支持是要求的(REQUIRED)，对"image/gif" 和"image/jpeg"的支持是推荐的(RECOMMENDED)，对其他类型的支持是可选的。
5. 图像的数据必须遵循base64二进制数据类型 7 ，并根据RFC 2045 8 的6.8部分进行编码，该部分推荐base64数据每行最多76个字符。然而，任何空白的字符(比如'\r' 和'\n')必须(MUST)忽略。

实现注意

<TYPE/>元素的XML字符是一个提示。如果<TYPE/>指定了的类型与<BINVAL/>元素的数据不符，应用必须(MUST)遵循实际的图像类型，必须(MUST)忽略<TYPE/>。如果<TYPE/>不是image/gif, image/jpeg, or image/png，它就应该(SHOULD)忽略。

如果图像超过了8kb的限制，该应用应该(SHOULD)处理该数据。

安全事项

本文档建立在RFC 3920 9, RFC 3921 10, and vcard-temp 11 之上，不需要引入安全事项。

IANA事项

本文不需要和互联网编号分配机构 (IANA) 12 的交互.

XMPP注册事项

协议空间

XMPP Register在所注册的正式协议空间中包含了'vcard-temp:x:update' (参考<http://www.xmpp.org/registrar/namespaces.html>)。

XML Schema

<?xml version='1.0' encoding='UTF-8'?>
 
<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='vcard-temp:x:update'
    xmlns='vcard-temp:x:update'
    elementFormDefault='qualified'>
 
  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0153: http://www.xmpp.org/extensions/xep-0153.html
    </xs:documentation>
  </xs:annotation>
 
  <xs:element name='x'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='photo' minOccurs='0' type='xs:base64Binary'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
 
</xs:schema>

致谢

作者感谢那些提供了帮助的，实现了本协议并且提供关于本文当反馈的开发人员。

附录

附录A:文档信息

系列：XEP

序号：0153

发布者：XMPP标准基金会

状态：活跃

类型：历史

版本：1.0

最后更新：2006-8-16

批准机构：XMPP理事会

依赖标准：XMPP Core, XMPP IM, XEP-0054

取代: 无

被替代标准：无

缩略名：vcard-avatar

Schema: <http://www.xmpp.org/schemas/vcard-avatar.xsd>

原文控制： HTML RSS

本文的其它格式： XML PDF

附录B:作者信息

Peter Saint-Andre

Email: stpeter@jabber.org

JabberID: stpeter@jabber.org

URI: https://stpeter.im/

附录C:法律通告

版权

XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.

权限

特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。

免责声明'

## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##

责任限制

在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。

知识产权的一致性

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

附录D:和XMPP的关系

可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.

附录E:讨论地点

主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.

在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .

勘误表可以发送邮件到 <editor@xmpp.org>.

附录F:需求一致性

以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

附录G:备注

1. XEP-0008: 基于IQ的头像 <http://www.xmpp.org/extensions/xep-0008.html>.
2. XEP-0084: 用户头像 <http://www.xmpp.org/extensions/xep-0084.html>.
3. XEP-0054: 用户电子名片 <http://www.xmpp.org/extensions/xep-0054.html>.
4. RFC 3174: 美国安全哈希机制1 (SHA1) <http://tools.ietf.org/html/rfc3174>.
5. XEP-0045: 多用户聊天 <http://www.xmpp.org/extensions/xep-0045.html>.
6. 内容类型的IANA注册项位于 <http://www.iana.org/assignments/media-types/>.
7. 参见 <http://www.w3.org/TR/xmlschema-2/#base64Binary>.
8. RFC 2045: 多用途互联网邮件扩展 (MIME) 第一部分: 互联网消息正文格式 <http://tools.ietf.org/html/rfc2045>.
9. RFC 3920: 可扩展的消息和出席信息协议 (XMPP): 核心 <http://tools.ietf.org/html/rfc3920>.
10. RFC 3921: 可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息 <http://tools.ietf.org/html/rfc3921>.
11. XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.
12. 互联网编号分配机构(IANA)是用于互联网协议的唯一性参数值分配的核心协调者, 例如号码和URI计划. 更多信息, 见 <http://www.iana.org/>.
13. XMPP登记员XMPP Registrar 维护着一个保留的协议名字空间以及用于由XMPP标准基金会批准的XMPP扩展协议的上下文参数的注册项的列表. 更多信息, 见 <http://www.xmpp.org/registrar/>.

附录H:修订历史

注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用

Version 1.0 (2006-08-16)

Per a vote of the Jabber Council, advanced status to Active. (psa)

Version 0.3 (2006-01-12)

Collected all syntax rules into dedicated section; incorporated feedback from implementation experience; adjusted text regarding base64 encoding. (psa)

Version 0.2 (2005-10-18)

Changed 8k limit from MUST NOT to SHOULD NOT; specified that client should publish new presence stanza if it obtains an avatar image after sending an empty photo element; specified that the update child should be included in directed presence stanzas; more clearly specified Base64 rules. (psa)

Version 0.1 (2005-06-16)

Initial version. (psa)

Version 0.0.3 (2005-06-14)

Changed type from Informational to Historical, adjusted text accordingly. (psa)

Version 0.0.2 (2005-06-13)

Specified that the image data is actually Base64 encoded. (psa)

Version 0.0.1 (2005-06-09)

First draft. (psa)

结束