moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0060: correct "entity" to "<subscription/>"

Browse Source 
The <entity/> element has been replaced with the <subscription/> element
since at least version 1.8. Text in several sections is updated to use
the <subscription/> element, making it consistent with the XML snippets.

Ref: https://mail.jabber.org/pipermail/standards/2018-July/035282.html

Signed-off-by: Melvin Vermeeren <mail@mel.vin>
This commit is contained in:
Melvin Vermeeren 2018-08-02 21:38:53 +02:00
parent bdc28943ad
commit a50a31c664
No known key found for this signature in database
GPG Key ID: 462C109D3AC7B859
1 changed files with 15 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0060.xml
View File

@ -50,6 +50,14 @@
&stpeter;
&ralphm;
<revision>
<version>1.15.3</version>
<date>2018-08-02</date>
<initials>mv</initials>
<remark>
<p>Correct several "entity element(s)" to "&lt;subscription/&gt; element(s)"</p>
</remark>
</revision>
<revision>
<version>1.15.2</version>
<date>2018-05-14</date>
@ -1544,7 +1552,7 @@ And by opposing end them?
</section3>
<section3 topic='Multiple Subscriptions' anchor='subscriber-subscribe-multi'>
<p>An entity may wish to subscribe using different subscription options, which it can do by subscribing multiple times to the same node. Support for this feature ("multi-subscribe") is OPTIONAL.</p>
<p>If multiple subscriptions for the same JID are allowed, the service MUST use the 'subid' attribute to differentiate between subscriptions for the same entity (therefore the SubID MUST be unique for each node+JID combination and the SubID MUST be present on the entity element any time it is sent to the subscriber). It is NOT RECOMMENDED for clients to generate SubIDs, since collisions might result; therefore a service SHOULD generate the SubID on behalf of the subscriber and MAY overwrite SubIDs if they are provided by subscribers. If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved).</p>
<p>If multiple subscriptions for the same JID are allowed, the service MUST use the 'subid' attribute to differentiate between subscriptions for the same entity (therefore the SubID MUST be unique for each node+JID combination and the SubID MUST be present on the &lt;subscription/&gt; element any time it is sent to the subscriber). It is NOT RECOMMENDED for clients to generate SubIDs, since collisions might result; therefore a service SHOULD generate the SubID on behalf of the subscriber and MAY overwrite SubIDs if they are provided by subscribers. If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved).</p>
<p>When the pubsub service generates event notifications, it SHOULD send only one event notification to an entity that has multiple subscriptions, rather than one event notification for each subscription. By "entity" here is meant the JID specified for the subscription, whether bare JID or full JID; however, if the same bare JID has multiple subscriptions but those subscriptions are for different full JIDs (e.g., one subscription for user@domain.tld./foo and another subscription for user@domain.tld/bar), the service MUST treat those as separate JIDs for the purpose of generating event notifications.</p>
</section3>
<section3 topic='Receiving the Last Published Item' anchor='subscriber-subscribe-last'>
@ -4489,7 +4497,7 @@ And by opposing end them?
</section5>
</section4>
<section4 topic='Multiple Simultaneous Modifications' anchor='owner-subscriptions-multi'>
<p>The owner MAY change multiple subscriptions in a single request. If one of the entity elements specified is invalid, the service MUST return an IQ error (which SHOULD be &notacceptable;) with the invalid entries, where the subscription returned is the original, un-altered subscription.</p>
<p>The owner MAY change multiple subscriptions in a single request. If one of the &lt;subscription/&gt; elements specified is invalid, the service MUST return an IQ error (which SHOULD be &notacceptable;) with the invalid entries, where the subscription returned is the original, un-altered subscription.</p>
<example caption='Owner sets subscription for multiple entities'><![CDATA[
<iq type='set'
from='hamlet@denmark.lit/elsinore'
@ -4518,7 +4526,7 @@ And by opposing end them?
</error>
</iq>
]]></example>
<p>If errors occur during a modification request for multiple entities, the pubsub service MUST return any &lt;subscription/&gt; element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'subscription' attribute. Any entity elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MAY specify multiple &lt;subscription/&gt; elements for the same entity, but each element MUST possess a distinct value of the 'subid' attribute.</p>
<p>If errors occur during a modification request for multiple entities, the pubsub service MUST return any &lt;subscription/&gt; element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'subscription' attribute. Any &lt;subscription/&gt; elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MAY specify multiple &lt;subscription/&gt; elements for the same entity, but each element MUST possess a distinct value of the 'subid' attribute.</p>
</section4>
</section3>
<section3 topic='Delete a Subscriber' anchor='owner-subscriptions-delete'>
@ -4704,7 +4712,7 @@ And by opposing end them?
</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 &notacceptable;) with the invalid entries, where the affiliation returned is the original, un-altered affiliation.</p>
<p>The owner MAY change multiple affiliations in a single request. If one of the &lt;subscription/&gt; elements specified is invalid, the service MUST return an IQ error (which SHOULD be &notacceptable;) 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'
@ -4735,7 +4743,7 @@ And by opposing end them?
</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 &lt;affiliation/&gt; 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 &lt;affiliation/&gt; elements for the same entity; otherwise the service MUST return a &badrequest; error.</p>
<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 &lt;affiliation/&gt; element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'affiliation' attribute. Any &lt;subscription/&gt; elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MUST NOT specify multiple &lt;affiliation/&gt; elements for the same entity; otherwise the service MUST return a &badrequest; error.</p>
</section4>
</section3>
<section3 topic='Delete an Entity' anchor='owner-affiliations-delete'>
@ -7225,7 +7233,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Kirk Bateman, Robin Collier, Blaine Cook, Ovidiu Craciun, Brian Cully, Dave Cridland, Guillaume Desmottes, Gaston Dombiak, William Edney, Seth Fitzsimmons, Fabio Forno, Nathan Fritz, Julien Genestoux, Anastasia Gornostaeva, Joe Hildebrand, Curtis King, Tuomas Koski, Petri Liimatta, Tobias Markmann, Pedro Melo, Dirk Meyer, Tory Patnoe, Peter Petrov, Sonny Piers, Christophe Romain, Pavel Šimerda, Andy Skelton, Kevin Smith, Chris Teegarden, Simon Tennant, Matt Tucker, Matthew Wild, Bob Wyman, Matus Zamborsky, and Brett Zamir for their feedback.</p>
<p>Thanks to Kirk Bateman, Robin Collier, Blaine Cook, Ovidiu Craciun, Brian Cully, Dave Cridland, Guillaume Desmottes, Gaston Dombiak, William Edney, Seth Fitzsimmons, Fabio Forno, Nathan Fritz, Julien Genestoux, Anastasia Gornostaeva, Joe Hildebrand, Curtis King, Tuomas Koski, Petri Liimatta, Tobias Markmann, Pedro Melo, Dirk Meyer, Tory Patnoe, Peter Petrov, Sonny Piers, Christophe Romain, Pavel Šimerda, Andy Skelton, Kevin Smith, Chris Teegarden, Simon Tennant, Matt Tucker, Melvin Vermeeren, Matthew Wild, Bob Wyman, Matus Zamborsky, and Brett Zamir for their feedback.</p>
</section1>
<section1 topic='Author Note' anchor='authornote'>