[Standards] Bookmarks 2 extensibility

Florian Schmaus flo at geekplace.eu
Wed Dec 4 21:06:17 UTC 2019

On 26.11.19 20:48, Dave Cridland wrote:
> On Tue, 26 Nov 2019 at 18:46, Florian Schmaus <flo at geekplace.eu
> <mailto: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?

Good questions. I do not have a strong opinion regarding the answer.
Mostly because I can not come up with an example or reason that
demonstrates that there is value in having a generic element or a
container element for server-generated metadata. That does not mean that
such a thing does not exists though.

- Florian

-------------- 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/20191204/6b42aab6/attachment.sig>

More information about the Standards mailing list