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 [email protected] discussion list: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes > 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 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 concerns. > 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
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
