privacy list
Click on the red underlined text to get to the source
... by the server from each of the contact's available
resources (again, subject to privacy lists in force for each
session).
...
... XML of that presence stanza (subject to privacy lists) but
SHOULD NOT otherwise modify the contact's status regarding
presence broadcast ...
... by the
server from each of the user's available resources (subject to
privacy lists in force for each session):
...
... IMP-REQS]). In XMPP this is done by managing one's
privacy lists using the 'jabber:iq:privacy' namespace ...
...
Server-side privacy lists enable successful completion of the
following use cases:
...
... following use cases:
o Retrieving one's privacy lists.
o Adding, removing ...
...
o Adding, removing, and editing one's privacy lists.
o Setting, changing, or declining active lists ...
...
A user MAY define one or more privacy lists, which are stored by the
user's server. Each <list/> element contains one or more rules in
...
...
When a client adds or updates a privacy list, the <list/> element
SHOULD contain at least one <item/> child element ...
... client
removes a privacy list, the <list/> element MUST NOT contain any
<item/> child elements ...
...
When a client updates a privacy list, it must include all of the
desired items (i.e., not a "delta").
...
... XML Stanzas (Section 11).
4. Privacy lists MUST be the first delivery rule applied by a
server, superseding (1) the routing ...
... 8).
5. The order in which privacy list items are processed by the server
is important. List items MUST be processed in ascending order
...
...
6. As soon as a stanza is matched against a privacy list rule, the
server MUST appropriately handle the stanza in accordance with
...
... element with only one <list/> child element, where the
'name' attribute is set to the name of the modified privacy list.
These "privacy list pushes" adhere to the same semantics ...
... 'name' attribute is set to the name of the modified privacy list.
These "privacy list pushes" adhere to the same semantics as the
"roster pushes" used in roster management ...
... Retrieving One's Privacy Lists ...
...
Example: Client requests names of privacy lists from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist1'>
...
...
Example: Client requests a privacy list from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist2'>
...
... </iq>
Example: Server sends a privacy list to client:
...
...
Example: Client requests another privacy list from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist3'>
...
... </iq>
Example: Server sends another privacy list to client:
...
...
Example: Client requests yet another privacy list from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist4'>
...
... </iq>
Example: Server sends yet another privacy list to client:
...
... Editing a Privacy List ...
...
In order to edit a privacy list, the user MUST send an IQ stanza of
type "set" with a <query ...
...
Example: Client edits a privacy list:
<iq from='romeo@example.net/orchard' type='set' id='edit1'>
...
... relevant items before submitting the list to the server.
The server MUST now send a "privacy list push" to all connected
resources:
...
... resources:
Example: Privacy list push on list edit:
<iq to='romeo@example.net/orchard' type='set' id='push1'>
...
... server as well:
Example: Acknowledging receipt of privacy list pushes:
<iq from='romeo@example.net/orchard'
...
... Adding a New Privacy List ...
... new list. If the list name matches that of an existing list, the
request to add a new list will overwrite the old one. As with list
edits, the server MUST also send a "privacy list push" to all
connected resources.
...
... Removing a Privacy List ...
...
In order to remove a privacy list, the user MUST send an IQ stanza of
type "set" with a <query ...
... Example: Client removes a privacy list:
<iq from='romeo@example.net/orchard' type='set' id='remove1'>
...
...
Server-side privacy lists enable a user to block incoming messages
from other entities based on the entity's JID ...
... the protocol. (Note: For the sake of brevity, IQ stanzas of type
"result" are not shown in the following examples, nor are "privacy
list pushes".)
Example: User blocks based on JID ...
...
Server-side privacy lists enable a user to block incoming presence
notifications from other entities based on the entity ...
...
Server-side privacy lists enable a user to block outgoing presence
notifications to other entities based on the entity ...
...
Server-side privacy lists enable a user to block incoming IQ stanzas
from other entities based on the entity ...
...
Server-side privacy lists enable a user to block all stanzas from and
to other entities based on the entity ...
... JID contained in the 'to' attribute is of the
form <user@example.com> or <user@example.com/resource>, the server
MUST first apply any privacy lists (Section 10) that are in force,
then follow the rules defined below:
...
... clients, presence subscriptions, roster storage and
manipulation, privacy lists, and IM-specific routing and delivery ...
... in this document, including presence subscriptions, roster
management, and privacy lists
o End-to-end ...
... stanza of any kind whose
intended recipient is a user associated with one of the server's
hostnames, the server MUST first apply any privacy lists (Section
10) that are in force (see Server Rules for Handling XML Stanzas
...
... C.2 Privacy Lists ...
... The Jabber community began to define a protocol for communications
blocking (privacy lists) in late 2001, but that effort was deprecated
once the XMPP Working Group ...
... IM session establishment
and communication blocking (privacy lists); the session establishment
protocol was mainly developed by Rob Norris and Joe Hildebrand, and
...
... session establishment
protocol was mainly developed by Rob Norris and Joe Hildebrand, and
the privacy lists protocol was originally contributed by Peter
Millard.
...