Georg, On Wed, 12 Feb 2020 at 16:54, Georg Lukas <ge...@op-co.de> wrote:
> * Jonas Schäfer <jo...@wielicki.name> [2020-01-29 17:34]: > > 1. Is this specification needed to fill gaps in the XMPP protocol > > stack or to clarify an existing protocol? > > Yes, it's a significant improvement over existing bookmarks. > > > 2. Does the specification solve the problem stated in the introduction > > and requirements? > > Yes, mostly (see below). > > > 3. Do you plan to implement this specification in your code? If not, > > why not? > > Yes. > > > 4. Do you have any security concerns related to this specification? > > As stated before, the publish-options need a very prominent mention. > > > 5. Is the specification accurate and clearly written? > > As was written before, the password should be re-added for backward > compatibility. > > Furthermore, I'm missing the following things: > > > RECOMMENDED name attribute: in past bookmark specifications, this > has led to clients or servers filling the `name` field with the > localpart of the room JID, which made it impossible for the receiving > client to determine whether this is a user-configured name that just > randomly happens to be equal to the localpart, or if it is the "default" > value and the client rather should display the disco#info name of the > room. Please make the name OPTIONAL instead, and add clear advise to > developers that it shall only be populated by the user, not > automatically. > > > Done. > <nick/> element: please add implementation notes that a client should > only populate this element if the nickname is different from the > XEP-0172/PEP value, and that when receiving a bookmark without the > nickname, the client SHOULD fall back to the XEP-0172/PEP value. > > Done. > > Persistence: certain PEP implementations from the past, which are still > distributed by major OS platforms, chose to implement PEP in a > non-persistent way, only keeping data in RAM. I know we are deep in > implementation-defined behavior territory here, but a warning to > developers might be appropriate. > > No idea what to say here. Feels like "Clients are RECOMMENDED to use servers which are not totally shit". > > Backward compatibility: > > First, the wording in the Compatibility section is not very clear: > > | A server MAY choose to unify the bookmarks from both Private XML > | Storage (XEP-0049) [2] based and the current Bookmark Storage (XEP-0048) > | [1]. > > Does that mean that Private XML will be merged into PEP-Bookmarks, but > neither into Bookmarks2? Or is that related to the following statement? > Or the multiple following statements? > > "from both" suggests "to this" as well. But "text welcome". > Second, I'd like to see better hints to client developers regarding how > to make use of the different server-side capability scenarios. > > on a server that doesn't support PEP/publish-options: use 0049 > > on a server that supports urn:xmpp:bookmarks:0#compat*: use 0402 > > on a server that just supports 0049 and PEP: ??? > > I wanted to suggest that a server implementing 0402 must mandatorily > implement both compat mechanisms, but it looks like 0402 doesn't have a > feature var and doesn't depend on explicit server support anyway, so > this point would be moot. However, I'm not sure how to best proceed from > here. > Me neither - as before, "text welcome". > > > Georg > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
