[Standards-JIG] proto-JEP: Flagging the Primary Resource

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Fri Sep 30 14:02:54 UTC 2005

Knowing the 'primary' source for presence is only necessary to bridge
between XMPP and its built in multi resource behavior and all the other
IM/Presence services who only understand single presence indication or use
aggregated presence documents.

For example this would apply to the 'presence enabled' web pages or email
displays, but is also useful when building a gateway between XMPP and, say,

But in all this cases, the 'user' of this indicator would be either a bot or
a gateway. To this day, most XMPP client that I know of do not need this
kind of indicator to display presence, as they have been build from the
ground up to display multiple resources presence.

If, as I say, the 'user' is an automatic process, then using the existing
<priority> associated with a convention is likely to do the trick without
resorting to addition to the protocol. In the case of a 'commercial'
gateway, then it could also be a combination of <priority> and some
proprietary extensions.

Whatever is chosen will require modification at the server level. Now, to
measure the impact on the existing clients, I would really be interested in
knowing how <priority> is used today by a 'real world' client. Would it
really make a difference if the server were to modify the priority?

Lastly, although it may break some existing rules, what if we were to
consider that priority sent by a client as a 'hint' rather than an absolute
value and let the server scale the priority according to its internal rules?

Again, all the interesting discussions about the usefulness of this
extension have not brought a conclusive argument about the need to create a
new protocol extension. I'd modify my opinion once I have heard the client
developers' story about their use of priority.



-----Original Message-----

Message: 9
Date: Fri, 30 Sep 2005 09:51:40 +0200
From: Tomasz Sterna <tomasz.sterna at gmail.com>
Subject: Re: [Standards-JIG] proto-JEP: Flagging the Primary Resource
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <747d68aa0509300051o7713cd5eg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

2005/9/30, Peter Saint-Andre <stpeter at jabber.org>:
> What if the
> resource from which you last received presence is connected to the
> server via an intermittent WAP connection (known to the server but not
> to the subscribers) and the server never considers such a connection to
> be primary because of the connection type?

Does my server really have any clue to decide which of my resources is
a primary one?

Taking your example:
- I have to resources connected. One direct and one WAP.
I see two scenarios:
- I'm sitting at my desk and would like to get messages on my desktop client
- I'm away of my desk doing something and would like to recieve
messages on my mobile

Does my server really is in the position of deciding which resource is
my primary one at the moment?
No. I have to tell it explicitly. And that's what I have priority
attached to presence. Rising my priority while sitting at the desk and
lowering while walking away.

We are spending much time discussing situations when there are many
resources with the same priority. We're creating workarounds, taking
different aproach - show, time, name, etc. when we have a solution
already implemented and deployed. While the reality is that the server
is not in the position, and really has no clue, of deciding where the
user really wants to get messages recieved.
I think the situation, when there are many resources with the same
priority is abnormal and shouldn't happen. "simple clients" - I'm
whole heart for the idea, but let's be real - there has to be at least
some logic there. :-) We cannot workaround all client defeciencies in
the servers.

Another thing - Why would a client be interested which resource is
primary? It just sends a message and the server takes care of the
delivery. Especially with presence of AMP one cannot be sure where the
message will be delivered.
There is only one client I see it be usefull for - presence
indicators. Code needed for tracking user's primary resource, for
display on a web page, is relatively large and complicated, compared
to the one-liner just extracting presence info and storing in the DB.
But is it really worth dumping more XML data into the network just for
some simple bots?

More information about the Standards mailing list