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

Maxime Buquet pep at bouah.net
Mon Feb 3 13:52:31 UTC 2020

My answer is a mix of what Sam, Daniel, and lovetox say. :)

> 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?


> 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 not implemented it yet, but I would.

As this spec allows to handle bookmarks separately, it's easier to
handle group/Enterprise(tm) bookmarks. The server can return an
appropriate answer for a specific bookmark and not reject an update on
the whole list without any hint.

I also don't understand why the password field has been removed, same as
lovetox. While I might agree with a push towards using MUC member-only
rooms (I would think that's the intent?), I don't think we're there yet.
Password-MUCs are still a reality, and also still used in transports.

While a password field could be added to the XEP, I'm curious if
anything happened around the issue Link Mauve raised a few weeks ago
about allowing for a extensions in the XEP? This would avoid having to
rewrite an entire bookmark XEP everytime we think about a new feature.

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

As Daniel says, it would be good to mention PEP access_model in security

> 5. Is the specification accurate and clearly written?

I agree with Sam in saying that the last part of the title is silly,
does not add any value, and makes it harder to cite. I like my XEPs dull
and straight to the point.

On Sunday, 30. January 2020 08:45:22 CET Daniel Gultsch wrote:
> 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
> XEP.
> 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.

I agree. (and jonas' answer in the thread looks closer to the intent of
the XEP already).

Maxime “pep” Buquet
-------------- 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/20200203/c3af93e7/attachment.sig>

More information about the Standards mailing list