[Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

Daniel Gultsch daniel at gultsch.de
Thu Jan 30 07:45:22 UTC 2020

Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer <jonas at wielicki.name>:
> This message constitutes notice of a Last Call for comments on
> XEP-0402.
> Title: Bookmarks 2 (This Time it's Serious)
> Abstract:
> This specification defines a syntax and storage profile for keeping a
> list of chatroom bookmarks on the server.
> URL: https://xmpp.org/extensions/xep-0402.html
> This Last Call begins today and shall end at the close of business on
> 2020-02-12.
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Not really. But it is arguably a better solution to bookmarks than '48.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?


> 3. Do you plan to implement this specification in your code? If not,
> why not?

I have an implementation that is currently guarded behind a compile time flag.

I would like to migrate to Bookmarks 2 because adds and deletes are
atomic operations.
In the past I had problems with users deleting 3 bookmarks (from 48
pep) in quick succession. And after deleting the 3 bookmark the
notification for deleting the 1 bookmark would come in and essentially
re-add bookmark #2 back to the list.
This can probably be worked around in the client be maintaining a
deletion queue or something (That reminds me to actually implement
that in Conversations) but it is probably very cumbersome.

Also '48 doesn’t cover immutable server injected bookmarks very well
since it is unspecified what would happen if the user attempts to
delete one; Will the server silently re-add the bookmark? Will it
reject the change?
With 402 the server could just reject the specific delete.

> 4. Do you have any security concerns related to this specification?

In the past we had multiple server- and client-side bugs with PEP that
would accidentally make those bookmarks public to everyone.

The security considerations need to be much more explicit about
publish-options and the bad things that happen if you don’t use it.
(and not just vaguely point to two other XEPs that nobody is going to

> 5. Is the specification accurate and clearly written?

I share Sam’s concerns regarding the title.

Maybe the benefits of Bookmarks 2 over Bookmarks need to be spelled
out more. Otherwise neither developers (as demonstrated by Phililpp)
nor the approving body will know why they should use or accept this

The arguments for 402 I'm raising above are good; but I don’t want to
personally tell them to every developer in order to convince them.
That's the XEPs job.


More information about the Standards mailing list