mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
re-organized manage affiliations section
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1314 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
26ef69f279
commit
4d838e4566
198
xep-0060.xml
198
xep-0060.xml
@ -4267,11 +4267,13 @@ And by opposing end them?
|
||||
</section3>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Manage Affiliations' anchor='owner-affiliations'>
|
||||
<p>A node owner may want to edit the affiliations of entities associated with a given node and to set affiliations for new entities. Support for this feature ("pubsub#modify-affiliations") is OPTIONAL.</p>
|
||||
<section3 topic='Request' anchor='owner-affiliations-request'>
|
||||
<p>In order to request a list of all affiliated entities, a node owner MUST send an affiliations request, consisting of an <affiliations/> element whose 'node' attribute specifies the NodeID of the relevant node.</p>
|
||||
<example caption='Owner requests all affiliated entities'><![CDATA[
|
||||
<section2 topic='Manage Affiliations' anchor='owner-affilmanage'>
|
||||
<p>A node owner may want to manage the affiliations of entities associated with a given node and to set affiliations for new entities. Support for this feature ("pubsub#modify-affiliations") is OPTIONAL.</p>
|
||||
<section3 topic='Retrieve Affiliations List' anchor='owner-affilmanage-retrieve'>
|
||||
<p>First the owner retrieves the affiliation list.</p>
|
||||
<section4 topic='Request' anchor='owner-affilmanage-retrieve-request'>
|
||||
<p>In order to request a list of all affiliated entities, a node owner MUST send an affiliations request, consisting of an <affiliations/> element whose 'node' attribute specifies the NodeID of the relevant node.</p>
|
||||
<example caption='Owner requests all affiliated entities'><![CDATA[
|
||||
<iq type='get'
|
||||
from='hamlet@denmark.lit/elsinore'
|
||||
to='pubsub.shakespeare.lit'
|
||||
@ -4280,11 +4282,11 @@ And by opposing end them?
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Success Case' anchor='owner-affiliations-success'>
|
||||
<p>If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "publisher", or "outcast" (it MUST NOT return entities whose affiliation is "none").</p>
|
||||
<example caption='Service returns list of affiliated entities'><![CDATA[
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='Success Case' anchor='owner-affilmanage-retrieve-success'>
|
||||
<p>If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "publisher", or "outcast" (it MUST NOT return entities whose affiliation is "none").</p>
|
||||
<example caption='Service returns list of affiliated entities'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='hamlet@denmark.lit/elsinore'
|
||||
@ -4296,22 +4298,22 @@ And by opposing end them?
|
||||
</affiliations>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Error Cases' anchor='owner-affiliations-error'>
|
||||
<p>There are several reasons why the affiliated entities request might fail:</p>
|
||||
<ol>
|
||||
<li>The service does not support modification of affiliations.</li>
|
||||
<li>The requesting entity does not have sufficient privileges to modify affiliations.</li>
|
||||
<li>The specified node does not exist.</li>
|
||||
</ol>
|
||||
<p>These error cases are described more fully in the following sections.</p>
|
||||
<section4 topic='Affiliation Modification Not Supported' anchor='owner-affiliations-notsupported'>
|
||||
<p>If an implementation does not support modification of affiliations, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "modify-affiliations".</p>
|
||||
<example caption='Node or service does not support affiliation management'><![CDATA[
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='Error Cases' anchor='owner-affilmanage-retrieve-error'>
|
||||
<p>There are several reasons why the affiliated entities request might fail:</p>
|
||||
<ol>
|
||||
<li>The service does not support modification of affiliations.</li>
|
||||
<li>The requesting entity does not have sufficient privileges to modify affiliations.</li>
|
||||
<li>The specified node does not exist.</li>
|
||||
</ol>
|
||||
<p>These error cases are described more fully in the following sections.</p>
|
||||
<section5 topic='Affiliation Modification Not Supported' anchor='owner-affilmanage-retrieve-notsupported'>
|
||||
<p>If an implementation does not support modification of affiliations, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "modify-affiliations".</p>
|
||||
<example caption='Node or service does not support affiliation management'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='purge1'>
|
||||
id='ent1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
@ -4321,11 +4323,11 @@ And by opposing end them?
|
||||
feature='modify-affiliations'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='Insufficient Privileges' anchor='owner-affiliations-forbidden'>
|
||||
<p>If the requesting entity is not a node owner, the service MUST return a &forbidden; error.</p>
|
||||
<example caption='Entity is not an owner'><![CDATA[
|
||||
]]></example>
|
||||
</section5>
|
||||
<section5 topic='Insufficient Privileges' anchor='owner-affilmanage-retrieve-forbidden'>
|
||||
<p>If the requesting entity is not a node owner, the service MUST return a &forbidden; error.</p>
|
||||
<example caption='Entity is not an owner'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='ent1'>
|
||||
@ -4336,14 +4338,14 @@ And by opposing end them?
|
||||
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='Node Does Not Exist' anchor='owner-affiliations-node'>
|
||||
<p>If the node does not exist, the service MUST return an ¬found; error.</p>
|
||||
<example caption='Node does not exist'><![CDATA[
|
||||
]]></example>
|
||||
</section5>
|
||||
<section5 topic='Node Does Not Exist' anchor='owner-affilmanage-retrieve-node'>
|
||||
<p>If the node does not exist, the service MUST return an ¬found; error.</p>
|
||||
<example caption='Node does not exist'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='purge1'>
|
||||
id='ent1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
@ -4351,38 +4353,112 @@ And by opposing end them?
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
</section5>
|
||||
</section4>
|
||||
</section3>
|
||||
<section3 topic='Modifying Affiliations' anchor='owner-affiliations-modify'>
|
||||
<p>Upon receiving the affiliations list, the node owner MAY modify affiliations. The owner MUST send only modified affiliations (i.e., a "delta"), not the complete list. (Note: If the 'affiliation' attribute is not specified in a modification request, then the value MUST NOT be changed.)</p>
|
||||
<example caption='Owner modifies affiliations'><![CDATA[
|
||||
<section3 topic='Modify Affiliation' anchor='owner-affilmanage-modify'>
|
||||
<p>A node owner may want to edit the affiliation of an entity associated with a given node or to set the affiliation for a new entity.</p>
|
||||
<section4 topic='Request' anchor='owner-affilmanage-modify-request'>
|
||||
<p>In order to modify an affiliation, a node owner MUST send an IQ set containing the modified affiliation or affiliations. The owner MUST send only modified affiliations (i.e., a "delta"), not the complete list. (Note: If the 'affiliation' attribute is not specified in a modification request, then the value MUST NOT be changed.)</p>
|
||||
<example caption='Owner modifies affiliation'><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@denmark.lit/elsinore'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='ent2'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
<affiliation jid='hamlet@denmark.lit' affiliation='owner'/>
|
||||
<affiliation jid='polonius@denmark.lit' affiliation='none'/>
|
||||
<affiliation jid='bard@shakespeare.lit' affiliation='publisher'/>
|
||||
</affiliations>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Service responds with success'><![CDATA[
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='Success Case' anchor='owner-affilmanage-modify-success'>
|
||||
<example caption='Service responds with success'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='ent2'/>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Deleting an Entity' anchor='owner-affiliations-delete'>
|
||||
<p>In order to remove an entity from the affiliations list, the owner MUST set the value of the 'affiliation' attribute to "none" and the service MUST remove that entity from the affiliations list and not return it in response to future list requests.</p>
|
||||
</section3>
|
||||
<section3 topic='Multiple Simultaneous Modifications' anchor='owner-affiliations-multi'>
|
||||
<p>The owner MAY change multiple affiliations in a single request. If one of the entity elements specified is invalid, the service MUST return an IQ error (which SHOULD be ¬acceptable;) with the invalid entries, where the affiliation returned is the original, un-altered affiliation.</p>
|
||||
<p>The following example shows an entity attempting to make the owner something other than an affiliation of "owner", an action which MUST NOT be allowed if there is only one owner.</p>
|
||||
<example caption='Owner sets affiliation for multiple entities'><![CDATA[
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='Error Cases' anchor='owner-affiliations-modify-error'>
|
||||
<p>There are several reasons why the modify-affiliations request might fail:</p>
|
||||
<ol>
|
||||
<li>The requested affiliation is not supported by the node or service.</li>
|
||||
<li>The service does not support modification of affiliations.</li>
|
||||
<li>The requesting entity does not have sufficient privileges to modify affiliations.</li>
|
||||
<li>The specified node does not exist.</li>
|
||||
</ol>
|
||||
<p>These error cases are described more fully in the following sections.</p>
|
||||
<section5 topic='Affiliation Modification Not Supported' anchor='owner-affilmanage-retrieve-notsupported'>
|
||||
<p>If an implementation does not support modification of affiliations, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "modify-affiliations".</p>
|
||||
<example caption='Node or service does not support affiliation management'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='ent1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
<error type='cancel'>
|
||||
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<unsupported xmlns='http://jabber.org/protocol/pubsub#errors'
|
||||
feature='modify-affiliations'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section5>
|
||||
<section5 topic='Affiliation Not Supported' anchor='owner-affiliations-nosuchaffil'>
|
||||
<p>If the node or service does not support the requested affiliation, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "member-affiliation", "outcast-affiliation", or "publisher-affiliation" as appropriate.</p>
|
||||
<example caption='Node or service does not support the requested affiliation'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='ent1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
<error type='cancel'>
|
||||
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<unsupported xmlns='http://jabber.org/protocol/pubsub#errors'
|
||||
feature='modify-affiliations'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section5>
|
||||
<section5 topic='Insufficient Privileges' anchor='owner-affilmanage-retrieve-forbidden'>
|
||||
<p>If the requesting entity is not a node owner, the service MUST return a &forbidden; error.</p>
|
||||
<example caption='Entity is not an owner'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='ent1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
<error type='auth'>
|
||||
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section5>
|
||||
<section5 topic='Node Does Not Exist' anchor='owner-affilmanage-retrieve-node'>
|
||||
<p>If the node does not exist, the service MUST return an ¬found; error.</p>
|
||||
<example caption='Node does not exist'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
id='ent1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<affiliations node='princely_musings'/>
|
||||
</pubsub>
|
||||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section5>
|
||||
</section4>
|
||||
<section4 topic='Multiple Simultaneous Modifications' anchor='owner-affiliations-multi'>
|
||||
<p>The owner MAY change multiple affiliations in a single request. If one of the entity elements specified is invalid, the service MUST return an IQ error (which SHOULD be ¬acceptable;) with the invalid entries, where the affiliation returned is the original, un-altered affiliation.</p>
|
||||
<p>The following example shows an entity attempting to make the owner something other than an affiliation of "owner", an action which MUST NOT be allowed if there is only one owner.</p>
|
||||
<example caption='Owner sets affiliation for multiple entities'><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@denmark.lit/elsinore'
|
||||
to='pubsub.shakespeare.lit'
|
||||
@ -4395,8 +4471,8 @@ And by opposing end them?
|
||||
</affiliations>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Service responds with an error'><![CDATA[
|
||||
]]></example>
|
||||
<example caption='Service responds with an error'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='hamlet@denmark.lit/elsinore'
|
||||
@ -4410,8 +4486,12 @@ And by opposing end them?
|
||||
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The state chart at the beginning of this document is a MUST-IMPLEMENT set of rules for checking possible state transitions. Implementations MAY enforce other (more strict) rules. If errors occur during a modification request for multiple entities, the pubsub service MUST return any <affiliation/> element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'affiliation' attribute. Any entity elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MUST NOT specify multiple <affiliation/> elements for the same entity; otherwise the service MUST return a &badrequest; error.</p>
|
||||
]]></example>
|
||||
<p>The state chart at the beginning of this document is a MUST-IMPLEMENT set of rules for checking possible state transitions. Implementations MAY enforce other (more strict) rules. If errors occur during a modification request for multiple entities, the pubsub service MUST return any <affiliation/> element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'affiliation' attribute. Any entity elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MUST NOT specify multiple <affiliation/> elements for the same entity; otherwise the service MUST return a &badrequest; error.</p>
|
||||
</section4>
|
||||
</section3>
|
||||
<section3 topic='Deleting an Entity' anchor='owner-affiliations-delete'>
|
||||
<p>In order to remove an entity from the affiliations list, the owner MUST set the value of the 'affiliation' attribute to "none" and the service MUST remove that entity from the affiliations list and not return it in response to future list requests.</p>
|
||||
</section3>
|
||||
<section3 topic='Notifying Entities' anchor='owner-affiliations-notify'>
|
||||
<p>An implementation MAY send a message to an entity whose affiliation has changed, which MAY contain a &BODY; element specifying natural-language text regarding the affiliation change and which SHOULD contain the modified affiliation data.</p>
|
||||
@ -5393,7 +5473,10 @@ And by opposing end them?
|
||||
</section2>
|
||||
|
||||
<section2 topic='Batch Processing' anchor='impl-batch'>
|
||||
<p>A publisher MAY include multiple &ITEM; elements in a publish request and MAY include multiple &ITEM; elements in a retract request. This results in "batch processing" of publications or retractions. If the service cannot process any one of the items to be published or retracted, the entire batch MUST fail. Also note that batch publication renders the concept of "last published item" problematic; therefore, if information coherence is needed, a publisher SHOULD publish items in separate requests rather than in batch mode.</p>
|
||||
<p>A publisher MAY include multiple &ITEM; elements in a publish request and MAY include multiple &ITEM; elements in a retract request. This results in "batch processing" of publications or retractions.</p>
|
||||
<p>If the service cannot process any one of the items to be published or retracted, the entire batch MUST fail and the service MUST NOT publish or retract any of the items.</p>
|
||||
<p>If a batch publish contains so many items that publication of all the items would exceed the maximum number of items for the node, the service MUST return a ¬allowed; error, which SHOULD also include a pubsub-specific error condition of <max-items-exceeded/>.</p>
|
||||
<p>Note: Batch publication renders the concept of "last published item" problematic; therefore, if information coherence is needed, a publisher SHOULD publish items in separate requests rather than in batch mode.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Auto-Subscribing Owners and Publishers' anchor='impl-autosubscribe'>
|
||||
@ -6743,6 +6826,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
|
||||
<xs:element name='item-forbidden' type='empty'/>
|
||||
<xs:element name='item-required' type='empty'/>
|
||||
<xs:element name='jid-required' type='empty'/>
|
||||
<xs:element name='max-items-exceeded' type='empty'/>
|
||||
<xs:element name='max-nodes-exceeded' type='empty'/>
|
||||
<xs:element name='nodeid-required' type='empty'/>
|
||||
<xs:element name='not-in-roster-group' type='empty'/>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user