[Standards] Bookmarks 2 extensibility

Emmanuel Gil Peyrot linkmauve at linkmauve.fr
Mon Nov 25 13:27:46 UTC 2019


On Mon, Nov 25, 2019 at 01:16:48PM +0000, Dave Cridland wrote:
> 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.

Do you think about XEP-0322 for instance, where the c2s link can (in
some cases AIUI) be entirely unable of transmitting unknown information?

Would it make sense to forbid such an implementation from writing to the
XEP-0402 bookmarks?

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

That’s the current status quo, and it’s quite meh.

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

That sounds like a better idea, thanks.

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

I think it’d be better to spec that than to rely on thinking and hoping,
because I’ve seen many clients (and some servers) over the years discard
everything they didn’t understand when overriding an item.

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

Hmm, one of the usecases would be to support the <password/> element of
XEP-0048, which really doesn’t make sense to have been removed, for the
very few rooms that use it it is extremely useful (otherwise a client
would have to ask the user everytime it restarts, not in any way
user-friendly).

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

Indeed, but given that no client could rely on XEP-0048 bookmarks
preserving their private extensions, I’d rather spec that in XEP-0402
before it gets a lot of implementations.  Because a single one not doing
so would prevent every other one from using extensions.

> 
> Dave.

I’ll attempt to write some text in the following days, thanks.

-- 
Emmanuel Gil Peyrot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191125/cfc2ab75/attachment.sig>


More information about the Standards mailing list