The scope of message types rejected for offline storage is too broad

The patch in http://www.igniterealtime.org/issues/browse/JM-1435 prevents
messages with empty or absent s from being stored offline. JM-1435 was
applied at v 3.6.0.

The only discussion I could find precipitating the patch is at

This thread indicates the patch’s purpose is to filter out typing notification
messages, which makes sense. Unfortunately the patch unintentionally filters
out some messages that should be stored offline. These are typically app to
app type messages that comply with rfc3920 but do not use the im related
features described in rfc3921.

A good example is shown here: http://forum.ag-software.de/thread/760

In this case a weather sensor is sending a message to an aggregating app.

90 57

If the aggregating app is offline, the message should be stored offline and
delivered when the aggregating app comes back up. The suggested workaround was
to add a my weather extension element, but that workaround can be
problematic in app to app systems that use the field for specialized
purposes already.

The weather app protocol might use the element for command and control.
Maybe something like:

ratelimit 5

I found one other report on this issue at:

I am not familiar with the various ways that chat clients send typing
notification messages. Maybe the patch can filter specifically for these. A
simple config toggle to enable/disable the filtering this patch introduced would
suffice in my case.

Thanks,

Michael Keller