<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:235366245;
        mso-list-type:hybrid;
        mso-list-template-ids:-1746770830 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>This has been brought up before, but didn’t find any definitive
answers with a search. What should we do about presence priorities in desktop XMPP
instant messaging applications? Managing priority is fairly straightforward
when you control all client implementations used by a bare JID, but in a
heterogeneous client environment it is more difficult as each developer chooses
his/her own path and only learns by spying on what others do. I think presence
priority is something that should be covered in the implementation guide so the
actual values become more uniform on the network. We currently do pretty basic
priority management, but I have some thoughts on a better implementation I hope
others implementations might help refine.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>Priority is typically used by both clients and servers to
determine which resource is most likely to be the one you want to interact with.
This could be for routing messages sent to bare JID’s, or deciding which
presence status to display in a contact list. So, after much deep thought and
implementation trial/error, here is my proposal.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>Unless a user explicitly specifies she does not want to
receive any messages, never set the priority below 0.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>In desktop software, presence priority is based first on user
input activity. It is more likely that if a user is active, she will be there
to respond to a message, regardless of the presence status that is set in the
client software. The actual times may vary based on implementation, but the
general idea is to have four base values:<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>User input idle less than 1 minute: 100<o:p></o:p></p>

<p class=MsoNormal>User input idle more than 1 minute: 80<o:p></o:p></p>

<p class=MsoNormal>User input idle more than 5 minutes: 60<o:p></o:p></p>

<p class=MsoNormal>User input idle more than 30 minutes: 40<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>When these idle thresholds are met, presence should be broadcast.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>The current show value is then applied.<o:p></o:p></p>

<p class=MsoNormal>chat: -4<o:p></o:p></p>

<p class=MsoNormal>none (normal/available): -4<o:p></o:p></p>

<p class=MsoNormal>dnd: -4<o:p></o:p></p>

<p class=MsoNormal>away: -8<o:p></o:p></p>

<p class=MsoNormal>xa: -12<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>Thus, if a user has been idle for more than 30 minutes and
has a status of “xa”, her priority is 28 (40-12). If a user has
been idle for more than 30 minutes and has a status of “away” her
priority is 32 (40-8).<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>By starting at a high number and leaving padding between
each show value, we leave room for implementations to add additional rules to
adjust priority. Dnd has a higher priority than away and xa because, although the
user does not want to be disturbed they are more likely to be at the dnd resource
than the away or xa resource. It is up to the client implementation to insure
they are not disturbed per the user’s configuration. A show of dnd uses
the same priority as none and chat since you are likely equally available, you
just don’t want to be disturbed.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>Priority and, optionally, show values are adjusted automatically
based on common “away from the computer” events: system input
idleness (how long since the user interacted with the system), when a session is
locked, or a session screen saver is active. When these events occur, the
priority rules must be processed again. For Example, my client is configured to
go to a show of away after 5 minutes with a status of “AFK”. After
30 minutes it is set to a show value of xa and a status of “AFK for a
long time”. When my system is locked or the screen saver comes on, my
client automatically adjusts my show value to away and a status of “Not
here”. Important: even if an implementation does not change status
messages or show values after these “away from the computer” events
it must still adjust its priority as defined above.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>After the “away from the computer” rules are
processed, the relative availability of your peer resources is taken into
account. If any peer was more recently more available (had a more available show
value than your current value – chat, none/dnd, away, then xa) and has a non-negative
priority, subtract 20 from your current priority. For example: I’m logged
in at home and work. At home I last announced available presence 4 hours ago. My
software at home never puts me into “xa” and instead decides I am “away”
after 30 minutes. Home priority is now 32 (40-8). At work I last announced
available presence 3 hours ago with a “none” show value. I go to lunch
at work but it is configured to reach a show value of xa after 30 minutes. Its
priority is now 28 (40-12). However, since work was my last active resource, when
my home resource receives the broadcast from work it adjusts itself to a
presence priority of 12 (32-20). The purpose of this is to insure that only the
most recently available resource above more available than away/xa is the one
that takes the higher priority.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>It is important to never adjust your priority relative to
the priority of a peer resource without taking much care. Doing so  can
cause a “race” for the highest or lowest priority (depending on the
relative direction your adjusting).<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>-JD<o:p></o:p></p>

</div>

</body>

</html>