On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus <[email protected]> wrote:
> The discussion drifted a bit into whether non-stanza top-level stream > elements should be used for a particular use case/XEP > or not. But what I really wanted to discuss is whether they could be > used after resource binding in general, or if this should be disallowed. > That's why I asked the council members to express their opinion on this > in their next meeting. > > As side note: I still think it is advantageous to have a unambiguous > term defined for non-stanza top-level stream elements. It would clearly > distinguish stanzas from non-stanzas in specifications and may help to > avoid the case where specification authors erroneously refer to > non-stanzas as stanzas. See for example the EXI XEP (XEP-322) where this > is done (nearly?) everywhere. Not to mention that this may cause > confusion when we take XEP-198: Stream Management into consideration. > > - Florian > > 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). These three categories require different sets of validation. 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). 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. -- Waqas Hussain
