mirror of https://github.com/moparisthebest/xeps
0.5 published
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3940 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
6b0f1a82eb
commit
789f15ebe7
162
xep-0215.xml
162
xep-0215.xml
|
|
@ -22,12 +22,13 @@
|
|||
<shortname>extdisco</shortname>
|
||||
&stpeter;
|
||||
&seanegan;
|
||||
<author>
|
||||
<firstname>Marcus</firstname>
|
||||
<surname>Lundblad</surname>
|
||||
<email>ml@update.uu.se</email>
|
||||
<jid>mlundblad@jabber.org</jid>
|
||||
</author>
|
||||
&mlundblad;
|
||||
<revision>
|
||||
<version>0.5</version>
|
||||
<date>2010-02-17</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Added ability to request credentials from a particular service; incremented the protocol version number to reflect the new feature.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.4</version>
|
||||
<date>2009-02-17</date>
|
||||
|
|
@ -85,7 +86,7 @@
|
|||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>An XMPP client or other entity may need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc5389;) and STUN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. <note>The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at <<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>>, but has been broadened in scope to address additional use cases if desired.</note> An XMPP entity can already discover such external services in several ways, including:</p>
|
||||
<p>An XMPP client or other entity might need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc5389;) and TURN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. <note>The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at <<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>>, but has been broadened in scope to address additional use cases if desired.</note> An XMPP entity can already discover such external services in several ways, including:</p>
|
||||
<ol>
|
||||
<li>The service is specified in the application's default settings.</li>
|
||||
<li>The service is manually added into the application's configuration by a human user.</li>
|
||||
|
|
@ -100,11 +101,11 @@
|
|||
</ul>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Unfortunately, some of the foregoing methods are subject to human error and others are either not widely available or cannot be deployed in wide range of scenarios (e.g., when the administrators of an XMPP service do not have access to DNS SRV records). Therefore, this document defines a way for an XMPP server or discovery service to provide information about external services, which may include extended information such as temporary credentials for authentication at such services. This method should be used only as a fallback when the relevant service discovery technologies (DNS SRV, DDDS, SLP, S-NAPTR, U-NAPTR, etc.) are not available to the XMPP entities involved (typically a client and server). This method does not use &xep0030; since that technology is designed for discovery of XMPP entities, not entities outside an XMPP network.</p>
|
||||
<p>Unfortunately, some of the foregoing methods are subject to human error and others are either not widely available or cannot be deployed in wide range of scenarios (e.g., when the administrators of an XMPP service do not have access to DNS SRV records). Therefore, this document defines a way for an XMPP server or discovery service to provide information about external services, which might include extended information such as temporary credentials for authentication at such services. This method SHOULD be used only as a fallback when the relevant service discovery technologies (DNS SRV, DDDS, SLP, S-NAPTR, U-NAPTR, etc.) are not available to the XMPP entities involved (typically a client and server). This method does not use &xep0030; since that technology is designed for discovery of XMPP entities, not entities outside an XMPP network.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Protocol' anchor='protocol'>
|
||||
<p>In order to learn about external services known to an XMPP server or discovery service, a requesting entity (typically a client) sends an IQ-get containing an empty <services/> element qualified by the 'urn:xmpp:extdisco:0' namespace &NSNOTE;, typically to its own server but perhaps alternatively to a dedicated discovery service.</p>
|
||||
<p>In order to learn about external services known to an XMPP server or discovery service, a requesting entity (typically a client) sends an IQ-get containing an empty <services/> element qualified by the 'urn:xmpp:extdisco:1' namespace &NSNOTE;, typically to its own server but perhaps alternatively to a dedicated discovery service.</p>
|
||||
<p>The responding entity (XMPP server or discovery service) SHOULD return the list of external services it is aware of, but MAY instead return an appropriate error, such as &unavailable; if the responding entity does not support this protocol or &forbidden; if the requesting entity does not have permission to receive the list of external services. Each service is encapsulated via a <service/> element.</p>
|
||||
<p>Note: The processes by which a responding entity discovers external services for "proxying" to XMPP entities are out of scope for this specification.</p>
|
||||
<p>The <service/> element MAY be empty or MAY include extended information about the service as described in the <link url='#extended'>Extended Information</link> section of this document.</p>
|
||||
|
|
@ -151,26 +152,26 @@
|
|||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>* Note: The processes by which an external service might generate or an XMPP server might negotiate the username and password are outside the scope of this specification. One possible approach is for the XMPP server to generate a short-term authentication credential based on a private key shared with the external service.</p>
|
||||
<p>* Note: The processes by which an external service might generate (or an XMPP server might negotiate) the username and password are outside the scope of this specification. One possible approach is for the XMPP server to generate a short-term authentication credential based on a private key shared with the external service.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Requesting All Services' anchor='all'>
|
||||
<p>A requesting entity requests all services by sending a <services/> element to its server or a discovery service.</p>
|
||||
<example caption='Entity Requests All External Services'><![CDATA[
|
||||
<iq type='get'
|
||||
from='bard@shakespeare.lit/globe'
|
||||
<iq from='bard@shakespeare.lit/globe'
|
||||
id='ul2bc7y6'
|
||||
to='shakespeare.lit'
|
||||
id='all1'>
|
||||
<services xmlns='urn:xmpp:extdisco:0'/>
|
||||
type='get'>
|
||||
<services xmlns='urn:xmpp:extdisco:1'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='XMPP Server Returns List'><![CDATA[
|
||||
<iq type='result'
|
||||
from='shakespeare.lit'
|
||||
<iq from='shakespeare.lit'
|
||||
id='ul2bc7y6'
|
||||
to='bard@shakespeare.lit/globe'
|
||||
id='all1'>
|
||||
<services xmlns='urn:xmpp:extdisco:0'>
|
||||
type='result'>
|
||||
<services xmlns='urn:xmpp:extdisco:1'>
|
||||
<service host='stun.shakespeare.lit'
|
||||
port='9998'
|
||||
transport='udp'
|
||||
|
|
@ -203,21 +204,21 @@
|
|||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Requesting Selected Services' anchor='select'>
|
||||
<p>A requesting entity requests selected services by sending a <services/> element including a 'type' attribute specifying the service type of interest.</p>
|
||||
<p>A requesting entity requests services of a particular type by sending a <services/> element including a 'type' attribute specifying the service type of interest.</p>
|
||||
<example caption='Entity Requests Selected Services'><![CDATA[
|
||||
<iq type='get'
|
||||
from='bard@shakespeare.lit/globe'
|
||||
<iq from='bard@shakespeare.lit/globe'
|
||||
id='yv2c19f7'
|
||||
to='shakespeare.lit'
|
||||
id='selected1'>
|
||||
<services xmlns='urn:xmpp:extdisco:0' type='turn'/>
|
||||
type='get'>
|
||||
<services xmlns='urn:xmpp:extdisco:1' type='turn'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='XMPP Server Returns List'><![CDATA[
|
||||
<iq type='result'
|
||||
from='shakespeare.lit'
|
||||
<iq from='shakespeare.lit'
|
||||
id='yv2c19f7'
|
||||
to='bard@shakespeare.lit/globe'
|
||||
id='selected1'>
|
||||
<services xmlns='urn:xmpp:extdisco:0'
|
||||
type='result'>
|
||||
<services xmlns='urn:xmpp:extdisco:1'
|
||||
type='turn'>
|
||||
<service host='turn.shakespeare.lit'
|
||||
password='jj929jkj5sadjfj93v3n'
|
||||
|
|
@ -234,13 +235,13 @@
|
|||
</services>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If a requesting entity requests selected services, the responding service MAY as needed send an updated list of the relevant services by "pushing" the list to a requesting entity that has previously requested the list. However, it MUST NOT push updates to the requesting entity unless it has presence information about the requesting entity (e.g., because the requesting entity is connected to the XMPP server or because the requesting entity has shared presence with a remote discovery service).</p>
|
||||
<p>If a requesting entity requests services of a particular type, the responding service MAY as needed send an updated list of the relevant services by "pushing" the list to a requesting entity that has previously requested the list. However, it MUST NOT push updates to the requesting entity unless it has presence information about the requesting entity (e.g., because the requesting entity is connected to the XMPP server or because the requesting entity has shared presence with a remote discovery service). A push is an IQ set to the requesting entity containing a <service/> payload with updated data about services matching the requested type (e.g., new services or updated credentials)</p>
|
||||
<example caption='Services Push'><![CDATA[
|
||||
<iq type='set'
|
||||
from='shakespeare.lit'
|
||||
<iq from='shakespeare.lit'
|
||||
id='lh3f1vc7'
|
||||
to='bard@shakespeare.lit/globe'
|
||||
id='push1'>
|
||||
<services xmlns='urn:xmpp:extdisco:0'
|
||||
type='set'>
|
||||
<services xmlns='urn:xmpp:extdisco:1'
|
||||
type='turn'>
|
||||
<service host='stun.shakespeare.lit'
|
||||
port='9999'
|
||||
|
|
@ -257,14 +258,42 @@
|
|||
</services>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Upon receiving a push, the requesting entity would then send an IQ-result to the responding service in accordance with &xmppcore;.</p>
|
||||
</section2>
|
||||
<section2 topic='Requesting Credentials' anchor='credentials'>
|
||||
<p>An entity might know about an external service via DNS or some other means, but still might need short-term credentials to use the service. The entity can request credentials by sending a special request to the server.</p>
|
||||
<example caption='Entity Requests Credentials at a Service'><![CDATA[
|
||||
<iq from='bard@shakespeare.lit/globe'
|
||||
id='xi2cax48'
|
||||
to='shakespeare.lit'
|
||||
type='get'>
|
||||
<credentials xmlns='urn:xmpp:extdisco:1'>
|
||||
<service host='turn.shakespeare.lit'/>
|
||||
</credentials>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The server then returns credentials if possible.</p>
|
||||
<example caption='Server Returns Credentials'><![CDATA[
|
||||
<iq from='shakespeare.lit'
|
||||
id='xi2cax48'
|
||||
to='bard@shakespeare.lit/globe'
|
||||
type='get'>
|
||||
<credentials xmlns='urn:xmpp:extdisco:1'>
|
||||
<service host='turn.shakespeare.lit'
|
||||
password='jj929jkj5sadjfj93v3n'
|
||||
username='nb78932lkjlskjfdb7g8'/>
|
||||
</credentials>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the server cannot obtain credentials at the service, it returns an appropriate stanza error, such as ¬found;, &remoteserver;, &timeout;, or ¬authorized;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Extended Information' anchor='extended'>
|
||||
<p>If a server or service needs to include extended information, 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 (see &xep0004;); this <x/> element SHOULD be a child of the <service/> element qualified by the 'urn:xmpp:extdisco:0' namespace &NSNOTE;. Thus the IQ result SHOULD be of the following form:</p>
|
||||
<p>If a server or service needs to include extended information, 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 (see &xep0004;); this <x/> element SHOULD be a child of the <service/> element qualified by the 'urn:xmpp:extdisco:1' namespace &NSNOTE;. Thus the IQ result SHOULD be of the following form:</p>
|
||||
<code><![CDATA[
|
||||
<iq type='result'>
|
||||
<services xmlns='urn:xmpp:extdisco:0'>
|
||||
<services xmlns='urn:xmpp:extdisco:1'>
|
||||
<service>
|
||||
<x type='result' xmlns='jabber:x:data'>
|
||||
<field var='[var-name]' label='[optional]'>
|
||||
|
|
@ -276,27 +305,27 @@
|
|||
</services>
|
||||
</iq>]]></code>
|
||||
<p>Note: A <field/> element MAY contain more than one <value/> child if appropriate.</p>
|
||||
<p>If the data fields are to be used in the context of a protocol approved by the XMPP Standards Foundation, they SHOULD be 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".</p>
|
||||
<p>Note: Although &xep0128; specifies that an XMPP entity MUST NOT supply extended information about associated children communicated via the 'urn:xmpp:extdisco:0' namespace, that rule does not apply to External Service Discovery since services external to the XMPP network cannot communicate via XMPP.</p>
|
||||
<p>If the data fields are to be used in the context of a protocol approved by the XMPP Standards Foundation, they SHOULD be registered in accordance with the rules defined in &xep0068;, 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".</p>
|
||||
<p>Note: Although &xep0128; specifies that an XMPP entity MUST NOT supply extended information about associated children communicated via the 'http://jabber.org/protocol/disco#info' namespace, that rule does not apply to External Service Discovery since services external to the XMPP network cannot communicate via XMPP.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Determining Support' anchor='disco'>
|
||||
<p>If an entity supports the STUN Server Discovery protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:extdisco:0" &NSNOTE; in response to a &xep0030; information request:</p>
|
||||
<p>If an XMPP entity supports this protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:extdisco:1" &NSNOTE; in response to a &xep0030; information request:</p>
|
||||
<example caption="Service Discovery Information Request"><![CDATA[
|
||||
<iq type='get'
|
||||
from='romeo@montague.lit/orchard'
|
||||
<iq from='romeo@montague.lit/orchard'
|
||||
id='ix61z3m9'
|
||||
to='montague.lit'
|
||||
id='disco1'>
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Service Discovery Information Response"><![CDATA[
|
||||
<iq type='result'
|
||||
from='montague.lit'
|
||||
<iq from='montague.lit'
|
||||
id='ix61z3m9'
|
||||
to='romeo@montague.lit/orchard'
|
||||
id='disco1'>
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<feature var='urn:xmpp:extdisco:0'/>
|
||||
<feature var='urn:xmpp:extdisco:1'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
|
@ -314,7 +343,7 @@
|
|||
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||
<p>This specification defines the following XML namespace:</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:extdisco:0</li>
|
||||
<li>urn:xmpp:extdisco:1</li>
|
||||
</ul>
|
||||
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
|
||||
</section2>
|
||||
|
|
@ -332,7 +361,7 @@
|
|||
<doc>the document that best defines the service type</doc>
|
||||
</service>
|
||||
]]></code>
|
||||
<p>The registrant may register more than one service type at a time, each contained in a separate <service/> element.</p>
|
||||
<p>The registrant can register more than one service type at a time, each contained in a separate <service/> element.</p>
|
||||
</section3>
|
||||
<section3 topic='Registration' anchor='registrar-methods-init'>
|
||||
<code><![CDATA[
|
||||
|
|
@ -358,8 +387,8 @@
|
|||
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:extdisco:0'
|
||||
xmlns='urn:xmpp:extdisco:0'
|
||||
targetNamespace='urn:xmpp:extdisco:1'
|
||||
xmlns='urn:xmpp:extdisco:1'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:import
|
||||
|
|
@ -375,34 +404,35 @@
|
|||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:element name='service'>
|
||||
<xs:element name='credentials'>
|
||||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='host' type='xs:string' use='required'/>
|
||||
<xs:attribute name='name' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='password' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='port' type='xs:string' use='required'/>
|
||||
<xs:attribute name='transport' type='xs:NCName' use='optional'/>
|
||||
<xs:attribute name='type' type='xs:NCName' use='required'/>
|
||||
<xs:attribute name='username' type='xs:string' use='optional'/>
|
||||
</xs:extension>
|
||||
</xs:simpleContent>
|
||||
<xs:sequence>
|
||||
<xs:element ref='service' minOccurs='0' maxOccurs='1'/>
|
||||
</xs:sequence>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:simpleType name='empty'>
|
||||
<xs:restriction base='xs:string'>
|
||||
<xs:enumeration value=''/>
|
||||
</xs:restriction>
|
||||
</xs:simpleType>
|
||||
<xs:element name='service'>
|
||||
<xs:complexType>
|
||||
<xs:sequence xmlns:xdata='jabber:x:data'>
|
||||
<xs:element ref='xdata:x' minOccurs='0'/>
|
||||
</xs:sequence>
|
||||
<xs:attribute name='host' type='xs:string' use='required'/>
|
||||
<xs:attribute name='name' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='password' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='port' type='xs:string' use='required'/>
|
||||
<xs:attribute name='transport' type='xs:NCName' use='optional'/>
|
||||
<xs:attribute name='type' type='xs:NCName' use='required'/>
|
||||
<xs:attribute name='username' type='xs:string' use='optional'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Justin Karneges and Unnikrishnan Vikrama Panicker for their feedback.</p>
|
||||
<p>Thanks to Justin Karneges, Evgeniy Khramtsov, and Unnikrishnan Vikrama Panicker for their feedback.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
|
|
|||
Loading…
Reference in New Issue