[Standards] Nonzas: What are they and do we need them?

Waqas Hussain waqas20 at gmail.com
Thu Apr 23 00:35:24 UTC 2015

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).

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

Waqas Hussain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150422/2d15049a/attachment.html>

More information about the Standards mailing list