This commit is contained in:
stpeter 2011-04-12 21:29:47 -06:00
parent 5a0239ed76
commit bae613ecae
1 changed files with 24 additions and 0 deletions

View File

@ -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>