moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00
Code Issues Releases Wiki Activity

1.6pre1

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@449 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-30 18:25:13 +00:00
parent b3c87cb6cf
commit d605db4a2a
1 changed files with 17 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
xep-0016.xml
View File

@ -21,6 +21,12 @@
<shortname>privacy</shortname> <shortname>privacy</shortname>
&pgmillard; &pgmillard;
&stpeter; &stpeter;
<revision>
<version>1.6pre1</version>
<date>in progress, last updated 2007-01-30</date>
<initials>psa</initials>
<remark><p>Added two notes to maintain consistency with XEP-0191.</p></remark>
</revision>
<revision> <revision>
<version>1.5</version> <version>1.5</version>
<date>2006-11-27</date> <date>2006-11-27</date>
@ -557,6 +563,7 @@
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.</p> <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.</p>
<p>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.</p>
</section2> </section2>
<section2 topic="Blocking Outbound Presence Notifications" anchor="protocol-presenceout"> <section2 topic="Blocking Outbound Presence Notifications" anchor="protocol-presenceout">
<p>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.</p> <p>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.</p>
@ -618,6 +625,7 @@
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p> <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
<p>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 <cite>RFC 3921</cite>).</p>
</section2> </section2>
<section2 topic="Blocking IQ Stanzas" anchor="protocol-iq"> <section2 topic="Blocking IQ Stanzas" anchor="protocol-iq">
<p>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.</p> <p>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.</p>
@ -759,6 +767,15 @@
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>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 &notacceptable; error:</p>
<example caption='Error: contact is blocked'><![CDATA[
<message type='error' from='romeo@montague.net' to='juliet@capulet.com'>
<body>Can you hear me now?</body>
<error type='cancel'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
]]></example>
</section2> </section2>
<section2 topic="Higher-Level Heuristics" anchor="protocol-heuristics"> <section2 topic="Higher-Level Heuristics" anchor="protocol-heuristics">
<p>When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.</p> <p>When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.</p>