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

Dave Cridland dave at cridland.net
Thu Feb 13 19:02:39 UTC 2020


These are late Last Call comments, but seeing as I'm an author *and* on the
Council, I figured better late than never...

On Wed, 29 Jan 2020 at 16:33, Jonas Schäfer <jonas at wielicki.name> wrote:

> 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?
>
>
Yes; in as much as bookmarks are a bit broken and this is a cleaner design
(and one we have discussed for years prior to this).


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


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I'm not entirely sure that any bookmarks are, currently, relevant for my
work.


> 4. Do you have any security concerns related to this specification?
>
>
Re-adding the password means that MUC passwords are back, but that's a
reasonable compromise.


> 5. Is the specification accurate and clearly written?
>
>
While trying to apply the changes others have suggested, I noted that it
says that if autojoin is set to true on a notification of a change, a
client should join the chatroom - this seems reasonable - but if it's set
to false, a client should immediately leave. This latter seems unexpected.
Leaving a chatroom on a retraction seems OK, but I would have thought that
leaving when autojoin simply happens to be unset (and might never have been
set) seems wrong.

Your feedback is appreciated!
>

Overall, I think this needs another round of discussion; though I hope this
will be short.

I'll prepare a PR with the changes discussed.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200213/72e0f92d/attachment.html>


More information about the Standards mailing list