XEP-0128

来自Jabber/XMPP中文翻译计划
（版本间的差异）
跳转到： 导航, 搜索
 
（未显示3个用户的49个中间版本）
第4行： 第4行：
 
'''本文的英文原文来自[http://xmpp.org/extensions/xep-0128.html XEP-0128]'''
 
'''本文的英文原文来自[http://xmpp.org/extensions/xep-0128.html XEP-0128]'''
  
−
'''XEP-0128: 发现服务'''
+
'''XEP-0128: 发现服务扩展'''
  
−
XEP-0128: Service Discovery Extensions
+
摘要: 这个文件规定了发现服务的扩展信息的最佳做法。
−
Abstract: This document specifies best practices for including extended information in Service Discovery results.
+
−
Author: Peter Saint-Andre
+
−
Copyright: © 1999 - 2010 XMPP Standards Foundation. SEE LEGAL NOTICES.
+
−
Status: Active
+
−
Type: Informational
+
−
Version: 1.0
+
−
Last Updated: 2004-10-20
+
  
−
--------------------------------------------------------------------------------
+
作者: Peter Saint-Andre
  
−
NOTICE: This Informational specification defines a best practice or protocol profile that has been approved by the XMPP Council and/or the XSF Board of Directors. Implementations are encouraged and the best practice or protocol profile is appropriate for deployment in production systems.
+
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见[[XEP-0030#附录C:法律通告|法律通告]].
  
 +
现状: 活跃
  
−
--------------------------------------------------------------------------------
+
类型: 信息
  
−
Table of Contents
+
版本: 1.0
  
−
1. Introduction
+
最后更新: 2004-10-20
−
2. Recommendations
+
−
3. Examples
+
−
    3.1. IM Server
+
−
    3.2. Multi-User Chat Room
+
−
4. Implementation Notes
+
−
5. Security Considerations
+
−
6. IANA Considerations
+
−
7. XMPP Registrar Considerations
+
  
−
Appendices
 
−
    A: Document Information
 
−
    B: Author Information
 
−
    C: Legal Notices
 
−
    D: Relation to XMPP
 
−
    E: Discussion Venue
 
−
    F: Requirements Conformance
 
−
    G: Notes
 
−
    H: Revision History
 
  
 +
注意：注意：此信息规范定义了一个最佳实践或协议配置文件已被批准的XMPP理事会和/或董事XSF局。实现是鼓励和最佳做法或协议配置文件是在生产系统中部署适当的。
  
−
--------------------------------------------------------------------------------
 
  
−
1. Introduction
+
==简介==
−
Developers periodically wonder why Service Discovery [1] does not include more bits of information. For example, why does the <identity/> element not include a 'description' attribute, and can we add one now? The answer is: well, it just doesn't, and at this point it's too late to make further changes (since XEP-0030 is Final). So the best approach is to specify a well-defined extension mechanism.
+
开发人员觉得[http://xmpp.org/extensions/xep-0030.html 发现服务]不能包含更多的信息. 例如, <identity/> 元素不包含'description'属性, 我们可以增加这个属性吗? 答案是可以,但现在不行,太迟了(因为XEP-0030是最终版). 因此,最好的办法是制定一个扩充机制.
  
−
Let us consider an example. A Multi-User Chat [2] room might want to include additional information in its service discovery results, such as the full room description, the current discussion topic (room subject), the number of occupants in the room, and the JID of the room owner.
+
让我们参考一个示例. 一个[http://xmpp.org/extensions/xep-0045.html 多用户聊天室][http://xmpp.org/extensions/xep-0128.html#nt-id92624[2]] 可能想要获取更多的信息, 包括房间描述信息,房间主题,房间在线人数和房间所有者的JID.
  
−
Adding one new attribute to the service discovery schema (even if that were an option) would not solve the problem, since a MUC service might want to provide certain bits of information, whereas a Publish-Subscribe [3] service might want to provide other bits.
+
增加一个新属性的服务发现架构(即使真的是一个选项)不能解决的问题,因为一MUC的服务可能需要提供某些信息，而发布，[http://xmpp.org/extensions/xep-0060.html 订阅] [http://xmpp.org/extensions/xep-0128.html#nt-id92653[3]]服务可能需要提供其信息。
  
−
A better solution would be to include extended information qualified by a namespace that provides a way to flexibly define structured data formats. Thankfully, we already possess such a protocol: Data Forms [4]. In addition, we possess a way to define common fields used in data forms: Field Standardization for Data Forms [5]. Using these building blocks, we can define some best practices for extending service discovery results.
+
一个更好的解决办法是通过一个扩展的信息包括命名空间，提供了一种灵活的结构化数据格式定义合格。 谢天谢地，我们已经拥有了这样一个协议： [http://xmpp.org/extensions/xep-0004.html 数据表格] [http://xmpp.org/extensions/xep-0128.html#nt-id92681[4]]。 此外，我们拥有一个共同的方式来定义字段形式用于数据： [http://xmpp.org/extensions/xep-0068.html 数据表格现场标准化] [http://xmpp.org/extensions/xep-0128.html#nt-id92702 [5]]。 使用这些构建模块，我们可以定义为扩展服务发现结果的一些最佳做法。
  
−
2. Recommendations
+
==建议==
−
If an entity desires to provide extended information about itself in an IQ results stanza within the context of the Service Discovery protocol, it SHOULD do so by including each bit of information as the XML character data of the <value/> child of a distinct <field/> element, with the entire set of fields contained within an <x/> element of type "result" qualified by the 'jabber:x:data' namespace; this <x/> element SHOULD be a child of the <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace. Thus the IQ result SHOULD be of the following form:
+
如果一个实体的希望提供服务发现协议的扩展信息,出现在回复信息内,它应该这样做:每个独立的<field/>元素包含<value/>点数据信息子节点,所有<field/>元素包含在一个类型为"result"命名空间值为'jabber:x:data'的<x/>元素里.
  
 +
<source lang="xml">
 +
<iq type="result">
 +
<query xmlns="http://jabber.org/protocol/disco#info"> 
 +
  ...
 +
  <x type='result' xmlns='jabber:x:data'>
 +
    <field var='[var-name]' label='[optional]'>
 +
    <value>[var-value]</value>
 +
    </field>
 +
    ...
 +
  </x>
 +
</query>
 +
</iq>
 +
</source>
  
−
<iq type='result'>
+
如果数据字段被用来在由XMPP标准基金会核准的议定书时，他们应该符合相关的XMPP扩展协议规范并按照XEP - 0068定义的规则注册，返回信息中包含一个<field/>元素,其'var'属性为"FORM_TYPE"，其'type'属性的值为"hidden"。
−
  <query xmlns='http://jabber.org/protocol/disco#info'>  
+
−
    ...
+
−
    <x type='result' xmlns='jabber:x:data'>
+
−
      <field var='[var-name]' label='[optional]'>
+
−
        <value>[var-value]</value>
+
−
      </field>
+
−
      ...
+
−
    </x>
+
−
  </query>
+
−
</iq>Note: A <field/> element MAY contain more than one <value/> child if appropriate.
+
  
−
If the data fields are to be used in the context of a protocol approved by the XMPP Standards Foundation, they SHOULD be described in the relevant XMPP Extension Protocol specification and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".
+
一个实体不能提供'http://jabber.org/protocol/disco#items' 命名空间相关子信息,因为服务发现的核心原则是：一个实体必须确定其身份,不界定的身份与子节点的实体.
  
−
An entity MUST NOT supply extended information about associated children communicated via the 'http://jabber.org/protocol/disco#items' namespace, since a core principle of Service Discovery is that an entity must define its own identity only and must not define the identity of any children associated with the entity.
+
==示例==
 +
===IM服务器===
  
−
3. Examples
+
以下是即时消息服务器返回一个标准的服务查询的例子.
−
3.1 IM Server
+
−
The following is an example of including a disco extension in the IQ result sent by a standard instant messaging server.
+
  
−
Example 1. Entity Queries Server for Information
+
'''例1. 实体查询信息服务器'''
  
 +
<source lang="xml">
 
<iq type='get'  
 
<iq type='get'  
 
     from='capulet.com'  
 
     from='capulet.com'  
 
     to='shakespeare.lit'  
 
     to='shakespeare.lit'  
 
     id='disco1'>  
 
     id='disco1'>  
−
   <query xmlns='http://jabber.org/protocol/disco#info'/>  
+
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 
</iq>  
 
</iq>  
−
+
 
−
<iq type='result'  
+
<iq type='result' from='shakespeare.lit'  
−
    from='shakespeare.lit'  
+
 
     to='capulet.com'  
 
     to='capulet.com'  
 
     id='disco1'>  
 
     id='disco1'>  
第121行： 第100行：
 
     </x>  
 
     </x>  
 
   </query>  
 
   </query>  
−
</iq>  
+
</iq>
−
    3.2 Multi-User Chat Room
+
</source>
−
The following is an example of including a disco extension in the IQ result sent by a Multi-User Chat room.
+
 
 +
===群===
 +
 
 +
下面是在多用户房间里查询服务的例子.
  
−
Example 2. User Queries Room for Information
+
'''例2. 用户查询房间信息'''
  
 +
<source lang="xml">
 
<iq type='get'  
 
<iq type='get'  
 
     from='hag66@shakespeare.lit/pda'  
 
     from='hag66@shakespeare.lit/pda'  
第163行： 第146行：
 
     </x>  
 
     </x>  
 
   </query>  
 
   </query>  
−
</iq>  
+
</iq>
−
    4. Implementation Notes
+
</source>
−
In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.
+
  
−
5. Security Considerations
+
==实现说明==
−
Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.
+
  
−
6. IANA Considerations
+
一般来说，XMPP标准基金会给每一个发现服务在注册登记时指定一个FORM_TYPE.此外，特定的应用可以定义应用程序以及具体FORM_TYPEs，一个实体可以有多个服务发现的身份（例如，一个XMPP服务器也可能作为一个发布，订阅服务）。因此，它是可能的（允许一个单一的服务发现的结果，发现含有多种服务扩展元素（可能高达2为每个标识元素））。然而，在实践中是不可能发现任何特定服务的结果将包含多个服务扩展元素的发现。
−
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [6].
+
  
−
7. XMPP Registrar Considerations
+
==安全注意事项==
−
This document requires no interaction with the XMPP Registrar [7]; however, specifications following the best practices defined herein may register FORM_TYPEs and field values with the XMPP Registrar.
+
  
 +
应用程序应确网络上任何实体都能发现服务扩展信息.
  
−
--------------------------------------------------------------------------------
+
==IANA注意事项==
−
Appendices
+
  
−
--------------------------------------------------------------------------------
+
这份文件并不需要与互联网分配编码机构(IANA) [6]互动.
−
Appendix A: Document Information
+
−
Series: XEP
+
−
Number: 0128
+
−
Publisher: XMPP Standards Foundation
+
−
Status: Active
+
−
Type: Informational
+
−
Version: 1.0
+
−
Last Updated: 2004-10-20
+
−
Approving Body: XMPP Council
+
−
Dependencies: XMPP Core, XEP-0004, XEP-0030, XEP-0068
+
−
Supersedes: None
+
−
Superseded By: None
+
−
Short Name: N/A
+
−
Source Control: HTML  RSS
+
−
This document in other formats: XML  PDF
+
  
 +
==XMPP协议注册事项==
  
−
--------------------------------------------------------------------------------
+
本文件并不需要的相互作用的XMPP注册 [ 7 ]，但是，最佳做法是在XMPP的登记FORM_TYPEs和field值.
−
Appendix B: Author Information
+
−
Peter Saint-Andre
+
−
Email: stpeter@jabber.org
+
−
JabberID: stpeter@jabber.org
+
−
URI: https://stpeter.im/
+
  
 +
==附录==
  
 +
===附录A:文档信息===
  
−
--------------------------------------------------------------------------------
+
系列：[http://xmpp.org/extensions/ XEP]
−
Appendix C: Legal Notices
+
−
Copyright
+
−
This XMPP Extension Protocol is copyright © 1999 - 2010 by the XMPP Standards Foundation (XSF).
+
−
Permissions
+
−
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
+
−
Disclaimer of Warranty
+
−
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
+
−
Limitation of Liability
+
−
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
+
−
IPR Conformance
+
−
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).
+
  
−
--------------------------------------------------------------------------------
+
序号：0128
−
Appendix D: Relation to XMPP
+
−
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
+
  
 +
发布者：[http://xmpp.org/xsf/ XMPP标准基金会]
  
−
--------------------------------------------------------------------------------
+
状态：[http://www.xmpp.org/extensions/xep-0001.html#states-Final 终结版]
−
Appendix E: Discussion Venue
+
−
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
+
  
−
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
+
类型：[http://www.xmpp.org/extensions/xep-0001.html#types-Standards%20Track 标准跟踪]
  
−
Errata can be sent to <editor@xmpp.org>.
+
版本：1.0
  
 +
最后更新：2004-10-20
  
−
--------------------------------------------------------------------------------
+
批准机构：[http://xmpp.org/council/ XMPP理事会]
−
Appendix F: Requirements Conformance
+
 
−
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
+
依赖标准：[[XEP-0004|XEP-0030|XEP-0068|XMPP Core]]
 +
 
 +
取代: 无
 +
 
 +
被替代标准：无
 +
 
 +
缩略名：N/A
 +
 
 +
原文控制： [http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0128.xml HTML] [http://svn.xmpp.org:18080//changelog/~rss/XMPP/trunk/extensions/xep-0128.xml/rss.xml RSS]
 +
 
 +
本文的其它格式： [http://xmpp.org/extensions/xep-0030.xml XML] [http://xmpp.org/extensions/xep-0128.pdf PDF]
  
  
 
--------------------------------------------------------------------------------
 
--------------------------------------------------------------------------------
−
Appendix G: Notes
+
===附录B:作者信息===
 +
'''Peter Saint-Andre'''
 +
 
 +
Email: stpeter@jabber.org
 +
 
 +
JabberID: stpeter@jabber.org
 +
 
 +
URI: https://stpeter.im/
 +
 
 +
 
 +
 
 +
{{Template:XEP附录CDEF}}
 +
 
 +
===附录G:备注===
 
1. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.
 
1. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.
  
第257行： 第229行：
  
 
--------------------------------------------------------------------------------
 
--------------------------------------------------------------------------------
−
Appendix H: Revision History
+
If you are looking for a pair of pretty UGG Boots, you shouldn't miss this chance for purchasing UGG Classic Cardy Boots this season in our shop. Ugg Bailey Button would give people such a deep impression. UGG Classic Short Boots appreciate it not only by the high quality with steady innovations but also by its stylish designs. There is no doubt that it could go well with you casual outfits. There are many kinds of UGG Classic Tall Boots for different ages and tastes online. So pick up your own UGG Sandals now.
−
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
+
 
 +
===附录H:修订历史===
 +
注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用
  
 
Version 1.0 (2004-10-20)
 
Version 1.0 (2004-10-20)
 +
 
Per a vote of the Jabber Council, advanced status to Active; also added implementation notes. (psa)  
 
Per a vote of the Jabber Council, advanced status to Active; also added implementation notes. (psa)  
 +
 
Version 0.2 (2004-03-15)
 
Version 0.2 (2004-03-15)
 +
 
Clarified syntax and corrected several errors; added IM server example. (psa)  
 
Clarified syntax and corrected several errors; added IM server example. (psa)  
 +
 
Version 0.1 (2004-03-05)
 
Version 0.1 (2004-03-05)
 +
 
Initial version. (psa)  
 
Initial version. (psa)  
  
 
--------------------------------------------------------------------------------
 
--------------------------------------------------------------------------------
  
−
END
+
结束

2011年5月18日 (三) 12:31的最后版本


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

XEP-0128: 发现服务扩展

摘要: 这个文件规定了发现服务的扩展信息的最佳做法。

作者: Peter Saint-Andre

版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.

现状: 活跃

类型: 信息

版本: 1.0

最后更新: 2004-10-20


注意：注意：此信息规范定义了一个最佳实践或协议配置文件已被批准的XMPP理事会和/或董事XSF局。实现是鼓励和最佳做法或协议配置文件是在生产系统中部署适当的。


目录

简介

开发人员觉得发现服务不能包含更多的信息. 例如, <identity/> 元素不包含'description'属性, 我们可以增加这个属性吗? 答案是可以,但现在不行,太迟了(因为XEP-0030是最终版). 因此,最好的办法是制定一个扩充机制.

让我们参考一个示例. 一个多用户聊天室[2] 可能想要获取更多的信息, 包括房间描述信息,房间主题,房间在线人数和房间所有者的JID.

增加一个新属性的服务发现架构(即使真的是一个选项)不能解决的问题,因为一MUC的服务可能需要提供某些信息，而发布，订阅 [3]服务可能需要提供其信息。

一个更好的解决办法是通过一个扩展的信息包括命名空间，提供了一种灵活的结构化数据格式定义合格。 谢天谢地，我们已经拥有了这样一个协议： 数据表格 [4]。 此外，我们拥有一个共同的方式来定义字段形式用于数据： 数据表格现场标准化 [5]。 使用这些构建模块，我们可以定义为扩展服务发现结果的一些最佳做法。

建议

如果一个实体的希望提供服务发现协议的扩展信息,出现在回复信息内,它应该这样做:每个独立的<field/>元素包含<value/>点数据信息子节点,所有<field/>元素包含在一个类型为"result"命名空间值为'jabber:x:data'的<x/>元素里. 

<iq type="result">
<query xmlns="http://jabber.org/protocol/disco#info">  
  ...
  <x type='result' xmlns='jabber:x:data'>
    <field var='[var-name]' label='[optional]'>
    <value>[var-value]</value>
    </field>
    ...
  </x>
</query>
</iq>

如果数据字段被用来在由XMPP标准基金会核准的议定书时，他们应该符合相关的XMPP扩展协议规范并按照XEP - 0068定义的规则注册，返回信息中包含一个<field/>元素,其'var'属性为"FORM_TYPE"，其'type'属性的值为"hidden"。

一个实体不能提供'http://jabber.org/protocol/disco#items' 命名空间相关子信息,因为服务发现的核心原则是：一个实体必须确定其身份,不界定的身份与子节点的实体.

示例

IM服务器

以下是即时消息服务器返回一个标准的服务查询的例子.

例1. 实体查询信息服务器 

<iq type='get' 
    from='capulet.com' 
    to='shakespeare.lit' 
    id='disco1'> 
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> 
 
<iq type='result' from='shakespeare.lit' 
    to='capulet.com' 
    id='disco1'> 
  <query xmlns='http://jabber.org/protocol/disco#info'> 
    <identity 
        category='server' 
        type='im' 
        name='shakespeare.lit jabber server'/> 
    <feature var='jabber:iq:register'/> 
    <x xmlns='jabber:x:data' type='result'> 
      <field var='FORM_TYPE' type='hidden'> 
        <value>http://jabber.org/network/serverinfo</value> 
      </field> 
      <field var='c2s_port'> 
        <value>5222</value> 
      </field> 
      <field var='c2s_port_ssl'> 
        <value>5223</value> 
      </field> 
      <field var='http_access'> 
        <value>http://shakespeare.lit/jabber</value> 
      </field> 
      <field var='ip_version'> 
        <value>ipv4</value> 
        <value>ipv6</value> 
      </field> 
      <field var='info_url'> 
        <value>http://shakespeare.lit/support.php</value> 
      </field> 
    </x> 
  </query> 
</iq>

群

下面是在多用户房间里查询服务的例子.

例2. 用户查询房间信息 

<iq type='get' 
    from='hag66@shakespeare.lit/pda' 
    to='darkcave@macbeth.shakespeare.lit' 
    id='disco1'> 
  <query xmlns='http://jabber.org/protocol/disco#info'/> 
</iq> 
 
<iq type='result' 
    from='darkcave@macbeth.shakespeare.lit' 
    to='hag66@shakespeare.lit/pda' 
    id='disco1'> 
  <query xmlns='http://jabber.org/protocol/disco#info'> 
    <identity 
        category='conference' 
        type='text' 
        name='A Dark Cave'/> 
    <feature var='http://jabber.org/protocol/muc'/> 
    <feature var='jabber:iq:register'/> 
    <x xmlns='jabber:x:data' type='result'> 
      <field var='FORM_TYPE' type='hidden'> 
        <value>http://jabber.org/protocol/muc#roominfo</value> 
      </field> 
      <field var='muc#roominfo_description' label='Description'> 
        <value>The place for all good witches!</value> 
      </field> 
      <field var='muc#roominfo_subject' label='Subject'> 
        <value>Spells</value> 
      </field> 
      <field var='muc#roominfo_occupants' label='Number of occupants'> 
        <value>3</value> 
      </field> 
      <field var='muc#roominfo_lang' label='Language of discussion'> 
        <value>en</value> 
      </field> 
    </x> 
  </query> 
</iq>

实现说明

一般来说，XMPP标准基金会给每一个发现服务在注册登记时指定一个FORM_TYPE.此外，特定的应用可以定义应用程序以及具体FORM_TYPEs，一个实体可以有多个服务发现的身份（例如，一个XMPP服务器也可能作为一个发布，订阅服务）。因此，它是可能的（允许一个单一的服务发现的结果，发现含有多种服务扩展元素（可能高达2为每个标识元素））。然而，在实践中是不可能发现任何特定服务的结果将包含多个服务扩展元素的发现。

安全注意事项

应用程序应确网络上任何实体都能发现服务扩展信息.

IANA注意事项

这份文件并不需要与互联网分配编码机构(IANA) [6]互动.

XMPP协议注册事项

本文件并不需要的相互作用的XMPP注册 [ 7 ]，但是，最佳做法是在XMPP的登记FORM_TYPEs和field值.

附录

附录A:文档信息

系列：XEP

序号：0128

发布者：XMPP标准基金会

状态：终结版

类型：标准跟踪

版本：1.0

最后更新：2004-10-20

批准机构：XMPP理事会

依赖标准：XEP-0030|XEP-0068|XMPP Core

取代: 无

被替代标准：无

缩略名：N/A

原文控制： HTML RSS

本文的其它格式： XML PDF


附录B:作者信息

Peter Saint-Andre

Email: stpeter@jabber.org

JabberID: stpeter@jabber.org

URI: https://stpeter.im/


附录C:法律通告

版权

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

权限

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

免责声明'

## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##

责任限制

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

知识产权的一致性

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/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标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.

附录E:讨论地点

主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.

在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .

勘误表可以发送邮件到 <editor@xmpp.org>.

附录F:需求一致性

以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


附录G:备注

1. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

2. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

3. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

4. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

5. XEP-0068: Field Data Standardization for Data Forms <http://xmpp.org/extensions/xep-0068.html>.

6. 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/>.

7. 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://xmpp.org/registrar/>.


If you are looking for a pair of pretty UGG Boots, you shouldn't miss this chance for purchasing UGG Classic Cardy Boots this season in our shop. Ugg Bailey Button would give people such a deep impression. UGG Classic Short Boots appreciate it not only by the high quality with steady innovations but also by its stylish designs. There is no doubt that it could go well with you casual outfits. There are many kinds of UGG Classic Tall Boots for different ages and tastes online. So pick up your own UGG Sandals now.

附录H:修订历史

注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用

Version 1.0 (2004-10-20)

Per a vote of the Jabber Council, advanced status to Active; also added implementation notes. (psa)

Version 0.2 (2004-03-15)

Clarified syntax and corrected several errors; added IM server example. (psa)

Version 0.1 (2004-03-05)

Initial version. (psa)

结束

来自“http://wiki.jabbercn.org/index.php?title=XEP-0128&oldid=1301”
个人工具