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

Ralph Meijer jabber.org at ralphm.ik.nu
Fri Sep 30 15:47:40 UTC 2005

On Fri, Sep 30, 2005 at 04:02:54PM +0200, Jean-Louis Seguineau wrote:
> 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.

Yes, and they have to guess the exact algorithm used by the server to
determine the primary resource that is used when message are sent to the
bare JID of the contact in question. Sure, it mostly works, but as
someone pointed out, some clients don't even let the user change their
priority themselves.

Example in case: gossip. It changes the priority based on 'show' values.
This usually works nicely but it is easier to get into corner cases
where the priority of different resources is identical. The rules beyond
the use of priority to determine the primary resource is not fixed. I
believe jabberd 1.x uses the clients connect time (v.s. sending of
presence which is different when you use the non-xmpp compliant presence
type 'invisible'). Other servers might do it slightly different.

Having this extra element clearly gives the server's idea of the primary
resource, without changing the meaning of existing protocol. Nothing
that doesn't understand the addition will break.

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

I rather have some standard protocol that is used by commercial
entities. Like waiting lists, for example.

> 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?

The impact to existing implementations that don't understand the new
protocol, the impact is zero. I do think that client implementations
would become simpler if we'd have this used throughout, but I don't see
that happening any time soon.

> 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?

I'm not out on this yet. It's an interesting approach, though.

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

If I understand correctly, the authors have determined there is a need
for this, at least in some commercial deployments. Again, I'm all for
making a standard out of it instead of having custom stuff that doesn't
interoperate. On top of that is my impression that it is useful for the
general community as well.



More information about the Standards mailing list