mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-12 20:35:13 -05:00
d5f22dffb8
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@302 4b5297f7-1745-476d-ba37-a9c6900126ab
277 lines
12 KiB
XML
277 lines
12 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Proposed Resource Binding Improvements</title>
|
|
<abstract>This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0193</number>
|
|
<status>Proposed</status>
|
|
<type>Standards Track</type>
|
|
<jig>Standards JIG</jig>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes>None</supersedes>
|
|
<supersededby>None</supersededby>
|
|
<shortname>N/A</shortname>
|
|
&stpeter;
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2007-01-02</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Required client to include from address on every stanza it sends over a stream to which it has bound multiple resources; specified server handling of sessions.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2006-08-16</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Initial version.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.2</version>
|
|
<date>2006-08-15</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Added stream feature for unbind.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2006-08-15</date>
|
|
<initials>psa</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='proto'>
|
|
&RFC3920BISNOTE;
|
|
<p><cite>RFC 3920</cite> introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &xep0078;). As defined in <cite>RFC 3920</cite>, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.</p>
|
|
<p>Note: The recommendations described herein have been incorporated into <cite>rfc3920bis</cite>.</p>
|
|
</section1>
|
|
<section1 topic='Unbinding a Resource' anchor='unbind'>
|
|
<p>In order to properly manage the resources associated with an XML stream, a client must be able to unbind resources. This shall be completed by sending an IQ-set with a child element of <unbind/> qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of <resource/> whose XML character data specifies the resource to be unbound:</p>
|
|
<example caption='Unbind'><![CDATA[
|
|
<iq type='set' id='bind_2'>
|
|
<unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>someresource</resource>
|
|
</unbind>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the server does not understand the <unbind/> element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of ¬found;. When the client unbinds the only resource associated with the stream, the server SHOULD close the stream and terminate the TCP connection.</p>
|
|
<p>A server SHOULD advertise its support for the 'urn:ietf:params:xml:ns:xmpp-bind' namespace and the unbind functionality by returning an appropriate stream feature as shown below:</p>
|
|
<example caption='Unbind Stream Feature'><![CDATA[
|
|
<stream:features>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<required/>
|
|
</bind>
|
|
<unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
|
|
</stream:features>
|
|
]]></example>
|
|
</section1>
|
|
<section1 topic='Business Rules' anchor='bizrules'>
|
|
<section2 topic='From Addresses' anchor='from'>
|
|
<p>When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST do one of the following:</p>
|
|
<ol>
|
|
<li>Stamp the stanza with the resource that the server considers to be the "default resource" for the stream. <note>The default resource SHOULD be the oldest resource bound to the stream, which typically will be the initial resource but which might be a resource bound later if subsequently the initial resource has been unbound.</note></li>
|
|
<li>Return the stanza to the client with an <unknown-sender/> stanza error. <note>Currently there is no <unknown-sender/> stanza defined in <cite>RFC 3920</cite>; the author will work to add such an error condition to <cite>rfc3920bis</cite>.</note></li>
|
|
</ol>
|
|
<p>Which of these a server does is up to the implementation or deployment.</p>
|
|
<p>Naturally, the existing rules from <cite>RFC 3920</cite> regarding validation of asserted 'from' addresses still apply.</p>
|
|
</section2>
|
|
<section2 topic='Server Sessions' anchor='sessions'>
|
|
<p>In instant messaging and presence applications, an XMPP server manages a session on behalf of a connected client. A server MUST create and manage a separate session for each distinct resource, even if there are multiple resources associated with a given XML stream. In particular:</p>
|
|
<ol>
|
|
<li>A server MUST consider each resource to be a distinct source of presence information, both with regard to presence notifications and with regard to presence probes.</li>
|
|
<li>A server MUST manage rosters (see <cite>RFC 3920</cite>) and &xep0016; separately for each resource.</li>
|
|
</ol>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Examples' anchor='examples'>
|
|
<p>The following examples show a possible flow of resource binding and unbinding.</p>
|
|
<p>First, the client binds an initial resource to the stream.</p>
|
|
<example caption='Binding an Initial Resource'><![CDATA[
|
|
<iq type='set' id='bind-1'>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>core</resource>
|
|
</bind>
|
|
</iq>
|
|
|
|
<iq type='result' id='bind-1'>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<jid>juliet@capulet.com/core</jid>
|
|
</bind>
|
|
</iq>
|
|
]]></example>
|
|
<p>Now the client sends some stanzas, making sure to set its 'from' address:</p>
|
|
<example caption='Sending Some Stanzas'><![CDATA[
|
|
<iq from='juliet@capulet.com/core' type='get' id='roster-1'>
|
|
<query xmlns='jabber:iq:roster'/>
|
|
</iq>
|
|
|
|
<iq to='juliet@capulet.com/core' type='result' id='roster-1'>
|
|
<query xmlns='jabber:iq:roster'>
|
|
<item jid='romeo@montague.net'/>
|
|
</query>
|
|
</iq>
|
|
|
|
<presence from='juliet@capulet.com/core'/>
|
|
]]></example>
|
|
<p>Now the client binds a second resource to the stream.</p>
|
|
<example caption='Binding a Second Resource'><![CDATA[
|
|
<iq type='set' id='bind-2'>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>balcony</resource>
|
|
</bind>
|
|
</iq>
|
|
|
|
<iq type='result' id='bind-2'>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<jid>juliet@capulet.com/balcony</jid>
|
|
</bind>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in <cite>RFC 3920</cite>.</p>
|
|
<p>Now the client sends more stanzas.</p>
|
|
<example caption='Sending More Stanzas'><![CDATA[
|
|
<iq from='juliet@capulet.com/balcony' type='get' id='roster-2'>
|
|
<query xmlns='jabber:iq:roster'/>
|
|
</iq>
|
|
|
|
<iq to='juliet@capulet.com/balcony' type='result' id='roster-2'>
|
|
<query xmlns='jabber:iq:roster'>
|
|
<item jid='romeo@montague.net'/>
|
|
</query>
|
|
</iq>
|
|
|
|
<presence from='juliet@capulet.com/balcony'/>
|
|
|
|
<message to='romeo@montague.net'>
|
|
<body>Wherefore art thou?</body>
|
|
</message>
|
|
]]></example>
|
|
<p>In handling the last stanza shown above, the server will either return a <unknown-sender/> error or stamped the 'from' address <juliet@capulet.com/core> (but in no case will the server stamp the 'from' address as <juliet@capulet.com/balcony>. Here we assume that the server stamps the 'from' address.</p>
|
|
<p>Now the client binds a third resource to the stream.</p>
|
|
<example caption='Binding a Third Resource'><![CDATA[
|
|
<iq type='set' id='bind-3'>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>softphone</resource>
|
|
</bind>
|
|
</iq>
|
|
|
|
<iq type='result' id='bind-3'>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<jid>juliet@capulet.com/softphone</jid>
|
|
</bind>
|
|
</iq>
|
|
]]></example>
|
|
<p>Now the client unbinds its initial resource.</p>
|
|
<example caption='Unbinding a Resource'><![CDATA[
|
|
<iq type='set' id='unbind-1'>
|
|
<unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>core</resource>
|
|
</unbind>
|
|
</iq>
|
|
|
|
<iq type='result' id='unbind-1'/>
|
|
]]></example>
|
|
<p>Now the client sends another stanza without a 'from' address, which we assume the server stamps as from the new default resource (note that this is no longer the initial resource):</p>
|
|
<example caption='Client Generates Another Stanza'><![CDATA[
|
|
<message to='romeo@montague.net'>
|
|
<body>Art thou not Romeo, and a Montague?</body>
|
|
</message>
|
|
]]></example>
|
|
<example caption='Server Stamps Stanza As From (New) Default Resource'><![CDATA[
|
|
<message from='juliet@capulet.com/balcony' to='romeo@montague.net'>
|
|
<body>Art thou not Romeo, and a Montague?</body>
|
|
</message>
|
|
]]></example>
|
|
<p>Now the client unbinds another resource.</p>
|
|
<example caption='Unbinding a Resource'><![CDATA[
|
|
<iq type='set' id='unbind-2'>
|
|
<unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>softphone</resource>
|
|
</unbind>
|
|
</iq>
|
|
|
|
<iq type='result' id='unbind-2'/>
|
|
]]></example>
|
|
<p>Now the client unbinds its last remaining resource.</p>
|
|
<example caption='Unbinding the Final Resource'><![CDATA[
|
|
<iq type='set' id='unbind-3'>
|
|
<unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
|
|
<resource>balcony</resource>
|
|
</unbind>
|
|
</iq>
|
|
|
|
<iq type='result' id='unbind-3'/>
|
|
]]></example>
|
|
<p>The server now SHOULD close the stream and terminate the underlying TCP connection.</p>
|
|
<example caption='Server Closes the Stream'><![CDATA[
|
|
</stream:stream>
|
|
]]></example>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in <cite>RFC 3920</cite>. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>No interaction with &IANA; is required as a result of this document.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>No interaction with the ®ISTRAR; is required as a result of this document.</p>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<p>Note: The following provisional schema is intended to replace the existing schema for the Resource Binding stream feature.</p>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='urn:ietf:params:xml:ns:xmpp-bind'
|
|
xmlns='urn:ietf:params:xml:ns:xmpp-bind'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:element name='bind'>
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:choice minOccurs='0' maxOccurs='1'>
|
|
<xs:element name='resource' type='resourceType'/>
|
|
<xs:element name='jid' type='fullJIDType'/>
|
|
</xs:choice>
|
|
<xs:element name='required'
|
|
minOccurs='0'
|
|
maxOccurs='1'
|
|
type='empty'/>
|
|
</xs:choice>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:element name='unbind'>
|
|
<xs:complexType>
|
|
<xs:sequence minOccurs='0'>
|
|
<xs:element name='resource' type='resourceType'/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:simpleType name='resourceType'>
|
|
<xs:restriction base='xs:string'>
|
|
<xs:minLength value='1'/>
|
|
<xs:maxLength value='1023'/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
|
|
<xs:simpleType name='fullJIDType'>
|
|
<xs:restriction base='xs:string'>
|
|
<xs:minLength value='8'/>
|
|
<xs:maxLength value='3071'/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
|
|
</xs:schema>
|
|
]]></code>
|
|
</section1>
|
|
</xep>
|