<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Nov 2019 at 18:46, Florian Schmaus <<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 25.11.19 14:16, Dave Cridland wrote:<br>
> As a general rule, I think clients need to try and preserve¬†unknown XML<br>
> nodes in data they manipulate. This goes for PEP data, roster data, and<br>
> all sorts.<br>
<br>
I don't share that sentiment. Clearly XMPP entities need to simply<br>
ignore unknown extension elements if they are just consuming them. But<br>
in cases where entities are modifying elements, like roster data,<br>
demanding that they have to replay also all unknown extension elements<br>
is, among other things, dangerous: One rotten apple could destroy the<br>
whole batch. That is, one misbehaving client could ruin everything. That<br>
is why I hope that we will never put extension elements in roster<br>
<item/>s that the client needs to replay [1].<br>
<br>
In such cases I instead favour the approach Emmanuel suggests: clearly<br>
define extension points and explicitly state the requirement to<br>
handle/preserve unknown XML in the specification.<br><br></blockquote><div><br></div><div>OK - I disagree, but I also think this is an acceptable compromise.</div><div><br></div><div>Should server-generated metadata also have a container element, so that clients know it can be ignored and must not be replayed?</div><div><br></div><div>Should these elements be generic elements, common across all cases, or do we make them individually each time?</div><div><br></div><div>Dave.¬†<br></div></div></div>