From e074a99d817a57c60c714605329ab28966a986fb Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Sat, 28 Sep 2019 19:45:06 +0200 Subject: [PATCH] XEP-0402: Fix inconsistent indent in examples. --- xep-0402.xml | 88 ++++++++++++++++++++++++++-------------------------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/xep-0402.xml b/xep-0402.xml index c329fb71..7a97b091 100644 --- a/xep-0402.xml +++ b/xep-0402.xml @@ -16,7 +16,7 @@ Standards Council - XEP-0223 + XEP-0223 @@ -102,7 +102,7 @@ - Puck + Puck ]]>

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'.

@@ -128,16 +128,16 @@ ]]> - +

Once connected, a client SHOULD first retrieve the current list of bookmarks:

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.

- - - + + + ]]> - - - - - JC - - - - - - - http://jabber.org/protocol/pubsub#publish-options - - - true - - - 10000 - - - never - - - whitelist - - - - + + + + + JC + + + + + + + http://jabber.org/protocol/pubsub#publish-options + + + true + + + 10000 + + + never + + + whitelist + + + + ]]>

Removing a bookmark means retracting an existing item, identified by the bookmark's JID, form the '&namespace;' node.

This implies that server support for the "delete-items" pubsub feature is REQUIRED.

-

A 'notify' attribute SHOULD be included on the <retract/> element in order to inform other online clients of the deletion.

+

A 'notify' attribute SHOULD be included on the <retract/> element in order to inform other online clients of the deletion.

- - - - - + + + + + ]]> ]]> -

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.

+

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.

@@ -276,7 +276,7 @@

A server MAY choose to unify the bookmarks from both &xep0049; based and the current &xep0048;.

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.

-

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;.

+

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;.

A server that supports unifying bookmarks between &xep0223; and &xep0402; SHOULD announce the "urn:xmpp:bookmarks:0#compat-pep" feature on the account.

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;