default list is in use by at least one connected resource other than
the sending resource, the server MUST return a <conflict/> stanza
error to the sending resource:
Example: Client attempts to change the default list but that list is
in use by another resource:
<iq to=’romeo@example.net/orchard’ type=’error’ id=’default1’>
<query xmlns=’jabber:iq:privacy’>
<default name=’special’/>
</query>
<error type=’cancel’>
<conflict
xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</iq>
If the user attempts to set a default list but a list by that name
does not exist, the server MUST return an <item-not-found/> stanza
error to the user:
Example: Client attempts to set a non-existent list as default:
<iq to=’romeo@example.net/orchard’ type=’error’ id=’default1’>
<query xmlns=’jabber:iq:privacy’>
<default name=’The Empty Set’/>
</query>
<error type=’cancel’>
<item-not-found
xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</iq>
In order to decline the use of a default list (i.e., to use the
domain’s stanza routing rules at all times), the user MUST send an
empty <default/> element with no ’name’ attribute.
Example: Client declines the use of the default list:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’default2’>
<query xmlns=’jabber:iq:privacy’>
<default/>
</query>
</iq>
Example: Server acknowledges success of declining any default list:
<iq type=’result’ id=’default2’ to=’romeo@example.net/orchard’/>
If one connected resource attempts to decline the use of a default
list for the user as a whole but the default list currently applies
to at least one other connected resource, the server MUST return a
<conflict/> error to the sending resource:
Example: Client attempts to decline a default list but that list is
in use by another resource:
<iq to=’romeo@example.net/orchard’ type=’error’ id=’default3’>
<query xmlns=’jabber:iq:privacy’>
<default/>
</query>
<error type=’cancel’>
<conflict
xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</iq>
10.6. Editing a Privacy List
In order to edit a privacy list, the user MUST send an IQ stanza of
type "set" with a <query/> element qualified by the
’jabber:iq:privacy’ namespace that contains one <list/> child element
possessing a ’name’ attribute whose value is set to the list name the
user would like to edit. The <list/> element MUST contain one or
more <item/> elements, which specify the user’s desired changes to
the list by including all elements in the list (not the "delta").
Example: Client edits a privacy list:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’edit1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’public’>
<item type=’jid’
value=’tybalt@example.com’
action=’deny’
order=’3’/>
<item type=’jid’
value=’paris@example.org’
action=’deny’
order=’5’/>
<item action=’allow’ order=’68’/>
</list>
</query>
</iq>
Example: Server acknowledges success of list edit:
<iq type=’result’ id=’edit1’ to=’romeo@example.net/orchard’/>
Note: The value of the ’order’ attribute for any given item is not
fixed. Thus in the foregoing example if the user would like to add 4
items between the "tybalt@example.com" item and the
"paris@example.org" item, the user’s client MUST renumber the
relevant items before submitting the list to the server.
The server MUST now send a "privacy list push" to all connected
resources:
Example: Privacy list push on list edit:
<iq to=’romeo@example.net/orchard’ type=’set’ id=’push1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’public’/>
</query>
</iq>
<iq to=’romeo@example.net/home’ type=’set’ id=’push2’>
<query xmlns=’jabber:iq:privacy’>
<list name=’public’/>
</query>
</iq>
In accordance with the semantics of IQ stanzas defined in
[XMPP-CORE], each connected resource MUST return an IQ result to the
server as well:
Example: Acknowledging receipt of privacy list pushes:
<iq from=’romeo@example.net/orchard’
type=’result’
id=’push1’/>
<iq from=’romeo@example.net/home’
type=’result’
id=’push2’/>
10.7. Adding a New Privacy List
The same protocol used to edit an existing list is used to create a
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.
10.8. Removing a Privacy List
In order to remove a privacy list, the user MUST send an IQ stanza of
type "set" with a <query/> element qualified by the
’jabber:iq:privacy’ namespace that contains one empty <list/> child
element possessing a ’name’ attribute whose value is set to the list
name the user would like to remove.
Example: Client removes a privacy list:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’remove1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’private’/>
</query>
</iq>
Example: Server acknowledges success of list removal:
<iq type=’result’ id=’remove1’ to=’romeo@example.net/orchard’/>
If a user attempts to remove a list that is currently being applied
to at least one resource other than the sending resource, the server
MUST return a <conflict/> stanza error to the user; i.e., the user
MUST first set another list to active or default before attempting to
remove it. If the user attempts to remove a list but a list by that
name does not exist, the server MUST return an <item-not-found/>
stanza error to the user. If the user attempts to remove more than
one list in the same request, the server MUST return a <bad request/>
stanza error to the user.
10.9. Blocking Messages
Server-side privacy lists enable a user to block incoming messages
from other entities based on the entity’s JID, roster group, or
subscription status (or globally). The following examples illustrate
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:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’msg1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’message-jid-example’>
<item type=’jid’
value=’tybalt@example.com’
action=’deny’
order=’3’>
<message/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive messages from the entity with the specified JID.
Example: User blocks based on roster group:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’msg2’>
<query xmlns=’jabber:iq:privacy’>
<list name=’message-group-example’>
<item type=’group’
value=’Enemies’
action=’deny’
order=’4’>
<message/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive messages from any entities in the specified roster
group.
Example: User blocks based on subscription type:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’msg3’>
<query xmlns=’jabber:iq:privacy’>
<list name=’message-sub-example’>
<item type=’subscription’
value=’none’
action=’deny’
order=’5’>
<message/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive messages from any entities with the specified
subscription type.
Example: User blocks globally:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’msg4’>
<query xmlns=’jabber:iq:privacy’>
<list name=’message-global-example’>
<item action=’deny’ order=’6’>
<message/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive messages from any other users.
10.10. Blocking Inbound Presence Notifications
Server-side privacy lists enable a user to block incoming presence
notifications from other entities based on the entity’s JID, roster
group, or subscription status (or globally). The following examples
illustrate the protocol.
Note: Presence notifications do not include presence subscriptions,
only presence information that is broadcasted to the user because the
user is currently subscribed to a contact’s presence information.
Thus this includes presence stanzas with no ’type’ attribute or of
type=’unavailable’ only.
Example: User blocks based on JID:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presin1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presin-jid-example’>
<item type=’jid’
value=’tybalt@example.com’
action=’deny’
order=’7’>
<presence-in/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive presence notifications from the entity with the
specified JID.
Example: User blocks based on roster group:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presin2’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presin-group-example’>
<item type=’group’
value=’Enemies’
action=’deny’
order=’8’>
<presence-in/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive presence notifications from any entities in the
specified roster group.
Example: User blocks based on subscription type:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presin3’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presin-sub-example’>
<item type=’subscription’
value=’to’
action=’deny’
order=’9’>
<presence-in/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive presence notifications from any entities with the
specified subscription type.
Example: User blocks globally:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presin4’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presin-global-example’>
<item action=’deny’ order=’11’>
<presence-in/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive presence notifications from any other users.
10.11. Blocking Outbound Presence Notifications
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.
Note: Presence notifications do not include presence subscriptions,
only presence information that is broadcasted to contacts because
those contacts are currently subscribed to the user’s presence
information. Thus this includes presence stanzas with no ’type’
attribute or of type=’unavailable’ only.
Example: User blocks based on JID:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presout1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presout-jid-example’>
<item type=’jid’
value=’tybalt@example.com’
action=’deny’
order=’13’>
<presence-out/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not send presence notifications to the entity with the specified
JID.
Example: User blocks based on roster group:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presout2’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presout-group-example’>
<item type=’group’
value=’Enemies’
action=’deny’
order=’15’>
<presence-out/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not send presence notifications to any entities in the specified
roster group.
Example: User blocks based on subscription type:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presout3’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presout-sub-example’>
<item type=’subscription’
value=’from’
action=’deny’
order=’17’>
<presence-out/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not send presence notifications to any entities with the
specified subscription type.
Example: User blocks globally:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’presout4’>
<query xmlns=’jabber:iq:privacy’>
<list name=’presout-global-example’>
<item action=’deny’ order=’23’>
<presence-out/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not send presence notifications to any other users.
10.12. Blocking IQ Stanzas
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.
Example: User blocks based on JID:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’iq1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’iq-jid-example’>
<item type=’jid’
value=’tybalt@example.com’
action=’deny’
order=’29’>
<iq/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive IQ stanzas from the entity with the specified JID.
Example: User blocks based on roster group:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’iq2’>
<query xmlns=’jabber:iq:privacy’>
<list name=’iq-group-example’>
<item type=’group’
value=’Enemies’
action=’deny’
order=’31’>
<iq/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive IQ stanzas from any entities in the specified roster
group.
Example: User blocks based on subscription type:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’iq3’>
<query xmlns=’jabber:iq:privacy’>
<list name=’iq-sub-example’>
<item type=’subscription’
value=’none’
action=’deny’
order=’17’>
<iq/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive IQ stanzas from any entities with the specified
subscription type.
Example: User blocks globally:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’iq4’>
<query xmlns=’jabber:iq:privacy’>
<list name=’iq-global-example’>
<item action=’deny’ order=’1’>
<iq/>
</item>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive IQ stanzas from any other users.
10.13. Blocking All Communication
Server-side privacy lists enable a user to block all stanzas from and
to other entities based on the entity’s JID, roster group, or
subscription status (or globally). Note that this includes
subscription-related presence stanzas, which are excluded by Blocking
Inbound Presence Notifications (Section 10.10). The following
examples illustrate the protocol.
Example: User blocks based on JID:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’all1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’all-jid-example’>
<item type=’jid’
value=’tybalt@example.com’
action=’deny’
order=’23’/>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive any communications from, nor send any stanzas to,
the entity with the specified JID.
Example: User blocks based on roster group:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’all2’>
<query xmlns=’jabber:iq:privacy’>
<list name=’all-group-example’>
<item type=’group’
value=’Enemies’
action=’deny’
order=’13’/>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive any communications from, nor send any stanzas to,
any entities in the specified roster group.
Example: User blocks based on subscription type:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’all3’>
<query xmlns=’jabber:iq:privacy’>
<list name=’all-sub-example’>
<item type=’subscription’
value=’none’
action=’deny’
order=’11’/>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive any communications from, nor send any stanzas to,
any entities with the specified subscription type.
Example: User blocks globally:
<iq from=’romeo@example.net/orchard’ type=’set’ id=’all4’>
<query xmlns=’jabber:iq:privacy’>
<list name=’all-global-example’>
<item action=’deny’ order=’7’/>
</list>
</query>
</iq>
As a result of creating and applying the foregoing list, the user
will not receive any communications from, nor send any stanzas to,
any other users.
10.14. Blocked Entity Attempts to Communicate with User
If a blocked entity attempts to send message or presence stanzas to
the user, the user’s server SHOULD silently drop the stanza and MUST
NOT return an error to the sending entity.
If a blocked entity attempts to send an IQ stanza of type "get" or
"set" to the user, the user’s server MUST return to the sending
entity a <service-unavailable/> stanza error, since this is the
standard error code sent from a client that does not understand the
namespace of an IQ get or set. IQ stanzas of other types SHOULD be
silently dropped by the server.
Example: Blocked entity attempts to send IQ get:
<iq type=’get’
to=’romeo@example.net’
from=’tybalt@example.com/pda’
id=’probing1’>
<query xmlns=’jabber:iq:version’/>
</iq>
Example: Server returns error to blocked entity:
<iq type=’error’
from=’romeo@example.net’
to=’tybalt@example.com/pda’
id=’probing1’>
<query xmlns=’jabber:iq:version’/>
<error type=’cancel’>
<service-unavailable
xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</iq>
10.15. Higher-Level Heuristics
When building a representation of a higher-level privacy heuristic, a
client SHOULD use the simplest possible representation.
For example, the heuristic "block all communications with any user
not in my roster" could be constructed in any of the following ways:
o allow communications from all JIDs in my roster (i.e., listing
each JID as a separate list item), but block communications with
everyone else
o allow communications from any user who is in one of the groups
that make up my roster (i.e., listing each group as a separate
list item), but block communications from everyone else
o allow communications from any user with whom I have a subscription
of ’both’ or ’to’ or ’from’ (i.e., listing each subscription value
separately), but block communications from everyone else
o block communications from anyone whose subscription state is
’none’
The final representation is the simplest and SHOULD be used; here is
the XML that would be sent in this case:
<iq type=’set’ id=’heuristic1’>
<query xmlns=’jabber:iq:privacy’>
<list name=’heuristic-example’>
<item type=’subscription’
value=’none’
action=’deny’
order=’437’/>
</list>
</query>
</iq>
11. Server Rules for Handling XML Stanzas
Basic routing and delivery rules for servers are defined in
[XMPP-CORE]. This section defines additional rules for
XMPP-compliant instant messaging and presence servers.
11.1. Inbound Stanzas
If the hostname of the domain identifier portion of the JID contained
in the ’to’ attribute of an inbound stanza matches a hostname of the
server itself and the 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: