<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 15, 2008, at 7:03 PM, Justin Karneges wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Monday 15 December 2008 15:08:00 Robert Quattlebaum wrote:<br><blockquote type="cite">Presence probes are useful to force a refresh of your presence state<br></blockquote><blockquote type="cite">if you were previously ignoring presence (say, via a privacy list<br></blockquote><blockquote type="cite">which blocks incoming presence).<br></blockquote><br>It should really be the server's job to handle this problem.  As soon as you <br>stop ignoring some presence, a well-designed server should automatically get <br>you that presence.</div></blockquote><div><br></div><div>Is this behavior that you are describing defined anywhere? This sounds like completely new behavior. It also sounds like it would be significantly more work to implement than what I am describing, considering how complex privacy lists are.</div><div><br></div><blockquote type="cite"><div>Today, you generally need to probe contacts that you unblock.  It's nice that <br>this works (as opposed to being SOL), but in my opinion it's a total hack.</div></blockquote><div><br></div><div>Sending a bunch of probes, one for each subscription, sounds like a hack.</div><div>Sending a single probe and letting the server forward that to who you are subscribed to sounds like reasonable behavior, IMHO.</div><div><br></div><div>It seems like we already have the vocabulary for the client to express its needs to the server, we just need the server to know what to do. To do that we need for everyone to generally agree on what should be the correct behavior of the server when it receives an unaddressed presence probe.</div><br><blockquote type="cite"><div><blockquote type="cite">Blocking incoming presence is useful in mobile environments when<br></blockquote><blockquote type="cite">interest in other's presence is only necessary in very limited<br></blockquote><blockquote type="cite">contexts. Receiving  and handling presence stanzas when they aren't<br></blockquote><blockquote type="cite">being used wastes power, so it is a good idea to not have them be sent<br></blockquote><blockquote type="cite">at all. The problem then comes what do you do when you want to<br></blockquote><blockquote type="cite">actually view presence in a roster?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Turning off the privacy list and sending a single presence probe makes<br></blockquote><blockquote type="cite">the most sense, but handling unaddressed presence probes are currently<br></blockquote><blockquote type="cite">not widely supported.<br></blockquote><br>In a perfect world, you'd just turn off the privacy list and be done.  But, in <br>an imperfect one you have to probe all of your contacts.  That, or try <br>rebroadcasting your own presence, which in turn may cause some servers to <br>reprobe.</div></blockquote><div><br></div><div>Rebroadcasting the client's presence doesn't really do what we want in this case. </div><br><blockquote type="cite"><div>I agree there's a problem that needs to be made better.  Let's just do it the <br>right way then.</div></blockquote><div><br></div>The trick is that if we are going to change the behavior, we need it to be simple enough that server implementors will actually consider implementing it.</div><div><br></div><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; "><div style="font-size: 8px; font-family: Helvetica; ">__________________</div><div style="font-size: 24px; color: rgb(51, 51, 51); font-family: Cochin; "><strong style="color: rgb(51, 51, 51); font-family: Cochin; font-size: 24px; font-weight: bold; ">Robert Quattlebaum</strong></div><div style="font-size: 12px; color: rgb(51, 51, 51); font-family: Monaco; ">Jabber: <span style="font-size: 14px; color: rgb(51, 51, 51); font-family: Georgia; "><a href="xmpp:darco@deepdarc.com"><span class="Apple-style-span" style="color: rgb(0, 0, 238); ">darco@deepdarc.com</span></a></span></div><div style="font-size: 12px; color: rgb(51, 51, 51); font-family: Monaco; ">eMail:  <span style="font-size: 14px; color: rgb(51, 51, 51); font-family: Georgia; "><a href="mailto:darco@deepdarc.com"><span class="Apple-style-span" style="color: rgb(0, 0, 238); ">darco@deepdarc.com</span></a></span></div><div style="font-size: 12px; color: rgb(51, 51, 51); font-family: Monaco; ">www:    <span style="font-size: 14px; color: rgb(51, 51, 51); font-family: Georgia; "><span class="Apple-style-span" style="color: rgb(0, 0, 238); "><a href="http://www.deepdarc.com/">http://www.deepdarc.com/</a></span></span></div><div><font class="Apple-style-span" color="#0000EE" face="Georgia" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br class="webkit-block-placeholder"></span></font></div></span></div></div></span><br class="Apple-interchange-newline"> </div><br></body></html>