Added two notes to maintain consistency with XEP-0191.
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.
+Note: If a client blocks incoming presence notifications from an entity that has been available before, the user's server SHOULD send unavailable presence to the user on behalf of that contact.
Server-side privacy lists enable a user to block outgoing presence notifications to other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
@@ -618,6 +625,7 @@ ]]>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.
+Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).
Server-side privacy lists enable a user to block incoming IQ stanzas from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
@@ -759,6 +767,15 @@ ]]> +If the user attempts to send an outbound stanza to a contact and that stanza type is blocked, the user's server MUST NOT route the stanza to the contact but instead MUST return a ¬acceptable; error:
+When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.