On 4/10/09 8:36 PM, Mridul Muralidharan wrote:
> 
> 
> --- On Sat, 11/4/09, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> 
>> From: Peter Saint-Andre <stpe...@stpeter.im> Subject: Re:
>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>> <standards@xmpp.org> Date: Saturday, 11 April, 2009, 4:04 AM On
>> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
>>> If I recall right, probe can be sent to a full jid in
>> case a directed
>>> presence was received from it in the past - and the
>> behavior would be
>>> different (return last presence stanza sent iirc). Has
>> that behavior
>>> changed or is the description below only for bare
>> jid's ?
>> 
>> You can probe anything you want. :)
> 
> 
> I should have clarified better.
> 
> Assume that there is mutual subscription between userA and userB. 
> Support we have :
> 
> userA has session us...@domain/resA 
> userB has session us...@domain/resB1
> userB has session us...@domain/resB2
> 
> 
> After presence has been exchanged, suppose userA blocks userB (or all
> users) - so an unavailable presence is sent to userB's resources. 
> Subsequent to that, suppose userA sends available to one of the
> resources, say - us...@domain/resB1
> 
> Now, iirc, if resB2 probes, userA's server must return unavailable. 

That seems reasonable.

> But if resB1 probes, userA's server must return the last directed
> presence sent (subsequent to unavailable).

That also seems reasonable.

> We could replace userB with muc or any other component in the above.

Right. The MUC example is more apropos.

> IIRC this was a usecase discussed quite a while back - was it removed
> ? If not, my query was, how does it interact with this list below

We had some text about this in rfc3921bis but IIRC we removed it because
people thought it belonged in XEP-0045 (e.g., an implementation note on
"how to remove ghost users"), not the RFC. However, I think the text
never made it to XEP-0045. I'll check on that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to