查看源代码

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

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

'''XEP-0128: 发现服务扩展协议'''

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

作者: Peter Saint-Andre 

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

现状: 活跃 

类型: 信息 

版本: 1.0 

最后更新: 2004-10-20 


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


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

让我们参考一个示例. 一个多用户聊天室[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.

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.

==建议==
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:


<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>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".

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服务器===
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

<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> 
===群===
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

<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> 

==实现说明==
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.

==安全注意事项==
Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.

==IANA注意事项==
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [6].

==XMPP协议注册事项==
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.


==附录==

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

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

序号：0128

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

状态：[http://www.xmpp.org/extensions/xep-0001.html#states-Final 终结版]

类型：[http://www.xmpp.org/extensions/xep-0001.html#types-Standards%20Track 标准跟踪]

版本：1.0

最后更新：2004-10-20

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

依赖标准：[[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]


--------------------------------------------------------------------------------
===附录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>.

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


--------------------------------------------------------------------------------
===附录H:修订历史===
Note: Older versions of this specification might be available at 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) 

--------------------------------------------------------------------------------

END