Hi Theo, On 22 September 2010 15:21, Theo Cushion <[email protected]> wrote: > Hi > Can anyone clarify how shared rosters are supposed to work. I've been > looking > at http://xmpp.org/rfcs/rfc3921.html#roster and http://xmpp.org/rfcs/rfc3921.html#rfc.section.5.1.2 but > still have some questions.
Firstly... shared rosters are unrelated to XMPP the protocol. XMPP defines rosters, which are a simple list of contacts. Such contacts may be in any number of roster groups, etc. What is known as "shared rosters" is a feature supported by many of the servers that allows you to have the server automatically and dynamically generate a roster based on group memberships defined by the server admin. For example everyone in the "admin" group seeing everyone else in the "admin" group, or the "admin" group being included in the roster of every user on the server. Again, XMPP describes none of this... servers are free to handle it how they will, XMPP is just the protocol used to convey information to the client and contacts. > Section 7.1 states that if a roster is received with the subscription > attributes for a contact set to both then "both the user and the contact > have subscriptions to each other's presence information". > However, looking at 5.1.2 about presence broadcast it states: > > If the presence stanza lacks a 'type' attribute (i.e., expresses > availability), the user's server MUST broadcast the full XML of that > presence stanza to all contacts (1) that are in the user's roster with a > subscription type of "from" or "both", (2) to whom the user has not blocked > outbound presence notifications, and (3) from whom the server has not > received a presence error during the user's session (as well as to any of > the user's other available resources). > > The scenario I am unsure about is as follows: > - User A is part of roster group "Admin" > - User B is part of roster group "Admin" > - User C is not part of any roster group, but gets sent the roster group I'm not sure why User C would necessarily see the Admin group if they were not a member of it. Your server may have the concept of a group appearing to all users, it is then up to the server to ensure that the roster is formatted accordingly (it would generally be subscription="to" for User C then) and that presence broadcasts get sent to the right places. > "Admin" - with all contacts subscription attribute set to both > So I understand that A can see B and B can see A due to - '(1) that are in > the user's roster with a subscription type of "from" or "both"' > However, should C receive A and B's presence? A and B do not have C in their > roster - so do not pass the condition '(1) that are in the user's roster > with a subscription type of "from" or "both"', but does section 7.1 override > this requirement? If User 1 has User 2 in their roster with subscription="to" or "both" then in a working server User 1 would also be in User 2's roster with subscription="from" or "both" respectively. Of course internally a server may choose to hide a "weak" subscription (ie. one via a shared roster) from User 2 to prevent User 2 from seeing everyone on the server in their client - this is what we (are attempting to) do in Prosody. Implementing this kind of shared roster well is extremely complicated, and we're in the process of reworking Prosody's roster handling code to allow fancy things like this to work efficiently. Again it's important to note that XMPP is a protocol, and describes how clients and servers talk to each other. There is nothing that prevents clients or servers from being smart within the realm of this protocol - which is exactly how shared rosters are achieved. That said, you'll find the specifications tend to assume the common case of two normal contacts since this greatly simplifies the description of the protocol. Hope this helps, Matthew
