[Standards] Bookmarks 2 extensibility

Dave Cridland dave at cridland.net
Mon Dec 9 17:49:58 UTC 2019


On Wed, 4 Dec 2019 at 21:07, Florian Schmaus <flo at geekplace.eu> wrote:

> 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.
>
>
I think the summary, then, is that:

* Some elements are part of the core specification and must always be
preserved.
* Some elements are private client extensions and must be preserved
unchanged by other clients.
* Some elements are server-driven extensions and should not be preserved
explicitly by the client, and may be ignored.

My gut feeling is that the latter two ought to sit in a container element,
to provide the most flexible solution.

If that sounds right, I'll prepare a PR.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191209/da644aa9/attachment.html>


More information about the Standards mailing list