[Standards] Bookmarks 2 extensibility

Dave Cridland dave at cridland.net
Mon Nov 25 13:16:48 UTC 2019

On Mon, 25 Nov 2019 at 12:26, Jonas Schäfer <jonas at wielicki.name> wrote:

> 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
> sense.
> 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.

I entirely agree with everything Jonas wrote.

As a general rule, I think clients need to try and preserve unknown XML
nodes in data they manipulate. This goes for PEP data, roster data, and all

By "unknown XML nodes" I generally mean elements in an unknown namespace.
Servers need to have an even broader view of what to preserve.

This is a specialization of the end-to-end principle, I think, or at the
very least it relates to it.

The effect of breaking this rule is that running one client can mess up
another, which feels like a Bad Thing, and has interoperability concerns
written all over it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191125/d58bbe40/attachment.html>

More information about the Standards mailing list