<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 7 April 2014 08:27, Steffen Larsen <span dir="ltr"><<a href="mailto:zooldk@gmail.com" target="_blank">zooldk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I completely agree about making XEP-0114 (external components) more suitable and secure like any other S2S scenario. Lifting it to a XMPP version 1.0 stage would be great, but would also break a lot of implementations.<br>
</blockquote><div><br></div><div>I'm not entirely sure. I've seen *some* implementations break when they receive stream features they weren't expecting, but most existing implementations don't send the version attribute, so won't get them.</div>
<div><br></div><div>So it'll break *some* implementations, and an implementation *might* want to offer component support on ports that suppress all features as a result. How widespread the problem would be is, I think, an unknown at this point.</div>
<div><br></div><div>The alternative is we just say "Components are privately-authenticated S2S connections", and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't backwards compatible with the older protocol, which becomes obsolete. That appeals to my sense of purity, and is likely significantly more secure in a number of ways. (At the very least, the security profile would be better understood).</div>
<div><br></div><div>Dave.</div></div></div></div>