[Standards] Bookmarks 2 extensibility

Dave Cridland dave at cridland.net
Tue Nov 26 19:48:19 UTC 2019

On Tue, 26 Nov 2019 at 18:46, Florian Schmaus <flo at geekplace.eu> wrote:

> On 25.11.19 14:16, Dave Cridland 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 don't share that sentiment. Clearly XMPP entities need to simply
> ignore unknown extension elements if they are just consuming them. But
> in cases where entities are modifying elements, like roster data,
> demanding that they have to replay also all unknown extension elements
> is, among other things, dangerous: One rotten apple could destroy the
> whole batch. That is, one misbehaving client could ruin everything. That
> is why I hope that we will never put extension elements in roster
> <item/>s that the client needs to replay [1].
> In such cases I instead favour the approach Emmanuel suggests: clearly
> define extension points and explicitly state the requirement to
> handle/preserve unknown XML in the specification.
OK - I disagree, but I also think this is an acceptable compromise.

Should server-generated metadata also have a container element, so that
clients know it can be ignored and must not be replayed?

Should these elements be generic elements, common across all cases, or do
we make them individually each time?

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

More information about the Standards mailing list