Re: [Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2
Sorry about the delayed reply... On 11/15/11 11:22 AM, Dave Richards wrote: > Am I missing something or is there a bit of a hole in these sections > regarding denying a subscription? > > In 3.1.2 (subscription request outbound), the user's server pushes a > roster entry containing "the potential contact with a subscription state > of "none" and with notation that the subscription is pending". > > In 3.2.3 (subscription cancellation inbound), the user's server is > supposed to ignore the subscription cancellation unless "the contact is > in the user's roster with subscription='to' or subscription='both'" And > a few lines later: "Otherwise ... if the contact is in the user's > roster with a subscription state other than those described in the > foregoing check -- then the user's server MUST silently ignore the > unsubscribed notification by not delivering it to the user, not > modifying the user's roster, and not generating a roster push to the > user's interested resources". > > Seems like a subscription denial/rejection would never get processed on > the user side. > > 3.1.6 (subscription approval inbound) talks about subscription none/from > with pending out, which seems should also be considered in 3.2.3. That does seem to be a bit a hole -- Section 3.2.3 should say mention the outbound pending case. I've made a note to fix that in 6121bis. > In an unrelated issue, 4.3.2, #1 says to send "unsubscribed" if "the > contact account does not exist or the user's bare JID is in the > contact's roster with a subscription state other than "From", "From + > Pending Out", or "Both"". Seems like this should also be the case if > the contact account exists but is not in the user's roster at all. All > other roster states are covered by available/unavailable, so it seems > lack of a response would indicate that the account at least exists, > which might be considered leaking information, as well as leaving the > user with apparently a dead "to" subscription to the contact. We kind of assume that not being in the roster is equivalent to being in the roster with a subscription state of "None", but you're right that this too could use with some clarification in 6121bis. Thanks for the feedback! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2
I'm at the IETF meeting in Taipei this week so I don't have time to look into this, but I might have time on the plane home Saturday, or for sure early next week. On 11/16/11 2:22 AM, Dave Richards wrote: > Am I missing something or is there a bit of a hole in these sections > regarding denying a subscription? > > In 3.1.2 (subscription request outbound), the user's server pushes a > roster entry containing "the potential contact with a subscription state > of "none" and with notation that the subscription is pending". > > In 3.2.3 (subscription cancellation inbound), the user's server is > supposed to ignore the subscription cancellation unless "the contact is > in the user's roster with subscription='to' or subscription='both'" And > a few lines later: "Otherwise ... if the contact is in the user's > roster with a subscription state other than those described in the > foregoing check -- then the user's server MUST silently ignore the > unsubscribed notification by not delivering it to the user, not > modifying the user's roster, and not generating a roster push to the > user's interested resources". > > Seems like a subscription denial/rejection would never get processed on > the user side. > > 3.1.6 (subscription approval inbound) talks about subscription none/from > with pending out, which seems should also be considered in 3.2.3. > > > In an unrelated issue, 4.3.2, #1 says to send "unsubscribed" if "the > contact account does not exist or the user's bare JID is in the > contact's roster with a subscription state other than "From", "From + > Pending Out", or "Both"". Seems like this should also be the case if > the contact account exists but is not in the user's roster at all. All > other roster states are covered by available/unavailable, so it seems > lack of a response would indicate that the account at least exists, > which might be considered leaking information, as well as leaving the > user with apparently a dead "to" subscription to the contact. > > > After a brief look I did not find any previous discussion of these, so > if there is can someone please point me there? If not, what do you think? > > > Thanks, > > Dave Richards
Re: [Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2
On 11/15/2011 10:22 AM, Dave Richards wrote: Am I missing something or is there a bit of a hole in these sections regarding denying a subscription? In 3.1.2 (subscription request outbound), the user's server pushes a roster entry containing "the potential contact with a subscription state of "none" and with notation that the subscription is pending". In 3.2.3 (subscription cancellation inbound), the user's server is supposed to ignore the subscription cancellation unless "the contact is in the user's roster with subscription='to' or subscription='both'" And a few lines later: "Otherwise ... if the contact is in the user's roster with a subscription state other than those described in the foregoing check -- then the user's server MUST silently ignore the unsubscribed notification by not delivering it to the user, not modifying the user's roster, and not generating a roster push to the user's interested resources". Seems like a subscription denial/rejection would never get processed on the user side. 3.1.6 (subscription approval inbound) talks about subscription none/from with pending out, which seems should also be considered in 3.2.3. In an unrelated issue, 4.3.2, #1 says to send "unsubscribed" if "the contact account does not exist or the user's bare JID is in the contact's roster with a subscription state other than "From", "From + Pending Out", or "Both"". Seems like this should also be the case if the contact account exists but is not in the user's roster at all. All other roster states are covered by available/unavailable, so it seems lack of a response would indicate that the account at least exists, which might be considered leaking information, as well as leaving the user with apparently a dead "to" subscription to the contact. After a brief look I did not find any previous discussion of these, so if there is can someone please point me there? If not, what do you think? Thanks, Dave Richards You do seem to have a point there. From my understanding, there would be no unsubscribed presence stanza since the user never had an outbound subscription, only a pending request for an outbound subscription. However, there would have to be a roster push to all interested resources, since the roster state would change - specifically the ask='subscribe' attribute would be removed, although the subscription attribute would be 'none' both before and after the roster push. Mike
[Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2
Am I missing something or is there a bit of a hole in these sections regarding denying a subscription? In 3.1.2 (subscription request outbound), the user's server pushes a roster entry containing "the potential contact with a subscription state of "none" and with notation that the subscription is pending". In 3.2.3 (subscription cancellation inbound), the user's server is supposed to ignore the subscription cancellation unless "the contact is in the user's roster with subscription='to' or subscription='both'" And a few lines later: "Otherwise ... if the contact is in the user's roster with a subscription state other than those described in the foregoing check -- then the user's server MUST silently ignore the unsubscribed notification by not delivering it to the user, not modifying the user's roster, and not generating a roster push to the user's interested resources". Seems like a subscription denial/rejection would never get processed on the user side. 3.1.6 (subscription approval inbound) talks about subscription none/from with pending out, which seems should also be considered in 3.2.3. In an unrelated issue, 4.3.2, #1 says to send "unsubscribed" if "the contact account does not exist or the user's bare JID is in the contact's roster with a subscription state other than "From", "From + Pending Out", or "Both"". Seems like this should also be the case if the contact account exists but is not in the user's roster at all. All other roster states are covered by available/unavailable, so it seems lack of a response would indicate that the account at least exists, which might be considered leaking information, as well as leaving the user with apparently a dead "to" subscription to the contact. After a brief look I did not find any previous discussion of these, so if there is can someone please point me there? If not, what do you think? Thanks, Dave Richards
