tors apr 23 02:35:24 2015 GMT+0200 skrev Waqas Hussain: > On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus <f...@geekplace.eu> 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).
I would like to point out that dialback elements are also in an awkward space, being treated as stanzas when sending (being routed etc) and nonzas when receiving. -- Kim "Zash" Alvefur
