Browse Source

SPEC-17

xep-0352-v0.2
stpeter 12 years ago
parent
commit
bae613ecae
  1. 24
      xep-0016.xml

24
xep-0016.xml

@ -802,6 +802,30 @@ @@ -802,6 +802,30 @@
</section2>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
<p>If an entity supports the privacy lists protocol, it MUST report that fact by including a service discovery feature of "jabber:iq:privacy" &NSNOTE; in response to a &xep0030; information request:</p>
<example caption="Service Discovery information request"><![CDATA[
<iq from='juliet@example.com/chamber'
id='disco1'
to='example.com'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service Discovery information response"><![CDATA[
<iq from='example.com'
id='disco1'
to='juliet@example.com/chamber'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='jabber:iq:privacy'/>
...
</query>
</iq>
]]></example>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>When a server receives a block command from a user, it MAY cancel any existing presence subscriptions between the user and the blocked user and MAY send a message to the blocked user; however, it is RECOMMENDED to deploy so-called "polite blocking" instead (i.e., to not cancel the presence subscriptions or send a notification). Which approach to follow is a matter of local service policy.</p>
<p>A service MAY also filter blocking users out of searches performed on user directories (see, for example, &xep0055;); however, that functionality is out of scope for this specification.</p>

Loading…
Cancel
Save