moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2025-02-07 02:40:22 -05:00
Code Issues Releases Wiki Activity

XEP-0402: Fix inconsistent indent in examples.

Browse Source
This commit is contained in:
Emmanuel Gil Peyrot 2019-09-28 19:45:06 +02:00
parent c6d68207e7
commit e074a99d81
1 changed files with 44 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
xep-0402.xml
View File

@ -16,7 +16,7 @@
<sig>Standards</sig> <sig>Standards</sig>
<approver>Council</approver> <approver>Council</approver>
<dependencies> <dependencies>
<spec>XEP-0223</spec> <spec>XEP-0223</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
@ -102,7 +102,7 @@
<conference xmlns=']]>&namespace;<![CDATA[' <conference xmlns=']]>&namespace;<![CDATA['
name='Council of Oberon' name='Council of Oberon'
autojoin='true'> autojoin='true'>
<nick>Puck</nick> <nick>Puck</nick>
</conference> </conference>
]]></example> ]]></example>
<p>This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.</p> <p>This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.</p>
@ -128,16 +128,16 @@
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Retrieving all bookmarks' anchor='retrieving-bookmarks'> <section2 topic='Retrieving all bookmarks' anchor='retrieving-bookmarks'>
<p>Once connected, a client SHOULD first retrieve the current list of bookmarks:</p> <p>Once connected, a client SHOULD first retrieve the current list of bookmarks:</p>
<p>NOTE: A future version of this specification might refer to &xep0312; or a similar protocol to reduce the need for full synchronisation on each connection.</p> <p>NOTE: A future version of this specification might refer to &xep0312; or a similar protocol to reduce the need for full synchronisation on each connection.</p>
<example caption='Client retrieves all bookmarks'><![CDATA[ <example caption='Client retrieves all bookmarks'><![CDATA[
<iq from='juliet@capulet.lit/balcony' type='get' id='retrieve1'> <iq from='juliet@capulet.lit/balcony' type='get' id='retrieve1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:bookmarks:0'/> <items node='urn:xmpp:bookmarks:0'/>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server returns the bookmarks'><![CDATA[ <example caption='Server returns the bookmarks'><![CDATA[
@ -171,36 +171,36 @@
<example caption='Client adds a new bookmark'><![CDATA[ <example caption='Client adds a new bookmark'><![CDATA[
<iq from='juliet@capulet.lit/balcony' type='set' id='pip1'> <iq from='juliet@capulet.lit/balcony' type='set' id='pip1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:bookmarks:0'> <publish node='urn:xmpp:bookmarks:0'>
<item id='theplay@conference.shakespeare.lit'> <item id='theplay@conference.shakespeare.lit'>
<conference xmlns=']]>&namespace;<![CDATA[' <conference xmlns=']]>&namespace;<![CDATA['
name='The Play&apos;s the Thing' name='The Play&apos;s the Thing'
autojoin='true'> autojoin='true'>
<nick>JC</nick> <nick>JC</nick>
</conference> </conference>
</item> </item>
</publish> </publish>
<publish-options> <publish-options>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'> <field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#publish-options</value> <value>http://jabber.org/protocol/pubsub#publish-options</value>
</field> </field>
<field var='pubsub#persist_items'> <field var='pubsub#persist_items'>
<value>true</value> <value>true</value>
</field> </field>
<field var='pubsub#max_items'> <field var='pubsub#max_items'>
<value>10000</value> <value>10000</value>
</field> </field>
<field var='pubsub#send_last_published_item'> <field var='pubsub#send_last_published_item'>
<value>never</value> <value>never</value>
</field> </field>
<field var='pubsub#access_model'> <field var='pubsub#access_model'>
<value>whitelist</value> <value>whitelist</value>
</field> </field>
</x> </x>
</publish-options> </publish-options>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges successful storage'><![CDATA[ <example caption='Server acknowledges successful storage'><![CDATA[
@ -211,15 +211,15 @@
<section2 topic='Removing a bookmark' anchor='removing-a-bookmark'> <section2 topic='Removing a bookmark' anchor='removing-a-bookmark'>
<p>Removing a bookmark means retracting an existing item, identified by the bookmark's JID, form the '&namespace;' node.</p> <p>Removing a bookmark means retracting an existing item, identified by the bookmark's JID, form the '&namespace;' node.</p>
<p>This implies that server support for the "delete-items" pubsub feature is REQUIRED.</p> <p>This implies that server support for the "delete-items" pubsub feature is REQUIRED.</p>
<p>A 'notify' attribute SHOULD be included on the &lt;retract/&gt; element in order to inform other online clients of the deletion.</p> <p>A 'notify' attribute SHOULD be included on the &lt;retract/&gt; element in order to inform other online clients of the deletion.</p>
<example caption='Client removes a new bookmark'><![CDATA[ <example caption='Client removes a new bookmark'><![CDATA[
<iq from='juliet@capulet.lit/balcony' type='set' id='remove-bookmark1'> <iq from='juliet@capulet.lit/balcony' type='set' id='remove-bookmark1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='urn:xmpp:bookmarks:0' notify='true'> <retract node='urn:xmpp:bookmarks:0' notify='true'>
<item id='theplay@conference.shakespeare.lit'/> <item id='theplay@conference.shakespeare.lit'/>
</retract> </retract>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges successful retraction'><![CDATA[ <example caption='Server acknowledges successful retraction'><![CDATA[
@ -249,7 +249,7 @@
</iq> </iq>
]]></example> ]]></example>
<p>On the other hand, if the 'autojoin' attribute is absent or false, or when the event is a retract notification, the client MUST leave the room.</p> <p>On the other hand, if the 'autojoin' attribute is absent or false, or when the event is a retract notification, the client MUST leave the room.</p>
<example caption='Client receives a bookmark retraction notification'><![CDATA[ <example caption='Client receives a bookmark retraction notification'><![CDATA[
<message from='juliet@capulet.lit' to='juliet@capulet.lit/balcony' type='headline' id='removed-room1'> <message from='juliet@capulet.lit' to='juliet@capulet.lit/balcony' type='headline' id='removed-room1'>
@ -276,7 +276,7 @@
<section2 topic="Compatibility"> <section2 topic="Compatibility">
<p>A server MAY choose to unify the bookmarks from both &xep0049; based and the current &xep0048;.</p> <p>A server MAY choose to unify the bookmarks from both &xep0049; based and the current &xep0048;.</p>
<p>It is encouraged to at least support unification between Private XML Storage because as of 2019 this is still the storage backend that is implemented in the majority of clients.</p> <p>It is encouraged to at least support unification between Private XML Storage because as of 2019 this is still the storage backend that is implemented in the majority of clients.</p>
<p>A server that supports unifying bookmarks from &xep0049; and &xep0402; SHOULD announce the "urn:xmpp:bookmarks:0#compat" feature on the account. Clients may use that feature as an indication that it is safe to store bookmarks using only &xep0402; without losing backward compatibility to clients that are only using &xep0049;.</p> <p>A server that supports unifying bookmarks from &xep0049; and &xep0402; SHOULD announce the "urn:xmpp:bookmarks:0#compat" feature on the account. Clients may use that feature as an indication that it is safe to store bookmarks using only &xep0402; without losing backward compatibility to clients that are only using &xep0049;.</p>
<p>A server that supports unifying bookmarks between &xep0223; and &xep0402; SHOULD announce the "urn:xmpp:bookmarks:0#compat-pep" feature on the account.</p> <p>A server that supports unifying bookmarks between &xep0223; and &xep0402; SHOULD announce the "urn:xmpp:bookmarks:0#compat-pep" feature on the account.</p>
<section3 topic="Publishing via this specification"> <section3 topic="Publishing via this specification">
<p>When a client publishes a new item, the server MAY collate all items, casting them into the 'storage:bookmarks' namespace and setting the jid attribute to the item id in each case. When contained within a storage element qualified by the 'storage:bookmarks' namespace, this will be the correct format for both current and previous variants of &xep0048;</p> <p>When a client publishes a new item, the server MAY collate all items, casting them into the 'storage:bookmarks' namespace and setting the jid attribute to the item id in each case. When contained within a storage element qualified by the 'storage:bookmarks' namespace, this will be the correct format for both current and previous variants of &xep0048;</p>