[Standards] Bookmarks 2 extensibility

Jonas Schäfer jonas at wielicki.name
Mon Nov 25 12:25:39 UTC 2019

On Sonntag, 24. November 2019 10:11:06 CET Emmanuel Gil Peyrot wrote:
> Hello standards@,
> One of the issues with 0048 bookmarks was that any extension to a
> bookmark was possibly removed by another client which didn’t know what
> to do with it.
> I’d like to achieve something better for bookmarks 2, so that clients
> can attach private or shared extensions and compatible clients can read
> them, while non-compatible clients would ignore them.
> Some examples I’ve seen in the wild include Gajim serialising the room’s
> state (whether it’s minimised in the roster), some clients storing tags
> or a hierarchical structure for easier searching.  All of those are
> usecases that hadn’t been thought about for the first bookmarks version,
> and that’s fine as long as we can extend it.
> I’m suggesting adding a <{bookmarks:0}extensions/> element inside the
> <{bookmarks:0}conference/>, where clients and servers alike MUST
> preserve the content if they don’t understand it.  Any downside to this
> approach?

The only obvious downside is that some entities may discard unknown data early 
in their stack for whatever reasons; I think you can actually get away with 
that in all cases (possibly except XHTML-IM) so far. Those entities might then 
have to change a considerable part of their deserialisation stack.

However, I’m not sure if there even is a viable alternative. It would be 
possible to use additional PEP nodes, but then the entities managing them 
would have to take care to update them when the original node updates and 
things may easily get out of sync. So keeping the data in the same node makes 

The only thing I wonder is: Why an extra sub-element? This reminds me of the 
`X-` prefix which has since been deprecated. We *do* have namespacing in XML, 
let’s make use of that. Simply state that all unknown child elements of the 
<{bookmarks:0}conference/> element must be preserved; no need to stuff it away 
in an extra element.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191125/c0cba62a/attachment.sig>

More information about the Standards mailing list