XEP0084 用户头像.docx

资源描述

XEP0084 用户头像.docx

《XEP0084 用户头像.docx》由会员分享，可在线阅读，更多相关《XEP0084 用户头像.docx（30页珍藏版）》请在冰豆网上搜索。

XEP0084 用户头像.docx

XEP0084用户头像

XEP-0084

来自Jabber/XMPP中文翻译计划

跳转到：

导航,搜索

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

XEP-0084:

用户头像

摘要:

本文定义了一个XMPP协议扩展，用于交换用户头像,一个小的和自然人用户相关的图像或图标.该协议定义了头像元数据和图像数据本身的承载格式.承载格式典型地使用定义于XEP-0163的XMPP发布-订阅个人事件脚本协议来传输

作者:

PeterSaint-Andre,PeterMillard,ThomasMuldowney,JulianMissig

版权:

状态:

草案

类型:

标准跟踪

版本:

1.1

最后更新日期:

2008-11-05

注意:

这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.

∙1绪论

∙2需求

∙3基本处理流程

3.1用户发布数据

3.2用户发布元数据通知

3.3订阅者接收元数据通知

3.4订阅者获取数据

3.5发布者禁止头像发布

∙4协议语法

4.1Data元素

4.2Metadata元素

▪4.2.1Info元素

▪4.2.2Pointer元素

∙5另外的例子

5.1带多内容类型的Metadata

5.2带Pointer的Metadata

∙6服务查询

6.1查询头像可用性

∙7实现备注

7.1多资源

7.2头像同步

7.3图片处理

∙8安全事项

∙9IANA事项

∙10XMPP注册处事项

10.1协议命名空间

∙11XMLSchema

11.1Data命名空间

11.2Metadata命名空间

∙12作者备注

∙13附录

13.1附录A:

文档信息

13.2附录B:

作者信息

13.3附录C:

法律通告

13.4附录D:

和XMPP的关系

13.5附录E:

讨论地点

13.6附录F:

需求一致性

13.7附录G:

备注

13.8附录H:

修订历史

绪论

很多通讯应用允许那个应用的用户拥有一个相关的小图片或图标.通常,这样一个"avatar"不一定是一个用户的真正长相的图片,而可能是一个用户期望的自己的图像（经常很怪诞）或该用户暂时的状态（例如心情或活动）.本文定义一个方法来把头像合并到目前的Jabber/XMPP系统，即把该功能架在XMPP发布-订阅1扩展（"pubsub"）之上,特别是个人事件协议2子集（"PEP"）,它被定义用于符合RFC39213的XMPP即时消息和出席信息系统的场景.

本协议在这里定义使用两种pubsub节点（nodes）:

一个node用于元数据"metadata"，关于头像状态的（称为元数据节点"metadatanode"）；另一个是用于头像数据本身（称为数据节点"datanode"）.这个从数据中分离出来的元数据metadata节省了带宽，并且使发布者和订阅者能够缓存头像数据.（例如,一个用户可能在两个或三个头像之间切换,这种情况下用户的联系人们可以显示这些图片的一个本地缓存版本而不用每次检索或接收完整的图片.）

这个协议也允许头像数据存储在一个可通过HTTP（见RFC26164）访问的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格式发布头像数据到数据节点datanode，并可选的地发布其他格式content-types到HTTPURLs.

2.用户发布已更新头像通知到元数据节点metadatanode,伴随ItemID，它是"image/png"content-type的图像数据的SHA-1哈希值（注意:

这是该图像数据本身的一个哈希,而不是base64编码过的那个版本）.

3.订阅者接收通知.

4.可选的（且如果必要）,订阅者使用pubsubretrieve-items特性（或通过HTTP）从数据节点datanode获取由ItemID标识的头像数据.

5.可选的,用户禁止头像显示.

这个处理流程在随后的章节描述得更加完整.

注意:

在发布头像数据和元数据之前,用户必须MUST根据定义于XEP-0163的流程确定是否他或她的服务器支持pubsub的PEP子集，因为这个支持简化了头像发布.以下例子假定PEP服务可用.

用户发布数据

在更新头像元数据节点之前,发布者必须MUSTm确保头像数据在数据节点或URL是可用的.当发布头像数据到数据节点时,发布者必须MUST确保pubsubItemID是该"image/png"格式数据的SHA-1哈希值（这被订阅者用于决定是否可以使用本地缓存副本来显示）.

以下例子展示发布头像数据到数据节点时发送的XML结构.

例子1.发布头像数据到数据节点

//jabber.org/protocol/pubsub'>

xmpp:

avatar:

data'>

xmpp:

avatar:

data'>

qANQR1DBwU4DX7jmYZnncm...

例子2.Pubsub服务应答成功

如果头像将通过HTTP而不是pubsub数据节点可用,发布者必须MUST要么检查这个HTTPURL是否存在头像数据，要么通过标准的HTTP方法发布它（这些方法超出了本协议的范围;反考RFC2616）.

用户发布元数据通知

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

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

例子3.发布头像元数据

//jabber.org/protocol/pubsub'>

xmpp:

avatar:

metadata'>

xmpp:

avatar:

metadata'>

id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'

height='64'

type='image/png'

width='64'/>

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

例子4.发布头像元数据

//jabber.org/protocol/pubsub'>

xmpp:

avatar:

metadata'>

xmpp:

avatar:

metadata'>

height='64'

id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'

type='image/gif'

url='http:

//avatars.example.org/happy.gif'

width='64'/>

订阅者接收元数据通知

接着用户的虚拟virtualpubsub服务将发送元数据通知给那些订阅了该用户的元数据节点的实体或那些声明拥有接收头像元数据能力的联系人（通过在实体能力8中包含一个"urn:

xmpp:

avatar:

metadata+notify"特性）.

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

//jabber.org/protocol/pubsub#event'>

xmpp:

avatar:

metadata'>

xmpp:

avatar:

metadata'>

height='64'

id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'

type='image/png'

width='64'/>

//jabber.org/protocol/address'>

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

订阅者获取数据

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

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

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

from='romeo@montague.lit/home'

to='juliet@capulet.lit'

id='retrieve1'>

//jabber.org/protocol/pubsub'>

xmpp:

avatar:

data'>

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

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

from='juliet@capulet.lit'

to='romeo@montague.lit/home'

id='retrieve1'>

//jabber.org/protocol/pubsub'>

xmpp:

avatar:

data'>

xmpp:

avatar:

data'>

qANQR1DBwU4DX7jmYZnncm...

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

发布者禁止头像发布

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

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

//jabber.org/protocol/pubsub'>

xmpp:

avatar:

data'>

xmpp:

avatar:

metadata'/>

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

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

//jabber.org/protocol/pubsub#event'>

xmpp:

avatar:

metadata'>

xmpp:

avatar:

metadata'/>

注意:

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

协议语法

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

∙

xmpp:

avatar:

data'/>

∙

xmpp:

avatar:

metadata'/>

更多定义如下.

Data元素

元素被用于通讯头像数据本身,并只用于"image/png"内容类型（支持这个是必需的）.

xmpp:

avatar:

data'>

IMAGEDATA

XML字符数据必须展示内容类型为"image/png"的头像的图片,遵循RFC464810的第4章做Base64编码.（注意:

Linefeeds不应该（SHOULDNOT）被添加但是应该被接受.）

元素不能（MUSTNOT）拥有任何属性.

对元素的支持是必需的.

Metadata元素

元素被用于通讯关于该头像的信息.元素有两个允许的子元素:

∙

更多定义如下.

另外,元素可以是空的（即,不包含子元素）;这个格式被用于禁止头像发布.

Info元素

子元素被用于通讯头像元数据.对元素的支持是必需的.

xmpp:

avatar:

metadata'>

height='image-height-in-pixels'

id='SHA-1-hash-of-image-data'

type='content-type-of-image-data'

url='HTTP-URL-for-image-data'

width='image-width-in-pixels'/>

子元素必须是空的.

元素的已定义属性见下表.

表1:

InfoAttributes

名称

定义

包含

bytes

图片数据的大小（以字节数计）.

必需

height

图片的高度（以像素计）.