moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

0.2

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@302 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-02 23:07:55 +00:00
parent 88e0258b41
commit d5f22dffb8
1 changed files with 25 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
xep-0193.xml
View File

@ -20,6 +20,12 @@
<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>
@ -64,14 +70,23 @@
</stream:features>
]]></example>
</section1>
<section1 topic='Managing From Addresses' anchor='from'>
<p>When a client binds multiple resources to a stream, proper management of 'from' addresses is imperative. The following rules apply:</p>
<ol start='1'>
<li>A client SHOULD specify a 'from' address on every stanza.</li>
<li>If a client does not specify a 'from' address, the server MUST stamp a 'from' address, which SHOULD be the "default" resource as specified below.</li>
</ol>
<p>The "default" resource SHOULD be the oldest resource bound to the stream; normally that will be the initial resource, but it may be a resource bound later (i.e., if subsequently the initial resource has been unbound).</p>
<p>Naturally, the existing rules from <cite>RFC 3920</cite> regarding validation of asserted 'from' addresses still apply.</p>
<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 &lt;unknown-sender/&gt; stanza error. <note>Currently there is no &lt;unknown-sender/&gt; 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>
@ -136,7 +151,7 @@
<body>Wherefore art thou?</body>
</message>
]]></example>
<p>Note that the last stanza sent will be stamped by the server as from &lt;juliet@capulet.com/core&gt;, <em>not</em> as from &lt;juliet@capulet.com/balcony&gt;.</p>
<p>In handling the last stanza shown above, the server will either return a &lt;unknown-sender/&gt; error or stamped the 'from' address &lt;juliet@capulet.com/core&gt; (but in no case will the server stamp the 'from' address as &lt;juliet@capulet.com/balcony&gt;. 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'>
@ -161,7 +176,7 @@
<iq type='result' id='unbind-1'/>
]]></example>
<p>Now the client sends another stanza without a 'from' address, which the server stamps as from the new default resource (i.e., no longer the initial resource):</p>
<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>