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). Peter -- Peter Saint-Andre https://stpeter.im/
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.