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
[Standards] XEP-0115 Feedback
(1) In 5.4. Processing Method, step 3.3 states, "If the response includes more than one service discovery identity with the same category/type/lang/name, consider the entire response to be ill-formed." Should that actually be category/type/lang instead? XEP-0030 states, "the element MUST NOT include multiple elements with the same category+type+xml:lang but with different 'name' values." Thus, the only change here would be that XEP-0115 disallows results which are already disallowed by XEP-0030. (2) We may want to put a cautionary note in XEP-0128 about what should or should not be included as an extension. For example, if a client included a public encryption key in a disco#info response via service discovery extensions, and this key was different for each user (or resource), then every user would publish a different verification string, meaning that entity capabilities would perform no better than disco flooding for that given client. If all users of a client would coalesce around a small subset of all possible values for any extensions added, then entity capabilities would still work as designed. However, I would argue IMHO that clients SHOULD NOT (or maybe even MUST NOT) introduce new information via service discovery extensions that would likely be different for each user or resource. I'll save a longer rant about the tendency for developers to say, "Let's make XYZ extensible!" without considering, for example, the performance and/or security implications of such extensibility. This isn't the first context where I've seen extensibility potentially cause such issues, nor am I the first person to have such complaints :)
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
