Hi, On 13 September 2010 10:32, Iñaki Baz Castillo <[email protected]> wrote: > Hi, I would appreciate clarification about section "3.2.3. Server > Processing of Inbound Subscription Cancellation": > > 2. Initiate a roster push to all of the user's interested resources, > containing an updated roster item for the contact with the > 'subscription' attribute set to a value of "none" (if the > subscription state was "To" or "To + Pending In") or "from" (if > the subscription state was "Both"). > > > So, imagine the case in which Alice was already subscribed to Bob, and > Bob has asked subscription to Alice. In Alice's roster Bob has > "subscription = To + Pending In". Later Bob cancells Alice's > subscription. > > According to step 2 above, Alice's server should set "subscription = > none" for Bob contact. Why? What about the pending incoming > subscription request from Bob to Alice? shouldn't the new state of Bob > in Alice's roster be "none + pending in"? >
Firstly, you're still on the wrong list (discussion about the core specs should be at https://www.ietf.org/mailman/listinfo/xmpp ). Secondly, you're still mixing up the value of the subscription attribute and the subscription state. The subscription attribute is always "none", "to", "from" or "both". It is never anything else. There is also an "ask" attribute, which is only ever the value "subscribe" if set. Combining these attributes, and the same on the contact's side, there are nine possible subscription *states* between two entities. The spec helpfully lists them to make it clear what the values of the attributes should be in each state, and what effect different subscription actions have in each state. So re-read the text again, bearing in mind that "subscription state" does not mean "subscription attribute". The states (and the attributes that would be present in both the user's and the contact's rosters for each) are explained in Appendix A: http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-12#appendix-A Hope this helps, Matthew
