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 (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). ##
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. ##
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
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". ##
A.3. Server Processing of Inbound Presence Subscription Stanzas
A.3.1.
