[Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))
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
> 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
> 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...
Size: 833 bytes
Desc: not available
More information about the Standards