On 2/2/10 7:17 AM, Jiří Zárevúcky wrote: > Justin Karneges píše v Po 01. 02. 2010 v 16:48 -0800: >> On Monday 01 February 2010 13:31:18 Peter Saint-Andre wrote: >>> On 2/1/10 2:09 PM, Peter Saint-Andre wrote: >>>> On 2/1/10 12:56 PM, Ben Schumacher wrote: >>>>> On 02/01/2010 12:29 PM, Justin Karneges wrote: >>>>>> Basically, the server should return the most recently sent presence to >>>>>> the JID >>>>>> doing the probing, whether directed or undirected. So, no, if you >>>>>> send me >>>>>> directed presence and then I probe you, I would not expect to receive >>>>>> your "real" (undirected) presence. >>>>> >>>>> Therein lies the rub. I do not want to have to shove ever presence sent >>>>> into a DB, DHT, whatever to meet these requirements. Hence the point of >>>>> the recommendation re: probe + unavailable. >>>> >>>> Yes, that seems onerous. >>>> >>>> Currently, the server needs to keep track of whether another entity is >>>> on the list for receiving unavailable presence for a given resource. The >>>> server will remove an entity from that list if the user sends directed >>>> unavailable presence to the entity. So the server knows if it can send >>>> <presence/> (no details like show or status or priority) to an entity, >>>> and perhaps that is the best thing for it to return to the entity if it >>>> probes the full JID. >>> >>> How is this text? >>> >>> If the contact's server receives a presence probe addressed to a full >>> JID of the contact, the server MUST NOT return presence information >>> about any resource except the resource specified by the 'to' address >>> of the probe. Rules #1 and #2 for a bare JID probe apply equally to >>> the case of a full JID probe. If there is a resource matching the >>> full JID and (a) the probing entity has authorization via a presence >>> subscription to see the contact's presence or (b) the contact has >>> sent directed available presence to the probing entity, then the >>> server MUST return an available presence notification, which SHOULD >>> communicate only the fact that the resource is available (not >>> detailed information such as the <show/>, <status/>, <priority/>, or >>> presence extensions). >> >> Hmm, I'm okay with where you're going with this, but it is strange that the >> presence returned here has a different meaning than it would in normal >> circumstances. I'm imagining a race condition where someone updates their >> directed presence to you right as you perform a probe on them. Now when you >> receive their presence, you'll think it is a reply to the probe, meaning that >> the user is still online but you'll otherwise discard the details of the >> presence packet. Then the probe is received by the contact's server and >> processed, and an empty presence is returned back to you, which you'd then >> process as a typical directed presence update. Oops. >> >> [...] > > What about using the 'id' attribute? The spec should perhaps say that if > probe has an id set, response to that probe should mirror it. Presence probes are not IQs. :) If I probe for your presence, wouldn't I get back your latest presence with whatever ID you included in your presence broadcast? Juliet: <presence id='foo'/> Romeo: <presence id='bar' to='juliet'/> Juliet: <presence from='juliet' to='romeo' id='foo'/> /psa
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.