-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/12/09 1:25 PM, Peter Saint-Andre wrote: > On 4/12/09 1:20 PM, Mridul Muralidharan wrote: >> >> --- 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 ? > > 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.
Done in my working copy. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkokTKYACgkQNL8k5A2w/vyEvgCdGUh+MxaaxkDCq4G7yA0W6sIP zgEAn0NOBNaL3GwzQqfhhDv1TtP4+rfG =8Fni -----END PGP SIGNATURE-----
