[Standards] Inconsistent Subscriptions in XMPP

Peter Saint-Andre stpeter at stpeter.im
Mon Jun 1 21:48:22 UTC 2009


-----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 <stpeter at stpeter.im> wrote:
>>
>>> From: Peter Saint-Andre <stpeter at stpeter.im> Subject: Re:
>>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>>> <standards at xmpp.org> 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 <stpeter at stpeter.im>
>>> wrote:
>>>>> From: Peter Saint-Andre <stpeter at stpeter.im>
>>> Subject: Re:
>>>>> [Standards] Inconsistent Subscriptions in XMPP To:
>>> "XMPP Standards"
>>>>> <standards at 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 userA at domain/resA userB has session
>>>> userB at domain/resB1 userB has session userB at 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 - userB at 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-----



More information about the Standards mailing list