[Standards] Nonzas: What are they and do we need them?
flo at geekplace.eu
Mon Apr 20 18:57:24 UTC 2015
On 20.04.2015 17:00, Georg Lukas wrote:
> * Florian Schmaus <flo at geekplace.eu> [2015-04-20 15:27]:
>> - Messages and IQs could be used instead
>> - Can't be used with BOSH
> As you pointed out below, they can be used in theory. I just assume that
> most implementations will not expect them and might break in subtle ways.
> IIRC, it required significant refactoring of the Smack XMPP library to
> accommodate them. I'm sure similar effort will be required in most other
> XMPP client and server implementations.
When I added support for SM to Smack I needed to define an internal API
for Nonzas anyway, i.e. there is now a "callback" (it's not really a
typical callback), which interested parties can consume when a Nonza
arrives. So you basically have the effort of adding support for Nonzas
in your XMPP stack anyways (as soon as you add support for SM).
>> - Introduces a bunch of conceptual and implementations problems
> One specific problem is that they can not be accounted for in XEP-0198,
> and therefore it is not clear if a Nonza got successfully delivered to
> the recipient in case of stream resumption. In the CSI discussion this
> caused confusion and led to the notion of resetting the CSI state on
> stream resumption, which looks like fixing the symptoms.
It appears the author(s) of CSI think of not keeping the CSI state as a
feature and specified the protocol that way intentionally, not as
workaround for Nonzas not being tracked by SM.
>> - Expresses the semantic that they are not routed
>> - This increases security, as they are harder to spoof
> I understand the first two points, but I'm not sure if they really
> outweigh the problems.
I think the advantages outweigh he problems. In fact, I think there are
no problems at all.
>> A. Nonzas MUST NOT be used after resource binding
> With the obvious exception of XEP-0198, of course.
Course, SM is fine as it is, And we all ♥ it (I really do). :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards