<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 31, 2009, at 8:59 PM, Peter Saint-Andre wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>I haven't yet had time (at least since the XMPP Summit last week) to<br>think more about this problem. We did a lot of work in the more recent<br>versions of XEP-0115 to maintain backward compatibility, and it would be<br>a shame to lose all that work now. But sometimes sunk costs are a fact<br>of life...<br></div></blockquote></div><br><div>Backward-compatibility is very important to me. &nbsp;There is a LOT of XEP-115 deployed out there. &nbsp;My preferences are:</div><div><br></div><div>1) characterize exactly the sorts of strings that lead to attack. &nbsp;Put wording in the XEP that allows detecting those attacks by disallowing certain combinations. &nbsp;I'm not sure if that's possible, but, for example, forbidding empty type attributes in identities might mitigate attacks 2 and 3.</div><div><br></div><div>2) add a new feature that sorts at the end, or a new extension that sorts at the front to signal the shift between features and extensions</div><div><br></div><div>3) move extensions to deprecated, and have everyone who sends extensions be viewed with suspicion. &nbsp;This is a distant last for me, since there were valid compromises that went into the inclusion of extensions in the first place. The last thing I want is for clients to go back to sending iq:version to everyone on the roster every time they receive presence.</div></body></html>