git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1185 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-24 21:44:46 +00:00
parent 582be4e763
commit 349258664b
1 changed files with 39 additions and 8 deletions

View File

@ -49,8 +49,8 @@
&ralphm;
<revision>
<version>1.10pre7</version>
<date>in progress, last updated 2007-08-17</date>
<version>1.10pre8</version>
<date>in progress, last updated 2007-08-24</date>
<initials>psa</initials>
<remark>
<ul>
@ -59,6 +59,7 @@
<li>Updated filtered-notifications text and examples to track changes to XEP-0115</li>
<li>Added publish-options functionality</li>
<li>Added developer-friendly How It Works section</li>
<li>Defined member affiliation to properly implement whitelist feature</li>
<li>Split several long sections into smaller sub-sections.</li>
<li>Clarified that a pubsub service must generate an ItemID if the publisher does not provide one.</li>
</ul>
@ -404,7 +405,7 @@ And by opposing end them?
<tr><td>Pubsub Service</td><td>An XMPP server or component that adheres to the protocol defined herein.</td></tr>
<tr><td>Roster Access Model</td><td>A node access model under which any entity that is subscribed to the owner's presence and in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.</td></tr>
<tr><td>Subscriber</td><td>An entity that is subscribed to a node.</td></tr>
<tr><td>Whitelist Access Model</td><td>A node access model under which an entity can subscribe only through being added by a node owner (subscription requests are rejected) and only subscribers may retrieve items.</td></tr>
<tr><td>Whitelist Access Model</td><td>A node access model under which an entity may subscribe and retrieve items only if explicitly allowed to do so by the node owner (subscription requests from unauthorized entities are rejected).</td></tr>
</table>
</section1>
@ -444,11 +445,12 @@ And by opposing end them?
<tr>
<th>Affiliation</th>
<th>Subscribe</th>
<th>Publish Items</th>
<th>Purge Items</th>
<th>Retrieve Items</th>
<th>Publish Item</th>
<th>Delete Item</th>
<th>Configure Node</th>
<th>Delete Node</th>
<th>Delete Item</th>
<th>Purge Node</th>
</tr>
<tr>
<td>Owner</td>
@ -458,16 +460,28 @@ And by opposing end them?
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Publisher</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
<td>Yes/No *</td>
</tr>
<tr>
<td>Member</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>None</td>
<td>Yes</td>
@ -476,6 +490,7 @@ And by opposing end them?
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Outcast</td>
@ -485,6 +500,7 @@ And by opposing end them?
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
</tr>
</table>
<p>* Note: A service MAY allow any publisher to delete any item once it has been published to that node instead of allowing only the original publisher to remove it (this is discoverable via the "pubsub#delete-any" feature).</p>
@ -494,6 +510,7 @@ And by opposing end them?
<th>&#160;</th>
<th>Outcast</th>
<th>None</th>
<th>Member</th>
<th>Publisher</th>
<th>Owner</th>
</tr>
@ -501,6 +518,7 @@ And by opposing end them?
<td>Outcast</td>
<td>--</td>
<td>Owner removes ban</td>
<td>Owner adds entity to member list</td>
<td>Owner adds entity to publisher list</td>
<td>Owner adds entity to owner list</td>
</tr>
@ -508,6 +526,15 @@ And by opposing end them?
<td>None</td>
<td>Owner bans entity</td>
<td>--</td>
<td>Owner adds entity to member list</td>
<td>Owner adds entity to publisher list</td>
<td>Owner adds entity to owner list</td>
</tr>
<tr>
<td>Member</td>
<td>Owner bans entity</td>
<td>Owner removes entity from member list</td>
<td>--</td>
<td>Owner adds entity to publisher list</td>
<td>Owner adds entity to owner list</td>
</tr>
@ -515,6 +542,7 @@ And by opposing end them?
<td>Publisher</td>
<td>Owner bans entity</td>
<td>Owner removes entity from publisher list</td>
<td>n/a</td>
<td>--</td>
<td>Owner adds entity to owner list</td>
</tr>
@ -523,6 +551,7 @@ And by opposing end them?
<td>n/a</td>
<td>Owner resigns</td>
<td>n/a</td>
<td>n/a</td>
<td>--</td>
</tr>
</table>
@ -617,7 +646,7 @@ And by opposing end them?
</tr>
<tr>
<td>Whitelist</td>
<td>An entity may be subscribed only through being added to a whitelist by the node owner (unsolicited subscription requests are rejected), and only subscribers may retrieve items from the node. In effect, the default affiliation is outcast. The node owner MUST automatically be on the whitelist. In order to add entities to the whitelist, the node owner SHOULD use the protocol specified in the <link url='#owner-affiliations'>Manage Affiliated Entities</link> section of this document.</td>
<td>An entity may subscribe or retrieve items only if on a whitelist managed by the node owner. The node owner MUST automatically be on the whitelist. In order to add entities to the whitelist, the node owner SHOULD use the protocol specified in the <link url='#owner-affiliations'>Manage Affiliated Entities</link> section of this document, specifically by setting the affiliation to "member".</td>
</tr>
</table>
<p>A generic publish-subscribe implementation SHOULD support all of the defined access models, although specialized publish-subscribe implementations MAY support only a subset of the access models. Which access models are provided in a particular deployment is a matter of service provisioning (e.g., some restricted deployments may wish to lock down permissions so that only the "authorize" and "whitelist" access models are provided, or even only the "whitelist" access model).</p>
@ -5746,6 +5775,8 @@ O, what a rogue and peasant slave am I!
</message>
]]></example>
</section2>
<section2 topic='Managing the Whitelist' anchor='impl-whitelist'>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>