Subject: [xmpp] Roster push on subscription request denial

From: Matthew Wild <[email-masked]>
Date: Tue, 24 May 2011 14:10:57 +0100

Hi,

Someone noticed recently an oddity when cancelling a subscription
request in Prosody (I haven't investigated other servers).

Flow:
  - Contact sends subscription request
  - User sends <presence type="unsubscribed"/> to deny
  - Prosody sends roster push to user with subscription='remove'

This last step is somewhat counter-intuitive - the contact was never
in the user's roster as far as the client was concerned.

However the roster push is required by the spec:

"Otherwise, as shown in the following examples, the contact's server
MUST route or deliver both presence notifications of type
"unavailable" and presence stanzas of type "unsubscribed" to the user
and MUST send a roster push to the contact."

Thoughts?

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 May 2011 10:41:45 -0600

> and MUST send a roster push to the contact."

Your quote is missing some context. The text in Section 3.2.2 reads:

###

   Upon receiving the outbound subscription cancellation, the contact's
   server MUST proceed as follows.

   1.  If the user's bare JID is not yet in the contact's roster or is
       in the contact's roster with a state of "None", "None + Pending
       Out", or "To", the contact's server SHOULD NOT route or deliver
       the presence stanza of type "unsubscribed" to the user and MUST
       NOT send presence notifications of type "unavailable" to the user
       as described below.

   2.  If the user's bare JID is in the contact's roster with a state of
       "None", "None + Pending Out", or "To" and the 'approved' flag is
       set to "true" (thus signaling a subscription pre-approval as
       described under Section 3.4), the contact's server MUST remove
       the pre-approval and MUST NOT route or deliver the presence
       stanza of type "unsubscribed" to the user.

   3.  Otherwise, as shown in the following examples, the contact's
       server MUST route or deliver both presence notifications of type
       "unavailable" and presence stanzas of type "unsubscribed" to the
       user and MUST send a roster push to the contact.

###

The case you're talking about fits #1 because the user is not yet in the
contact's roster. However, the spec might have a different bug here,
because it says that the contact's server SHOULD NOT route the
"unsubscribed" to the user. Yet that would prevent the contact's server
from informing the user that the contact has denied the subscription
request (a kind of "polite denial"). That seems wrong -- I think it
needs to say "SHOULD" instead of "SHOULD NOT". Thus 6121bis (shudder)
would say:

   1.  If the user's bare JID is not yet in the contact's roster or is
       in the contact's roster with a state of "None", the contact's
       server SHOULD route or deliver the presence stanza of type
       "unsubscribed" to the user, MUST NOT send presence notifications
       of type "unavailable" to the user as described below, and MUST
       NOT send a roster push as described below.

We'd then need to define #1b that covers the "None + Pending Out" and
"To" cases (send the "unsubscribed", don't send the "unavailable", send
the roster push).

Or so it seems to me. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 May 2011 11:35:59 -0600

> "To" cases (send the "unsubscribed", don't send the "unavailable", send

For further corroboration, see Section 8.2.1 of RFC 3921:

###

8.2.1.  Alternate Flow: Contact Declines Subscription Request

   The above activity flow represents the "happy path" regarding the
   user's subscription request to the contact.  The main alternate flow
   occurs if the contact refuses the user's subscription request, as
   described below.

   1.  If the contact wants to refuse the request, the contact's client
       MUST send a presence stanza of type "unsubscribed" to the user
       (instead of the presence stanza of type "subscribed" sent in Step
       6 of Section 8.2):

   <presence to=[email-masked]' type='unsubscribed'/>

   2.  As a result, the contact's server MUST route the presence stanza
       of type "unsubscribed" to the user, first stamping the 'from'
       address as the bare JID (<[email-masked]>) of the contact:

   <presence
       from=[email-masked]'
       to=[email-masked]'
       type='unsubscribed'/>

   Note: If the contact's server previously added the user to the
   contact's roster for tracking purposes, it MUST remove the relevant
   item at this time.

###

So I think the spec author goofed here. I'll work on suitable text for
an erratum.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/