Our system uses privacy lists with fall-through rules that should deny everything except IQ packets. After migration from Smack 3.3.1 to Smack 4.0.6 we found that this functionality no longer works.
It turns our that since commit 61108720622dd16b5e15cdc2d20f513a6922d553 PrivacyProvider ignores child elements in fall-through items when parsing privacy lists. I cannot find any justification for this behavior in XEP-0016, therefore I think that it’s incorrect.
Thanks for reporting this interesting case. The XEP mentions indeed no restrictions. So you basically have
<item type=…
<item type=…
Is that correct?
The only thing that may hints that the fall-through item should have no child elements is hat in § 2.2 Business Rules
- If no fall-through item is provided in a list, the fall-through action is assumed to be “allow”.
But here we have a fall-through item, it is just only specified for message, presence-in and -out. Also the examples don’t show a fall-through with child items, but of course, they are not normative. I’m going to ask for feedback on the XMPP Summit in two weeks about this.
In the meantime, you could simply workaround by adding 4 itmes with those filters that match on the 4 possible subscription states. Not a nice solution, but the best I came up with.
Of course you could also simply replace the Provider.
I think the XML schema is clear on it, i.e. it allows XML like in your example, because it uses a xs:sequence
element. , , <presnce_in/out/> may each occur 0 or 1 time within the sequence.
Well the schema is only half of the specification.
I’ve looked on a few server implementations and they all understand fall-through with child elements. And since it’s also a useful feature, I’ve (re-)added parsing support for it and made a few other minor tweaks to Smack’s privacy code: Improve privacy parsing and API. Add NumberUtil · 476e1b7 · Flowdalic/Smack · GitHub