As mentioned, one small aspect of rfc3921bis-04 requires comment... The basic idea is that you might want to "pre-approve" a contact's subscription request, so that if they send you a subscription request you never have to see it. This use case is handled somehow in SIP/SIMPLE so it would be nice to support it in XMPP also. The user could do this by sending <presence type='subscribed'/> (with or without roster set) and the user's server would keep track of this via a new value of the 'ask' attribute, namely ask='subscribed'.
So here is revised text from the spec, with comments.... ****** 3.1.3. Server Processing of Inbound Subscription Request The contact's server MUST adhere to the following rules when processing the inbound subscription request: 1. Above all, the contact's server MUST NOT automatically approve subscription requests on the contact's behalf; instead, if a subscription request requires approval then the contact's server MUST deliver that request to the contact's interested resource(s) for approval or denial by the contact. ## COMMENT: we treat ask='subscribed' as a condition under which a subscription request does not require explicit approval by the contact (since the contact already pre-approved the user's subscription). ## <snip/> 3. If the contact exists and the user already has a subscription to the user's presence, then the contact's server SHOULD auto-reply on behalf of the contact by sending a presence stanza of type "subscribed" from the contact's bare JID to the user's bare JID. If the contact previously sent a presence stanza of type "subscribed" and the contact's server treated that as indicating "pre-approval" for the user's presence subscription (see Appendix A), then the contact's server MAY also auto-reply on behalf of the contact. ## COMMENT: the second sentence is added here to handle the pre-approval case. ## <snip/> Appendix A. Subscription States This section provides detailed information about subscription states and server processing of subscription-related presence stanzas (i.e., presence stanzas of type "subscribe", "subscribed", "unsubscribe", and "unsubscribed"). ## COMMENT: Note that all of the following states and tables are described from the perspective of the user, not the contact!!! ## A.2. Server Processing of Outbound Presence Subscription Stanzas <snip/> A.2.3. Subscribed Table 3: Processing of outbound "subscribed" stanzas +-----------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +-----------------------------------------------------------------+ | "None" | S.N. | no state change [1] | | "None + Pending Out" | S.N. | no state change | | "None + Pending In" | MUST | "From" | | "None + Pending Out+In" | MUST | "From + Pending Out" | | "To" | S.N. | no state change | | "To + Pending In" | MUST | "Both" | | "From" | S.N. | no state change | | "From + Pending Out" | S.N. | no state change | | "Both" | S.N. | no state change | +-----------------------------------------------------------------+ [1] A server MAY note the fact that the user wishes to allow the contact to be subscribed to the user's presence and automatically approve any subscription request received from the contact; if it does so, upon receiving the presence stanza of type "subscribed" from the user's client it MUST add a roster item for the contact to the user's roster and set the 'ask' flag to a value of "subscribed". However, the user's server still SHOULD NOT route the presence stanza of type "subscribed" to the contact. This optional functionality applies only if the contact is not already in the user's roster or if the contact is in the user's roster with a state of "None" (not including a state of "None + Pending Out"). ## COMMENT: this gets a bit tricky because we can't have both ask='subscribe' and ask='subscribed' (unless we're going to allow ask='subscribe subscribed' a la HTML attribute values, which I think is problematic). So the pre-approval will be set only if the contact is not already in the user's roster. A more complex rule would be to allow ask='subscribed' for all subscription states that don't involve "pending out" (e.g., the user could have a subscription to the contact's presence but still flag the contact as pre-approved). In other words, under the more complex model ask='subscribe' always trumps ask='subscribed' for the roster settings, but once the contact approves the user's outbound presence subscription request then the server could set ask='subscribed' again. But I think it is simpler to do this only if the user does not have an outbound subscription request -- this is a kind of "standing pre-approval". ## <snip/> A.3. Server Processing of Inbound Presence Subscription Stanzas A.3.1. Subscribe Table 5: Processing of inbound "subscribe" stanzas +------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | MUST [1] | "None + Pending In" | | "None + Pending Out" | MUST | "None + Pending Out+In" | | "None + Pending In" | S.N. | no state change | | "None + Pending Out+In" | S.N. | no state change | | "To" | MUST | "To + Pending In" | | "To + Pending In" | S.N. | no state change | | "From" | S.N. [2] | no state change | | "From + Pending Out" | S.N. [2] | no state change | | "Both" | S.N. [2] | no state change | +------------------------------------------------------------------+ [1] If the user previously sent presence of type "subscribed" as described under Appendix A.2.3, then the server MAY auto-reply with "subscribed" and change the state to "From" rather than "None + Pending In". [2] Server SHOULD auto-reply with "subscribed". ## COMMENT: Footnote [1] here is the flip side -- how the user's server shall handle an inbound "subscribe" from the contact if the user pre-approved the contact's presence subscription. ## ****** Thoughts? /psa
smime.p7s
Description: S/MIME Cryptographic Signature
