查看源代码

[[Category:XMPP扩展]]
[[Category:已翻译]]

'''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0153.html XEP-0153]'''

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

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

作者: Peter Saint-Andre

版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见[[XEP-0153#附录C:法律通告|法律通告]].

状态: 活跃的

类型: 历史的

版本: 1.0

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

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

==绪论==

有好几种中建议的协议可以通过Jabber/XMPP交流用户的头像信息(参考 [http://xmpp.org/extensions/xep-0008.html 基于IQ的头像] [[XEP-0138#附录G:备注|1]] 和 [http://xmpp.org/extensions/xep-0084.html 用户头像] [[XEP-0138#附录G:备注|2]])。本文档描述了另一个目前在Jabber/XMPP网络中使用的协议。本文是历史的并且没有意图建议一个标准跟踪协议。然而，未来的协议可能会改进本文档。

==需求==

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

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

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

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

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

==用例==

===用户发布个人头像===

在通知联系人有关用户的图像信息前，用户的客户端首先根据在[[XEP-0054|vcard-temp]] [[XEP-0153#附录G:备注|3]] 定义的协议发布用户公开的vCard信息。

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

<source lang="xml">
<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>
</source>

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

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

接下来，用户客户端根据[http://tools.ietf.org/html/rfc3174 RFC 3174] [[XEP-0153#附录G:备注|4]] 计算用户图像的SHA1哈希值(不是base64编码)。此哈希值包含在用户的出席信息中，该出席信息包含了'vcard-temp:x:update'命名空间限定的<x/>元素及其<photo/>子元素，就如下例子显示：

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

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

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

===联系人获取头像===

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

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

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

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

<source lang="xml">
<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>
</source>

==业务规则==

===在出席信息中包含更新===

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

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

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

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

<source lang="xml">
<presence>
  <x xmlns='vcard-temp:x:update'/>
</presence>
</source>

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

'''例子7. 没有图像被发送'''

<source lang="xml">
<presence>
  <x xmlns='vcard-temp:x:update'>
    <photo/>
  </x>
</presence>
</source>

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

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

===下载和更新vCard===

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

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

===多资源===

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

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

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

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

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

===重置图片的哈希值===

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

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

===XML语法===

以下规则适用于XML语法：

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

===图像限制===

以下规则适用于图像：

# 图像应该(SHOULD)小于8k；这个限制应该由发布信息的客户端限制。
# 图像的高度和宽度应该(SHOULD)在32到96之间；推荐的大小是高度为64像素，宽度为64像素。
# 图像应该是(SHOULD)正方形的。
# 图像内容类型 [[XEP-0153#附录G:备注|6]] 应该(SHOULD)是image/gif, image/jpeg, 或者 image/png；对"image/png"的支持是要求的(REQUIRED)，对"image/gif" 和"image/jpeg"的支持是推荐的(RECOMMENDED)，对其他类型的支持是可选的。
# 图像的数据必须遵循base64二进制数据类型 [[XEP-0153#附录G:备注|7]] ，并根据RFC 2045 [[XEP-0153#附录G:备注|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 [[XEP-0153#附录G:备注|9]], RFC 3921 [[XEP-0153#附录G:备注|10]], and vcard-temp [[XEP-0153#附录G:备注|11]] 之上，不需要引入安全事项。

==IANA事项==

本文不需要和互联网编号分配机构 (IANA) [[XEP-0153#附录G:备注|12]] 的交互.

==XMPP注册事项==

===协议空间===

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

==XML Schema==

<source lang="xml">
<?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>
</source>

==致谢==

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

==附录==

===附录A:文档信息===

系列：[http://xmpp.org/extensions/ XEP]

序号：0153

发布者：[http://xmpp.org/xsf/ XMPP标准基金会]

状态：[http://xmpp.org/extensions/xep-0001.html#states-Active 活跃]

类型：[http://xmpp.org/extensions/xep-0001.html#types-Historical 历史]

版本：1.0

最后更新：2006-8-16

批准机构：[http://xmpp.org/council/ XMPP理事会]

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

取代: 无

被替代标准：无

缩略名：vcard-avatar

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

原文控制： [http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0153.xml HTML] [http://svn.xmpp.org:18080//changelog/~rss/XMPP/trunk/extensions/xep-0153.xml/rss.xml RSS]

本文的其它格式： [http://xmpp.org/extensions/xep-0153.xml XML] [http://xmpp.org/extensions/xep-0153.pdf PDF]

--------------------------------------------------------------------------------
===附录B:作者信息===
:'''Peter Saint-Andre'''

::Email: stpeter@jabber.org

::JabberID: stpeter@jabber.org

::URI: https://stpeter.im/

--------------------------------------------------------------------------------
{{Template:XEP附录CDEF}}

--------------------------------------------------------------------------------
===附录G:备注===

# XEP-0008: 基于IQ的头像 <http://www.xmpp.org/extensions/xep-0008.html>.
# XEP-0084: 用户头像 <http://www.xmpp.org/extensions/xep-0084.html>.
# XEP-0054: 用户电子名片 <http://www.xmpp.org/extensions/xep-0054.html>.
# RFC 3174: 美国安全哈希机制1 (SHA1) <http://tools.ietf.org/html/rfc3174>.
# XEP-0045: 多用户聊天 <http://www.xmpp.org/extensions/xep-0045.html>.
# 内容类型的IANA注册项位于 <http://www.iana.org/assignments/media-types/>.
# 参见 <http://www.w3.org/TR/xmlschema-2/#base64Binary>.
# RFC 2045: 多用途互联网邮件扩展 (MIME) 第一部分: 互联网消息正文格式 <http://tools.ietf.org/html/rfc2045>.
# RFC 3920: 可扩展的消息和出席信息协议 (XMPP): 核心 <http://tools.ietf.org/html/rfc3920>.
# RFC 3921: 可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息 <http://tools.ietf.org/html/rfc3921>.
# XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.
# 互联网编号分配机构(IANA)是用于互联网协议的唯一性参数值分配的核心协调者, 例如号码和URI计划. 更多信息, 见 <http://www.iana.org/>.
# 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)

==修订历史==

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) 

--------------------------------------------
结束