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

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Sep 28 02:16:38 CDT 2005


On Tue, Sep 27, 2005 at 10:24:16PM +0200, Jean-Louis Seguineau wrote:
> IMHO the document falls a little short explaining what the goal behind =
the
> proposal is...
>=20
> Could the author(s) elaborate on the usage of this extension (Use cases=
 are
> always welcomed by the community). What is the definition of a 'primary=
'
> resource? In what way would this 'primary' resource be used?
>=20
> As another post said, we already have a priority mechanism in the serve=
r. How
> is this going to be different? Couldn't we adapt the priority mechanism=
 to
> achieve the same results?

Indeed. RFC 3920 gives some guidelines in how you a server may decide
which resource to send a message that was sent to the bare JID. Most
implementations use priority, show and login time for this, but every
implementation is free to decide on a particular algorithm.

IMO, the value of this proposal is in exposing the algorithm that is
used by the server to determine the primary resource, by flagging the
actual resource that is considered primary.

So, at every presence the server receives from you, it determines the
primary resource and then multicasts your presence, possibly with the
primary flag set. If the primary resource changes because of a received
presence, the 'old' primary resource's presence will be resent without
the primary flag set.

So, why would you want this? For sending messages, the preferred method
is to still send the message to the bare JID. The added value is for
example in showing the primary resource's presence in client.

Without this proposal, every client has to guess which of the received
presences from a particular entity would be considered to represent the
primary resource. And the algorithm the client uses may differ from the
actual implementation in the server. This results in clients showing a
certain resource as primary while the server thinks differently when
sending a message to bare JID.

For my news bot, that is part of Mim=C3=ADr, I had to implement such an
algorithm, too. Not to show presence, but to determine when a reminder
of waiting news could be sent. Such a notification will be sent at a
presence change that makes the primary resource eligable for receiving
the notification. This proposal would greatly simplify the
implementation.

I believe JEP-0152 (Reachability Addresses) is complementary to this
proposal, since the reachability is client generated information.

--=20
Groetjes,

ralphm



More information about the Standards-JIG mailing list