From d5f22dffb8573ae596349637bc86601a4cc0430f Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 2 Jan 2007 23:07:55 +0000 Subject: [PATCH] 0.2 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@302 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0193.xml | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/xep-0193.xml b/xep-0193.xml index e0b024b7..3ac4c4b8 100644 --- a/xep-0193.xml +++ b/xep-0193.xml @@ -20,6 +20,12 @@ None N/A &stpeter; + + 0.2 + 2007-01-02 + psa +

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.

 + 0.1 2006-08-16 @@ -64,14 +70,23 @@ ]]> - -

When a client binds multiple resources to a stream, proper management of 'from' addresses is imperative. The following rules apply:

-
    -
  1. A client SHOULD specify a 'from' address on every stanza.
    2. -
  2. 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.
    3. -
-

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

-

Naturally, the existing rules from RFC 3920 regarding validation of asserted 'from' addresses still apply.

+ + +

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:

+
    +
  1. Stamp the stanza with the resource that the server considers to be the "default resource" for the stream. 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.
    2. +
  2. Return the stanza to the client with an <unknown-sender/> stanza error. Currently there is no <unknown-sender/> stanza defined in RFC 3920; the author will work to add such an error condition to rfc3920bis.
    3. +
+

Which of these a server does is up to the implementation or deployment.

+

Naturally, the existing rules from RFC 3920 regarding validation of asserted 'from' addresses still apply.

+ + +

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:

+
    +
  1. 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.
    2. +
  2. A server MUST manage rosters (see RFC 3920) and &xep0016; separately for each resource.
    3. +
+

The following examples show a possible flow of resource binding and unbinding.

@@ -136,7 +151,7 @@ Wherefore art thou? ]]> -

Note that the last stanza sent will be stamped by the server as from <juliet@capulet.com/core>, not as from <juliet@capulet.com/balcony>.

+

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.

Now the client binds a third resource to the stream.

@@ -161,7 +176,7 @@ ]]> -

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

+

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

Art thou not Romeo, and a Montague?