[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmpp] 3921bis: probe to full JID?



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.