Mercurial > prosody-wiki
comparison mod_privacy.wiki @ 32:f9fcf45e4ce8
Edited wiki page through web user interface.
| author | t.ephraim |
|---|---|
| date | Sat, 26 Sep 2009 20:20:56 +0000 |
| parents | a96213be1606 |
| children | b6062e1902bf |
comparison
equal
deleted
inserted
replaced
| 31:3b33fdc7eda2 | 32:f9fcf45e4ce8 |
|---|---|
| 12 | 12 |
| 13 | 13 |
| 14 | 14 |
| 15 == TODO == | 15 == TODO == |
| 16 * If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a "bad-request" stanza error. | 16 * If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a "bad-request" stanza error. |
| 17 * If the type is "group", then the 'value' attribute SHOULD contain the name of a group in the user's roster. (If a client attempts to update, create, or delete a list item with a group that is not in the user's roster, the server SHOULD return to the client an "item-not-found" stanza error.) | |
| 18 * If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined RFC 3921, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only). | |
| 19 * If no 'type' attribute is included, the rule provides the "fall-through" case. | |
| 20 * The 'action' attribute MUST be included and its value MUST be either "allow" or "deny". | |
| 21 * The 'order' attribute MUST be included and its value MUST be a non-negative integer that is unique among all items in the list. (If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a "bad-request" stanza error.) | |
| 17 * Examples 29-51 | 22 * Examples 29-51 |
| 18 | |
| 19 === special TODO's === | |
| 20 * Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in RFC 3921 and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in RFC 3921. | |
| 21 * When a resource attempts to remove a list or specify a new default list while that list applies to a connected resource other than the sending resource, the server MUST return a "conflict" error to the sending resource and MUST NOT make the requested change. | 23 * When a resource attempts to remove a list or specify a new default list while that list applies to a connected resource other than the sending resource, the server MUST return a "conflict" error to the sending resource and MUST NOT make the requested change. |
| 22 * Example 18. Client attempts to change the default list but that list is in use by another resource | 24 * Example 18. Client attempts to change the default list but that list is in use by another resource |
| 23 * Example 22. Client attempts to decline a default list but that list is in use by another resource | 25 * Example 22. Client attempts to decline a default list but that list is in use by another resource |