diff --git a/inbox/bookmarks2.xml b/inbox/bookmarks2.xml index cee29979..f4edd4fc 100644 --- a/inbox/bookmarks2.xml +++ b/inbox/bookmarks2.xml @@ -83,113 +83,29 @@
Note: The datatypes are as defined in &w3xmlschema2;.
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'.
Note that a bookmark item MUST contain only one conference room.
Note also that a conference element has no truly mandatory attributes or child elements, though a name SHOULD be given. Thus the following is legal:
Adding a bookmark means publishing a new item, with the bookmark JID as id, to the '&namespace;' node.
- -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.
- -When a client is sent an event from the Pubsub service for the '&namespace;' node, it MUST check the 'autojoin' attribute if present, and join the room immediately if the attribute is both present and true.
&xep0060; is used for data storage, specifically through the use of private, personal pubsub nodes (described in &xep0223;) hosted at the user's virtual pubsub service (see &xep0163;).
-A server MAY choose to unify the bookmarks from both &xep0049; based and the current &xep0048;.
Security considerations related to object persistence via publish-subscribe are described in XEP-0060 and XEP-0223.
-The client needs to make sure that the server actually supports the "http://jabber.org/protocol/pubsub#publish-options" feature, before relying on it. If it's not supported, the client should configure the '&namespace;' node first (see xep-0060), before adding any bookmarks.
+The password child element of conference is well known to provide only very weak levels of security; storing it in bookmarks lowers this security still further.
Note: The datatypes are as defined in &w3xmlschema2;.
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'.
Note that a bookmark item MUST contain only one conference room.
Note also that a conference element has no truly mandatory attributes or child elements, though a name SHOULD be given. Thus the following is legal:
Adding a bookmark means publishing a new item, with the bookmark JID as id, to the '&namespace;' node.
+ +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.
+ +When a client is sent an event from the Pubsub service for the '&namespace;' node, it MUST check the 'autojoin' attribute if present, and join the room immediately if the attribute is both present and true.
&xep0060; is used for data storage, specifically through the use of private, personal pubsub nodes (described in &xep0223;) hosted at the user's virtual pubsub service (see &xep0163;).
+A server MAY choose to unify the bookmarks from both &xep0049; based and the current &xep0048;.
The password child element of conference is well known to provide only very weak levels of security; storing it in bookmarks lowers this security still further.
+Security considerations related to object persistence via publish-subscribe are described in XEP-0060 and XEP-0223.
+The client needs to make sure that the server actually supports the "http://jabber.org/protocol/pubsub#publish-options" feature, before relying on it. If it's not supported, the client should configure the '&namespace;' node first (see xep-0060), before adding any bookmarks.