<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus <span dir="ltr"><<a href="mailto:flo@geekplace.eu" target="_blank">flo@geekplace.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The discussion drifted a bit into whether non-stanza top-level stream<br>
elements should be used for a particular use case/XEP<br>
or not. But what I really wanted to discuss is whether they could be<br>
used after resource binding in general, or if this should be disallowed.<br>
That's why I asked the council members to express their opinion on this<br>
in their next meeting.<br>
<br>
As side note: I still think it is advantageous to have a unambiguous<br>
term defined for non-stanza top-level stream elements. It would clearly<br>
distinguish stanzas from non-stanzas in specifications and may help to<br>
avoid the case where specification authors erroneously refer to<br>
non-stanzas as stanzas. See for example the EXI XEP (XEP-322) where this<br>
is done (nearly?) everywhere. Not to mention that this may cause<br>
confusion when we take XEP-198: Stream Management into consideration.<br>
<span class=""><font color="#888888"><br>
- Florian<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Some thoughts: In the Prosody XMPP server implementation, we classify top-level elements into two categories: stanzas, and non-stanzas (nonzas!). We call non-stanzas 'elements'. Interestingly, stanzas sent before a bind are categorized with non-stanzas, given how different they are from normal stanzas (several normally expected invariants don't hold for them, e.g., no reliable 'from' attribute). The bind stanza is special, and is almost a third category (it awkwardly exists in this space between having a username and not having a resource).</div><div class="gmail_extra"><br></div><div class="gmail_extra">These three categories require different sets of validation.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Normally we expect non-stanzas to be purely affecting the state of a specific stream, and they don't have any affect beyond that. Stanzas typically do not affect the stream itself. The exceptions make code awkward, and the main (only?) one is the bind IQ (which we are forced to special case).</div><div class="gmail_extra"><br></div><div class="gmail_extra">This all has actual architectural implications: stream features can be consumed by XMPP proxies (BOSH/websocket components, TLS unwrapping proxies, other edge server scenarios), while non-stanzas are passed through to the XMPP core/router. The idea of XMPP reverse proxies has very interesting deployment implications, and something we have experimented with.</div><div class="gmail_extra"><br></div><div class="gmail_extra">--</div><div class="gmail_extra">Waqas Hussain</div><div class="gmail_extra"><br></div></div>