[Standards] Bookmarks 2 extensibility

Florian Schmaus flo at geekplace.eu
Tue Nov 26 18:46:43 UTC 2019

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.

- Florian

1: Without prior negotiation that is. It may be approachable that
compatible clients signal support for <extensions/> in roster <item/>,
while legacy clients to do see that extra data.

> 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.
> Dave.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191126/ec590d03/attachment.sig>

More information about the Standards mailing list