[Standards] RFC 6121 ambiguous stanza processing rules

Christian Schudt christian.schudt at gmx.de
Fri May 1 16:32:39 UTC 2020


Hi,

I have difficulties understanding the correct server side processing of inbound „unsubscribe“ and „unsubscribed" presence, because RFC 6121 is ambiguous here:

-----
§ 3.3.3.  Server Processing of Inbound Unsubscribe

MUST first check if the user's bare JID is in the contact's roster with subscription='from' or subscription='both' (i.e., a subscription state of "From", "From + Pending Out", or "Both“)
[…]
Otherwise —[…] if the user's bare JID is in the contact's roster with a subscription state other than those described in the foregoing check -- then the contact's server MUST silently ignore the unsubscribe stanza by not delivering it to the contact, not modifying the contact's roster, and not generating a roster push to the contact's interested resources.
----

This text implies that if the subscription state is „To“ or „None", the unsubscribe presence MUST NOT be delivered.



However, later in Appendix "A.3.2.  Unsubscribe" it says:

----
"None + Pending In"     |  MUST [1]  |  "None"                  |
"None + Pending Out+In" |  MUST [1]  |  "None + Pending Out"
"To + Pending In"       |  MUST [1]  |  "To“ 
——


(I think in this case presence MUST NOT be delivered, because removing the „Pending In“ substate should not trigger as roster push (as nothing has changed from client perspective).


There is similar ambiguous text in:

3.2.3.  Server Processing of Inbound Subscription Cancellation (deliver only if „To“ or „Both“)
vs.
A.3.4.  Unsubscribed (deliver on more states)
(Appendix seems right, text not)


Any ideas? Is the specification indeed unclear?
Should subscription presence only be delivered if it is followed by a roster push?


Kind regards,
Christian



More information about the Standards mailing list