XEP-0153

来自Jabber/XMPP中文翻译计划
2011年3月4日 (五) 05:45How (讨论 | 贡献)的版本
跳转到： 导航, 搜索


本文的英文原文来自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定义的协议发布用户公开的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计算用户图像的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子元素(比如，在加入多用户聊天室时直接发送的出席信息)

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. 图像的类型应该(SHOULD)是image/gif, image/jpeg, 或者 image/png；对"image/png"的支持是要求的(REQUIRED)，对"image/gif" 和"image/jpeg"的支持是推荐的(RECOMMENDED)，对其他类型的支持是可选的。
  5. 图像的数据必须遵循base64编码，并根据RFC 2045的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事项

本文不需要和Internet Assigned Numbers Authority (IANA)的交互.

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>

致谢

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

备注

  1. XEP-0008: IQ-Based Avatars <http://www.xmpp.org/extensions/xep-0008.html>.
  2. XEP-0084: User Avatar <http://www.xmpp.org/extensions/xep-0084.html>.
  3. XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.
  4. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.
  5. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.
  6. The IANA registry of content types is located at <http://www.iana.org/assignments/media-types/>.
  7. See <http://www.w3.org/TR/xmlschema-2/#base64Binary>.
  8. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://tools.ietf.org/html/rfc2045>.
  9. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.
  10. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.
  11. XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.
  12. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
  13. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

修订历史

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)

结束

文档信息

系列: XEP

编号:0153

发布者:XMPP标准基金会

状态:激活

类型: 历史性的

版本:1.0

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

批准机构:XMPP理事会

依赖于:XMPP Core, XMPP IM, XEP-0054

上文:无

下文:无

简称:vcard-avatar

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

Wiki页: <http://wiki.jabber.org/index.php/vcard-avatar (XEP-0153)>

作者信息

Peter Saint-Andre

JID: [xmpp:stpeter@jabber.org stpeter@jabber.org]
URI: <https://stpeter.im/>
来自“http://wiki.jabbercn.org/index.php?title=XEP-0153&oldid=1194”
个人工具