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

Georg Lukas georg at op-co.de
Wed Feb 12 16:54:09 UTC 2020

* Jonas Schäfer <jonas at wielicki.name> [2020-01-29 17:34]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes, it's a significant improvement over existing bookmarks.

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

Yes, mostly (see below).

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


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

As stated before, the publish-options need a very prominent mention.

> 5. Is the specification accurate and clearly written?

As was written before, the password should be re-added for backward

Furthermore, I'm missing the following things:

RECOMMENDED name attribute: in past bookmark specifications, this
has led to clients or servers filling the `name` field with the
localpart of the room JID, which made it impossible for the receiving
client to determine whether this is a user-configured name that just
randomly happens to be equal to the localpart, or if it is the "default"
value and the client rather should display the disco#info name of the
room. Please make the name OPTIONAL instead, and add clear advise to
developers that it shall only be populated by the user, not

<nick/> element: please add implementation notes that a client should
only populate this element if the nickname is different from the
XEP-0172/PEP value, and that when receiving a bookmark without the
nickname, the client SHOULD fall back to the XEP-0172/PEP value.

Persistence: certain PEP implementations from the past, which are still
distributed by major OS platforms, chose to implement PEP in a
non-persistent way, only keeping data in RAM. I know we are deep in
implementation-defined behavior territory here, but a warning to
developers might be appropriate.

Backward compatibility:

First, the wording in the Compatibility section is not very clear:

| A server MAY choose to unify the bookmarks from both Private XML
| Storage (XEP-0049) [2] based and the current Bookmark Storage (XEP-0048)
| [1].

Does that mean that Private XML will be merged into PEP-Bookmarks, but
neither into Bookmarks2? Or is that related to the following statement?
Or the multiple following statements?

Second, I'd like to see better hints to client developers regarding how
to make use of the different server-side capability scenarios.

on a server that doesn't support PEP/publish-options: use 0049

on a server that supports urn:xmpp:bookmarks:0#compat*: use 0402

on a server that just supports 0049 and PEP: ???

I wanted to suggest that a server implementing 0402 must mandatorily
implement both compat mechanisms, but it looks like 0402 doesn't have a
feature var and doesn't depend on explicit server support anyway, so
this point would be moot. However, I'm not sure how to best proceed from

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200212/3209bda8/attachment.sig>

More information about the Standards mailing list