<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 Nov 2019 at 12:26, Jonas Schäfer <<a href="mailto:jonas@wielicki.name">jonas@wielicki.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sonntag, 24. November 2019 10:11:06 CET Emmanuel Gil Peyrot wrote:<br>
> Hello standards@,<br>
> <br>
> One of the issues with 0048 bookmarks was that any extension to a<br>
> bookmark was possibly removed by another client which didn’t know what<br>
> to do with it.<br>
> <br>
> I’d like to achieve something better for bookmarks 2, so that clients<br>
> can attach private or shared extensions and compatible clients can read<br>
> them, while non-compatible clients would ignore them.<br>
> <br>
> Some examples I’ve seen in the wild include Gajim serialising the room’s<br>
> state (whether it’s minimised in the roster), some clients storing tags<br>
> or a hierarchical structure for easier searching.  All of those are<br>
> usecases that hadn’t been thought about for the first bookmarks version,<br>
> and that’s fine as long as we can extend it.<br>
> <br>
> I’m suggesting adding a <{bookmarks:0}extensions/> element inside the<br>
> <{bookmarks:0}conference/>, where clients and servers alike MUST<br>
> preserve the content if they don’t understand it.  Any downside to this<br>
> approach?<br>
<br>
The only obvious downside is that some entities may discard unknown data early <br>
in their stack for whatever reasons; I think you can actually get away with <br>
that in all cases (possibly except XHTML-IM) so far. Those entities might then <br>
have to change a considerable part of their deserialisation stack.<br>
<br>
However, I’m not sure if there even is a viable alternative. It would be <br>
possible to use additional PEP nodes, but then the entities managing them <br>
would have to take care to update them when the original node updates and <br>
things may easily get out of sync. So keeping the data in the same node makes <br>
sense.<br>
<br>
The only thing I wonder is: Why an extra sub-element? This reminds me of the <br>
`X-` prefix which has since been deprecated. We *do* have namespacing in XML, <br>
let’s make use of that. Simply state that all unknown child elements of the <br>
<{bookmarks:0}conference/> element must be preserved; no need to stuff it away <br>
in an extra element.<br></blockquote><div><br></div><div>I entirely agree with everything Jonas wrote.</div><div><br></div><div>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.</div><div><br></div><div>By "unknown XML nodes" I generally mean elements in an unknown namespace. Servers need to have an even broader view of what to preserve.</div><div><br></div><div>This is a specialization of the end-to-end principle, I think, or at the very least it relates to it.</div><div><br></div><div>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.</div><div><br></div><div>Dave.</div></div></div>