XEP--用户头像

1、XEP-0084来自Jabber/XMPP中文翻译计划跳转到： 导航, 搜索本文的英文原文来自XEP-0084 XEP-0084: 用户头像 摘要: 本文定义了一个XMPP协议扩展，用于交换用户头像,一个小的和自然人用户相关的图像或图标. 该协议定义了头像元数据和图像数据本身的承载格式. 承载格式典型地使用定义于XEP-0163的 XMPP发布-订阅个人事件脚本 协议来传输 作者: Peter Saint-Andre, Peter Millard, Thomas Muldowney, Julian Missig 版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参

2、见法律通告. 状态: 草案 类型: 标准跟踪 版本: 1.1 最后更新日期: 2008-11-05 注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动. 目录· 1 绪论· 2 需求· 3 基本处理流程 o 3.1 用户发布数据o 3.2 用户发布元数据通知o 3.3 订阅者接收元数据通知o 3.4 订阅者获取数据o 3.5 发布者禁止头像发布· 4 协议语法 o 4.1 Data元素o 4.2 Metadata元素 § 4.2.1 Info元素

3、§ 4.2.2 Pointer元素· 5 另外的例子 o 5.1 带多内容类型的Metadatao 5.2 带Pointer的Metadata· 6 服务查询 o 6.1 查询头像可用性· 7 实现备注 o 7.1 多资源o 7.2 头像同步o 7.3 图片处理· 8 安全事项· 9 IANA事项· 10 XMPP注册处事项 o 10.1 协议命名空间· 11 XML Schema o 11.1 Data命名空间o 11.2 Metadata命名空间· 12 作者备注· 13 附录 o 13.1

4、 附录A:文档信息o 13.2 附录B:作者信息o 13.3 附录C:法律通告o 13.4 附录D:和XMPP的关系o 13.5 附录E:讨论地点o 13.6 附录F:需求一致性o 13.7 附录G:备注o 13.8 附录H:修订历史绪论很多通讯应用允许那个应用的用户拥有一个相关的小图片或图标. 通常, 这样一个 "avatar" 不一定是一个用户的真正长相的图片, 而可能是一个用户期望的自己的图像 (经常很怪诞) 或该用户暂时的状态 (例如心情或活动). 本文定义一个方法来把头像合并到目前的 Jabber/XMPP 系统，即把该功能架在 XMPP发布-订阅 1 扩展 (&

5、quot;pubsub")之上, 特别是 个人事件协议 2 子集 ("PEP"), 它被定义用于符合 RFC 3921 3的 XMPP 即时消息和出席信息系统的场景. 本协议在这里定义使用两种 pubsub 节点(nodes): 一个 node 用于元数据 "metadata"，关于头像状态的 (称为 元数据节点 "metadata node") ；另一个是用于头像数据本身 (称为 数据节点 "data node"). 这个从数据中分离出来的元数据 metadata 节省了带宽，并且使发布者和订阅者能够缓

6、存头像数据. (例如, 一个用户可能在两个或三个头像之间切换, 这种情况下用户的联系人们可以显示这些图片的一个本地缓存版本而不用每次检索或接收完整的图片.) 这个协议也允许头像数据存储在一个可通过HTTP (见 RFC 2616 4) 访问的 URL 上. 5 如果一个 pubsub-aware 数据仓库不可用，作为一个回退机制这是有帮助的. 它也使头像图片能被托管在公共的网站上 (例如, 一个面向终端用户的社区网站) 并从那个网站检索到而不是直接由发布的客户端以任何方式来处理. 最后, 本协议也使 XMPP 应用能选择性地和托管了用户头像的第三方服务(例如, 在线游戏系统和虚拟世界)集成.

7、一旦 XMPP 发布-订阅 的 PEP子集被足够广泛地实现和布署，本协议准备将来取代 基于IQ的头像 6 和 基于vCard的头像 7. 需求本文涉及以下的头像发布的用例: 1. 发布头像数据 2. 更新当前头像的元数据 3. 禁止头像 本文涉及以下头像订阅的用例: 1. 发现头像可用性 2. 接收头像变更通知 3. 通过pubsub获取头像数据 4. 通过HTTP获取头像数据 基本处理流程发布和更新用户头像的流程如下: 1. 用户用 "image/png" content-type 格式发布头像数据到数据节点 data node，并可选的地发布其他格式 content-t

8、ypes 到 HTTP URLs. 2. 用户发布已更新头像通知到元数据节点 metadata node, 伴随 ItemID ，它是"image/png" content-type 的图像数据的 SHA-1 哈希值 (注意: 这是该图像数据本身的一个哈希, 而不是base64编码过的那个版本). 3. 订阅者接收通知. 4. 可选的 (且如果必要), 订阅者使用 pubsub retrieve-items 特性 (或通过 HTTP)从数据节点 data node 获取由 ItemID 标识的头像数据. 5. 可选的, 用户禁止头像显示. 这个处理流程在随后的章节描述得更加

9、完整. 注意: 在发布头像数据和元数据之前, 用户必须 MUST 根据定义于 XEP-0163 的流程确定是否他或她的服务器支持pubsub的PEP子集，因为这个支持简化了头像发布. 以下例子假定PEP服务可用. 用户发布数据在更新头像元数据节点之前, 发布者必须 MUST m确保头像数据在数据节点或URL是可用的. 当发布头像数据到数据节点时, 发布者必须 MUST 确保 pubsub ItemID 是该"image/png" 格式数据的 SHA-1 哈希值 (这被订阅者用于决定是否可以使用本地缓存副本来显示). 以下例子展示发布头像数据到数据节点时发送的 XML 结构.

10、 例子 1. 发布头像数据到数据节点 <iq type='set' from='julietcapulet.lit/chamber' id='publish1'> <pubsub xmlns='/protocol/pubsub'> <publish node='urn:xmpp:avatar:data'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <d

11、ata xmlns='urn:xmpp:avatar:data'> qANQR1DBwU4DX7jmYZnncm. </data> </item> </publish> </pubsub></iq>例子 2. Pubsub服务应答成功 <iq type='result' to='julietcapulet.lit/chamber' id='publish1'/>如果头像将通过 HTTP 而不是 pubsub 数据节点可用, 发布者必须 MUST 要么检查

12、这个 HTTP URL 是否存在头像数据，要么通过标准的 HTTP 方法发布它 (这些方法超出了本协议的范围; 反考 RFC 2616). 用户发布元数据通知任何时候发布者希望修改当前头像, 它必须 MUST 更新元数据节点. 以下例子显示的指定可用头像数据的元数据，仅针对一个格式 ("image/png") 并且只可在数据节点访问. 例子 3. 发布头像元数据 <iq type='set' from='julietcapulet.lit/chamber' id='publish2'> <pubsub xml

13、ns='/protocol/pubsub'> <publish node='urn:xmpp:avatar:metadata'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <metadata xmlns='urn:xmpp:avatar:metadata'> <info bytes='12345' id='111f4b3c50d7b0df729d299bc6f8e9

14、ef9066971f' height='64' type='image/png' width='64'/> </metadata> </item> </publish> </pubsub></iq>以下例子显示的指定可用头像数据的元数据，对一个 HTTP URL 可用. 例子 4. 发布头像元数据 <iq type='set' from='julietcapulet.lit/chamber' id='publish2'&

15、gt; <pubsub xmlns='/protocol/pubsub'> <publish node='urn:xmpp:avatar:metadata'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <metadata xmlns='urn:xmpp:avatar:metadata'> <info bytes='23456' height='64'

16、id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f' type='image/gif' url='/happy.gif' width='64'/> </metadata> </item> </publish> </pubsub></iq>订阅者接收元数据通知接着用户的虚拟 virtual pubsub 服务将发送元数据通知给那些订阅了该用户的元数据节点的实体或那些声明拥有接收头像

17、元数据能力的联系人(通过在 实体能力 8 中包含一个"urn:xmpp:avatar:metadata+notify"特性). 例子 5. 订阅者接收头像元数据通知 <message to='romeomontague.lit' from='julietcapulet.lit'> <event xmlns='/protocol/pubsub#event'> <items node='urn:xmpp:avatar:metadata'> <

18、item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <metadata xmlns='urn:xmpp:avatar:metadata'> <info bytes='12345' height='64' id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f' type='image/png' width='64'/> </metadata> </it

19、em> </items> </event> <addresses xmlns='/protocol/address'> <address type='replyto' jid='julietcapulet.lit/chamber'/> </addresses></message>如上所示, 取决于节点配置, 这个条目可以包含关于该发布资源的 扩展的节地址 9 信息(详见 XEP-0060 ). 订阅者获取数据在接收到该通知后, 每个订阅者

20、应该决定是否有一个该头像的本地缓存副本(它可以通过ItemID搜索一个图像标识符). 如果该订阅者已经有一个该头像的本地缓存副本, 它不能(MUST NOT)获取该图像数据. 如果该订阅者没有该头像图片的本地缓存副本, 它应该获取该数据. 它可以发送一个pubsub的 获取条目 请求给该数据节点, 指定适当的ItemID. 例子 6. 订阅者通过ItemID请求最后的条目 <iq type='get' from='romeomontague.lit/home' to='julietcapulet.lit' id='retrieve1

21、'> <pubsub xmlns='/protocol/pubsub'> <items node='urn:xmpp:avatar:data'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'/> </items> </pubsub></iq>运行在该用户的服务器上的PEP服务接着应该返回头像数据. 例子 7. PEP服务返回头像数据 <iq type='res

22、ult' from='julietcapulet.lit' to='romeomontague.lit/home' id='retrieve1'> <pubsub xmlns='/protocol/pubsub'> <items node='urn:xmpp:avatar:data'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <data xmlns

23、='urn:xmpp:avatar:data'> qANQR1DBwU4DX7jmYZnncm. </data> </item> </items> </pubsub></iq>如果被发送给元数据节点的<info/>元素拥有一个'url'属性, 该头像数据位于一个URL. 所以, 为了获取那一内容类型的头像图片数据, 该请求实体必须发送一个HTTP请求给指定的URL. 干这事的方法超出了本协议的范围(见 RFC 2616 ). 发布者禁止头像发布为了临时禁止头像发布, 该用户发布一个空的

24、<metadata/>元素给该元数据节点. 例子 8. 临时禁止头像发布 <iq type='set' from='julietcapulet.lit/chamber' id='publish3'> <pubsub xmlns='/protocol/pubsub'> <publish node='urn:xmpp:avatar:data'> <item> <metadata xmlns='urn:xmpp:av

25、atar:metadata'/> </item> </publish> </pubsub></iq>照旧, 该元数据的订阅者将接着收到该通知. 例子 9. 订阅者获取头像元数据通知 <message to='romeomontague.lit/home' from='julietcapulet.lit'> <event xmlns='/protocol/pubsub#event'> <items node='urn:

26、xmpp:avatar:metadata'> <item> <metadata xmlns='urn:xmpp:avatar:metadata'/> </item> </items> </event></message>注意: 在本协议的一个早期版本中, 用户通过发送包含一个<stop/>子元素的<metadata/>元素来表明它想禁止发布. 为了保持和其他PEP载荷格式的一致性, 对<stop/>元素的支持被废弃了. 协议语法pubsub的PEP子集要求在

27、命名空间和节点之间将存在一对一的关系. 因为在这里定义的协议规定了两种节点的使用(一个用于头像数据一个用于头像元数据), 我们定义了两个命名空间, 每个都有一个相应的根元素: · <data xmlns='urn:xmpp:avatar:data'/> · <metadata xmlns='urn:xmpp:avatar:metadata'/> 更多定义如下. Data元素<data/>元素被用于通讯头像数据本身, 并只用于"image/png"内容类型(支持这个是必需的). <d

28、ata xmlns='urn:xmpp:avatar:data'> IMAGE DATA</data>XML字符数据必须展示内容类型为"image/png"的头像的图片, 遵循RFC 464810的第4章做Base64编码. (注意: Line feeds不应该(SHOULD NOT)被添加但是应该被接受.) <data/>元素不能(MUST NOT)拥有任何属性. 对<data/>元素的支持是必需的. Metadata元素<metadata/>元素被用于通讯关于该头像的信息. <metadata/

29、>元素有两个允许的子元素: · <info/> · <pointer/> 更多定义如下. 另外, <metadata/>元素可以是空的(即, 不包含子元素); 这个格式被用于禁止头像发布. Info元素<info/>子元素被用于通讯头像元数据. 对<info/>元素的支持是必需的. <metadata xmlns='urn:xmpp:avatar:metadata'> <info bytes='size-of-image-data-in-bytes' heig

30、ht='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'/></metadata><info/>子元素必须是空的. <info/>元素的已定义属性见下表. 表1: Info Attributes 名称 定义 包含 bytes 图片数

31、据的大小(以字节数计). 必需 height 图片的高度(以像素计). 推荐 id 对于指定的内容类型的图片数据的哈希值, 这里的哈希值的生成遵循RFC 3174 11定义的SHA-1机制(以二进制输出). 必需 type 该图片数据的在IANA注册了的内容类型. 必需 url 图片数据文件所在的 http: 或 https: URL  除非该图片数据文件能从HTTP获取，不能(MUST NOT)包含该属性. 可选 width 该图片的宽度(以像素计) 推荐 <metadata/>根元素可以包含多个<info/>元素. 每个<info/>元素必须为

32、相同的头像图片指定元数据但是要以替代的内容类型(例如, "image/png", "image/gif", 和 "image/jpeg"), 并且格式之一必须是"image/png"以确保互操作性. 'type'属性的值必须是一个在IANA注册了的内容类型"image"或"video". 12 对"image/png"内容类型的支持是必需的. 对"image/gif"和"image/jpeg"内容类型

33、的支持是推荐的. 岁任何其他内容类型的支持是可选的. Pointer元素<pointer/>子元素被用于指向一个未通过pubsub或HTTP发布的头像, 但是相反由类似在线游戏系统或虚拟世界的第三方服务提供. <metadata xmlns='urn:xmpp:avatar:metadata'> <pointer> . APPLICATION-SPECIFIC DATA . </pointer></metadata>如果发布的应用有相关的信息,<pointer/>元素可以拥有以下属性: · byt

34、es - 该图片数据的大小(以字节计). · height - 该图片的高度(以像素计). · id - 该图片数据用于指定内容类型的SHA-1哈希. · type - 该图片数据的在IANA注册了的内容类型. · width - 该图片的宽度(以像素计). <pointer/>元素的内容必须是一个正确使用命名空间的子元素以指定如何从第三方服务获取该头像的信息. 任何子元素的结构超出了本文的范围. 即使包含了<pointer>元素, 至少必须有一个<info/>元素的实例发生在它之前，这样不支持<pointer/

35、>元素的实现能显示该头像的"后备"格式(最低限度, "image/png"). 对<pointer/>元素的支持是可选的. 另外的例子带多内容类型的Metadata以下例子展示指定头像数据的元数据可用的多种格式("image/png", "image/gif", 和 "image/mng"), 这里"image/png"内容类型只可用在数据节点而其他内容类型可用于 HTTP URLs. 例子 10. 发布头像元数据(多格式) <iq type='

36、;set' from='julietcapulet.lit/chamber' id='publish3'> <pubsub xmlns='/protocol/pubsub'> <publish node='urn:xmpp:avatar:metadata'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <metadata xmlns='urn:xmpp:ava

37、tar:metadata'> <info bytes='12345' height='64' id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f' type='image/png' width='64'/> <info bytes='12345' height='64' id='e279f80c38f99c1e7e53e262b440993b2f7eea57' type='image/png

38、' url='/happy.png' width='64'/> <info bytes='23456' height='64' id='357a8123a30844a3aa99861b6349264ba67a5694' type='image/gif' url='/happy.gif' width='64'/> <info bytes=&

39、#39;78912' height='64' id='03a179fe37bd5d6bf9c2e1e592a14ae7814e31da' type='image/mng' url='/happy.mng' width='64'/> </metadata> </item> </publish> </pubsub></iq>在前述的例子中, 以"image/png"内容类型封装

40、的图片同时可用于一个pubsub数据节点和一个HTTP URL; 所以它被包含了两次(第二次带了一个'url'属性). 带Pointer的Metadata以下例子展示元数据指定在数据节点可用的"image/png"头像数据，同时也带有一个指针指向外部服务. 例子 11. 发布头像元数据(带指针) <iq type='set' from='julietcapulet.lit/chamber' id='publish4'> <pubsub xmlns='/p

41、rotocol/pubsub'> <publish node='urn:xmpp:avatar:metadata'> <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'> <metadata xmlns='urn:xmpp:avatar:metadata'> <info bytes='12345' height='64' id='111f4b3c50d7b0df729d299bc6f8e9ef9066

42、971f' type='image/png' width='64'/> <pointer> <x xmlns=' <game>Ancapistan</game> <character>Kropotkin</character> </x> </pointer> </metadata> </item> </publish> </pubsub></iq>服务查询查询头像可用性pubsub "

43、;auto-subscribe" 和 "filtered-notifications" 特性允许一个联系人自动订阅一个用户的头像. 无论如何, 一个联系人也能显式地决定是否另一个用户使用本协议发布头像，通过发送一个服务查询 13 条目 ("disco#items") 请求给该用户的春JID <localpartdomain.tld>. 例子 12. 查询条目请求 <iq type='get' from='romeomontague.lit/orchard' to='julietcapul

44、et.lit' id='items1'> <query xmlns='/protocol/disco#items'/></iq>如果该用户发布头像数据到一个PEP节点, 结果必须包含适当的条目. 例子 13. 查询条目结果 <iq type='result' from='julietcapulet.lit' to='romeomontague.lit/orchard' id='items1'> <query xm

45、lns='/protocol/disco#items'> <item jid='julietcapulet.lit' node='urn:xmpp:avatar:data'/> <item jid='julietcapulet.lit' node='urn:xmpp:avatar:metadata'/> </query></iq>该联系人接着可以根据XEP-0060中定义的协议订阅该元数据节点. 无论如何, 该联系人不应该(SHO

46、ULD NOT)订阅该数据节点(反之, 它应该简单地在需要的时候从那个节点获取条目, 如上所述). 实现备注多资源如果一个用户同一时间有多个资源, 每个资源可以发布一个不同的头像. PEP服务应该包含上述的正在发布的资源的"replyto"地址，这样易于区分这个头像和前一个资源的头像. 头像同步当一个用户以一个新的资源登陆并且之前发布了一个头像, 它的客户端应该获取它最近发布的头像, 要么通过自动发送带有合适的实体可用性信息的出席信息(见 XEP-0115)要么使用XEP-0060所述的"retrieve-items"方法. 图片处理决定获取哪个头像格式

47、(例如, "image/gif"而不是"image/png")和决定获取的适当方法(例如, HTTP而不是pubsub)是接收的应用的责任. 接收的应用显示一个图片的时候不应该(SHOULD NOT)拉伸它. 如果一个头像对一个联系人不可用, 接收应用可以显示该联系人的相片, 例如, 在联系人的vCard中提供的(见vcard-temp 14) 或其他个人信息. 安全事项关于和基础的传输协议相关的安全事项见XEP-0060和XEP-0163. 有可能SHA-1哈希机制的输出会导致冲突; 无论如何, 使用SHA-1生成头像数据的哈希不是安全的关键. IAN

48、A事项本文使用了IANA注册的内容类型, 但是不要求和互联网编号分配授权机构(IANA) 15交互. XMPP注册处事项协议命名空间XMPP注册处 16 已经把"urn:xmpp:avatar:data"和"urn:xmpp:avatar:metadata"包含在它的协议命名空间的注册项中(见 </registrar/namespaces.html>). XML SchemaData命名空间<?xml version='1.0' encoding='UTF-8'?>

49、60;<xs:schema xmlns:xs='/2001/XMLSchema' targetNamespace='urn:xmpp:avatar:data' xmlns='urn:xmpp:avatar:data' elementFormDefault='qualified'>  <xs:annotation> <xs:documentation> The protocol documented by this schema is defined in

50、 XEP-0084: /extensions/xep-0084.html </xs:documentation> </xs:annotation>  <xs:element name='data' type='xs:base64Binary'/> </xs:schema>Metadata命名空间<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmln

51、s:xs='/2001/XMLSchema' targetNamespace='urn:xmpp:avatar:metadata' xmlns='urn:xmpp:avatar:metadata' elementFormDefault='qualified'>  <xs:annotation> <xs:documentation> The protocol documented by this schema is defined in XEP-0084: ht

52、tp://extensions/xep-0084.html </xs:documentation> </xs:annotation>  <xs:element name='metadata'> <xs:complexType> <xs:choice> <xs:sequence minOccurs='0' maxOccurs='1'> <xs:element ref='info' minOccurs='1'

53、 maxOccurs='unbounded'/> <xs:element ref='pointer' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> </xs:choice> </xs:complexType> </xs:element>  <xs:element name='info'> <xs:complexType> <xs:simpleConte

54、nt> <xs:extension base='empty'> <xs:attribute name='bytes' type='xs:unsignedShort' use='required'/> <xs:attribute name='height' type='xs:unsignedByte' use='optional'/> <xs:attribute name='id' type='xs:string&

55、#39; use='required'/> <xs:attribute name='type' type='xs:string' use='required'/> <xs:attribute name='url' type='xs:anyURI' use='optional'/> <xs:attribute name='width' type='xs:unsignedByte' use='optional&#

56、39;/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>  <xs:element name='pointer'> <xs:complexType> <xs:sequence> <xs:any namespace='#other'/> </xs:sequence> </xs:complexType> </xs:element>&

57、#160; <xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType> </xs:schema>作者备注Peter Millard, 本协议从版本0.1到版本0.7的作者, 去世于 April 26, 2006. 剩下的作者们感谢他在用户头像方面的工作. 附录附录A:文档信息系列

58、：XEP 序号：0084 发布者：XMPP标准基金会 状态：草案 类型：标准跟踪 版本：1.1 最后更新：2008-11-05 批准机构：XMPP理事会 依赖标准：XMPP Core, XEP-0030, XEP-0060, XEP-0163 替代标准：XEP-0008, XEP-0153 被替代标准：无 缩略名：avatar data命名空间的XML Schema: </schemas/avatar-data.xsd>metadata命名空间的XML Schema: </schemas/avatar-m

59、etadata.xsd>原文控制： HTML 本文的其它格式： XML PDF 附录B:作者信息Peter Saint-Andre Email: JabberID: URI: https:/stpeter.im/ Peter Millard 见 作者备注 Thomas Muldowney Email: JabberID: Julian Missig Email: JabberID: 附录

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

61、注。 免责声明' # 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. # 责任限制 在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商

62、业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。 知识产权的一致性 XMPP扩展协议完全遵守XSF的知识产权策略(可在</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标准基金会贡献到由依据R

63、FC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改. 附录E:讨论地点主要的XMPP扩展协议讨论地点是 <> 讨论列表. 在 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 </about/discuss.shtml> . 勘误表可以发送邮件到 <>. 附录F:需求一致性以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED" "MUST NOT", "SHALL