[Standards] Bookmarks 2 extensibility
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 .
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards