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

Dave Cridland dave at cridland.net
Thu Feb 13 19:31:11 UTC 2020


Georg,

On Wed, 12 Feb 2020 at 16:54, Georg Lukas <georg at op-co.de> wrote:

> * Jonas Schäfer <jonas at 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-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200213/6917946d/attachment.html>


More information about the Standards mailing list