Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/12/09 1:20 PM, Mridul Muralidharan wrote:
>
>
> --- On Mon, 13/4/09, Peter Saint-Andre wrote:
>
>> From: Peter Saint-Andre Subject: Re:
>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>> 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
>> wrote:
From: Peter Saint-Andre
>> Subject: Re:
[Standards] Inconsistent Subscriptions in XMPP To:
>> "XMPP Standards"
>> 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 ?
People found it confusing and MUC-specific. However, that was for the
full use case. I do think that rfc3921bis needs to say something about
answering probes from entities to which you've sent directed presence,
so that would belong in Section 4.3.2 or Section 4.6.2 of rfc3921bis.
I'll add that to my task list for the RFC revisions.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
--- On Mon, 13/4/09, Peter Saint-Andre wrote:
> From: Peter Saint-Andre
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards"
> 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
> wrote:
> >
> >> From: Peter Saint-Andre
> Subject: Re:
> >> [Standards] Inconsistent Subscriptions in XMPP To:
> "XMPP Standards"
> >>
> 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/
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/10/09 8:36 PM, Mridul Muralidharan wrote: > > > --- On Sat, 11/4/09, Peter Saint-Andre wrote: > >> From: Peter Saint-Andre Subject: Re: >> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards" >> 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/ smime.p7s Description: S/MIME Cryptographic Signature
