[Standards-JIG] Behaviour when sending a message to a negativepriority resource

Clemens Lucas Fries xeno at gmx.at
Thu Sep 14 22:30:05 UTC 2006

May I add this to the discussion:

I came up with the following example when I thought about the impact of
this decision.
Consider a situation where you are in a hurry. You want to drop somebody
a line (via XMPP) but you do not want to receive any pending messages
because you have absolutely no extra time. In this hypothetical
situation one might choose, if given the opportunity, to sign in with a
negative priority to achieve this behaviour.

And of course, I'm guilty of running a bot on the same account I use on
a daily basis. The bot isn't online when I'm offline, though. I use it
to control a remote machine and in case anybody sends it a message, it
archives it.
I chose this constellation solely because it proved convenient to me,
and luckily nobody confused me with the bot so far. I think Joe
Hildebrand is still right when it comes to the big picture - generally
people should consider putting the bot(s) on a different account.

I am not sure if I recall this one correctly, but aren't the different
negative values for the priority reserved for future use?
So, what about a value that implies the current behaviour, as defined in
section 11.1 §4.1 of rfc3921, and some/any other value that defines the
resource as being presence only? (or vice versa for that matter)

This is, in fact, not a very XMLish approach to the problem because you
have somewhat meaningless (negative) values that imply different
behaviour. On the other hand, mostly XMPP-savvy people come up with
programs that use negative priorities (same goes for my example) ;-)


JD Conley wrote:
> Also, from what I remember at the interop event, we decided client software should represent negative priority resources as presence-only resources. Thus the resource is shown as available, but the user cannot send it a message through the user interface.
> -JD

More information about the Standards mailing list