--- 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/