XEP-0153

来自Jabber/XMPP中文翻译计划

2009年3月30日 (一) 09:08Admin (讨论 | 贡献)的版本

(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)

跳转到：导航, 搜索

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

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

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

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

文档信息

系列: 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/>

法律通告

版权

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

权限

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

免责声明

注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件.在任何情况XMPP标准基金会或作者不对此协议承担任何责任索赔，损害赔偿，或其他责任，无论是在一项行动的合同，侵权，或否则，所产生的，运出，或在他涉嫌与规格或执行，部署或以其它方式使用本协议. ##

责任限制

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

知识产权的一致性

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XSF, P.O. Box 1641, Denver, CO 80201 USA).

讨论地点

首选的讨论的地方是标准讨论邮件列表: <http://mail.jabber.org/mailman/listinfo/standards>.

勘误表发送到editor@xmpp.org

XMPP 相关信息

XMPP 是由XSF(XMPP标准化基金会)按互联网标准程序贡献的,和 IETF的RFC 2026兼容的规范,包括 XMPP核心(RFC 3920)和 XMPP IM(RFC 3921).在本文中定义的任何协议,都是在互联网标准程序之外开发的,是扩展XMPP，而不是改变、发展和修改 XMPP本身。

一致性术语

本文中以下关键词的含义如 RFC 2119 所述: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

绪论

通过Jabber/XMPP有好几种中推荐的协议可以查看用户的图像信息(参考IQ-Based Avatars和User Avatar)。本文档描述了另一个目前在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中的协议就查询发送者的全JID的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)在每个广播信息中包含每个子元素而且应该(SHOULD)在包含有关应用的出席信息中包含该子元素(比如，在加入多用户聊天室中应用的出席信息)

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

例子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：

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

多资源

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

如果从另一个资源收到的出席信息节点没有包含更新子元素，那表示另一个资源不支持vCard-base avatars。那个资源可以修改vCard文本的信息(包括photo元素)；因为调查vCard是不允许的，客户端必须(MUST)停止发布图像哈希值。然而，客户端可以(MAY)在所有不符合的资源下线之后重置图片的hash。
如果从其他资源受到的出席信息中包含更新子节点，那么其他是遵循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)正方形的。
图像的类型应该(SHOULD)是image/gif, image/jpeg, 或者 image/png；对"image/png"的支持是要求的(REQUIRED)，对"image/gif" 和"image/jpeg"的支持是推荐的(RECOMMENDED)，对其他类型的支持是可选的。
图像的数据必须遵循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>

致谢

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

备注

XEP-0008: IQ-Based Avatars <http://www.xmpp.org/extensions/xep-0008.html>.
XEP-0084: User Avatar <http://www.xmpp.org/extensions/xep-0084.html>.
XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.
RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.
XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.
The IANA registry of content types is located at <http://www.iana.org/assignments/media-types/>.
See <http://www.w3.org/TR/xmlschema-2/#base64Binary>.
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://tools.ietf.org/html/rfc2045>.
RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.
XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.
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/>.
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)

结束

来自“http://wiki.jabbercn.org/index.php?title=XEP-0153&oldid=20”

2个分类: