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

Waqas Hussain waqas20 at gmail.com
Thu Apr 23 17:12:52 UTC 2015


On Thu, Apr 23, 2015 at 3:52 AM, Kim Alvefur <zash at zash.se> wrote:

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

I'll add this to your point: bind is more awkward than dialback. While
dialback is awkward, it can relatively easily be isolated in the s2s and
dialback plugins in Prosody. Bind awareness however needs to be in the core
stanza router. In the XMPP layering violation contest, my vote goes to bind
:)

Inspecting stanza routers of different servers is actually quite
fascinating. You get to see all the more awkward parts of XMPP core.

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


More information about the Standards mailing list