[Standards] Nonzas: What are they and do we need them?
zash at zash.se
Thu Apr 23 07:52:12 UTC 2015
tors apr 23 02:35:24 2015 GMT+0200 skrev Waqas Hussain:
> On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus <flo at 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
More information about the Standards