Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer <jo...@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@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? Yes. > 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 read.) > 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 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. cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
