--- On Mon, 13/4/09, Peter Saint-Andre <[email protected]> wrote:

> From: Peter Saint-Andre <[email protected]>
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards" <[email protected]>
> Date: Monday, 13 April, 2009, 12:45 AM
> On 4/10/09 8:36 PM, Mridul
> Muralidharan wrote:
> > 
> > 
> > --- On Sat, 11/4/09, Peter Saint-Andre <[email protected]>
> wrote:
> > 
> >> From: Peter Saint-Andre <[email protected]>
> Subject: Re:
> >> [Standards] Inconsistent Subscriptions in XMPP To:
> "XMPP Standards"
> >> <[email protected]>
> 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.


Shouldn't this not be part of the CORE xmpp spec ?
Privacy enforcement, routing decisions, presence management happen within the 
server - and only server has visibility of the user's stanza history to support 
this imo - so, if required, wouldn't it not be for the server to handle it ? 
('it' being responding to probe with previous presence stanza in case of 
directed presence - or maybe this is already there and I just did not see it ?).

A quick search did not reveal much on discussion about this - any overriding 
reason why this was pulled out ?


Thanks,
Mridul

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


      Add more friends to your messenger and enjoy! Go to 
http://messenger.yahoo.com/invite/

Reply via email to