[Standards] Bookmarks 2 extensibility

Jonas Schäfer jonas at wielicki.name
Mon Nov 25 16:43:00 UTC 2019


On Montag, 25. November 2019 14:27:46 CET Emmanuel Gil Peyrot wrote:
> 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?

I’m thinking about implementations like aioxmpp which would by default discard 
elements which haven’t been declared explicitly in the internal schema. It 
does have ways to collect and re-emit elements (plus children) which are 
unknown in a generic way, but it needs to be explicitly requested on a parent 
node.

If a parser stack is *not* prepared to generate a generic representation of 
XML, it might run into trouble with this type of stuff.

kind regards,
Jonas
-------------- 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/6de1d415/attachment.sig>


More information about the Standards mailing list