I have not implemented strict IQ type checking because there were Tigase deployments which used extended types for IQ stanzas and I did not want to break those. And I also think XMPP is just XML so the server should allow for just XML processing and bot being very strict.

However, the RFC requires strict IQ type checking and returning an error for an incorrect type. Therefore, I think we should have such a mode implemented in Tigase.

So the answer:

1. Yes, we should implement it

2. Yes, it should be ON by default

3. Yes, there should be a config option to switch strict stanza checking off

4. Ideally we should check/validate stanzas in CM, to reduce impact of malicious stanzas getting into our server. However, we have many CMs implementation but we do not want to have multiple implementations for the same logic. So ideally, if should be some kind of loadable plugin into any CMs that we have. Maybe the code which parses data stream and builds XML from it, could pass it through some kind of validation filters?

I guess there are more requirements for stanza checking than just IQ type. So ideally we would like to have some sort of API for loading different validation filters. We have some customers who have more strict rules for the stanzas and in some cases even for message content.

Do we need this for 7.2.0 version?

Artur Hefczyc wrote:

we have many CMs implementation but we do not want to have multiple implementations for the same logic. So ideally, if should be some kind of loadable plugin into any CMs that we have. Maybe the code which parses data stream and builds XML from it, could pass it through some kind of validation filters?

I guess there are more requirements for stanza checking than just IQ type. So ideally we would like to have some sort of API for loading different validation filters. We have some customers who have more strict rules for the stanzas and in some cases even for message content.

Well, there is are Appendix A. XML Schemas

      <xs:attribute name='type' use='required'>
        <xs:simpleType>
          <xs:restriction base='xs:NMTOKEN'>
            <xs:enumeration value='error'/>
            <xs:enumeration value='get'/>
            <xs:enumeration value='result'/>
            <xs:enumeration value='set'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>

I think that Tigase should first and foremost be compatible with specification (and rather strict about it, it's always possible to extend XMPP with custom XMLNS, having IQ type different than above really doesn't make much sense).

At any rate - having it configurable makes more sense.

Do we need this for 7.2.0 version?

No, I assigned it because it's required with the intention of "Request for discussion". I think we could handle such in "Candidates for next major version" or better yet have "RFC" version.

Please assign version accordingly.

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

I guess there are more requirements for stanza checking than just IQ type. So ideally we would like to have some sort of API for loading different validation filters. We have some customers who have more strict rules for the stanzas and in some cases even for message content.

Well, there is are Appendix A. XML Schemas

[...]

By "more requirements for stanza checking" I meant, not just IQ related checking. Presences, Messages, xmlns. People attempt to send all sorts of XML content through XMPP. I have seen XMLNS top level elements which are not either IQ, Message or Presence. Plus, some XMPP service providers require more deep stanza content checking for abusive content for example. This is why I thought of some kind of an API which allows to plug different filters and checkers on the CM level for performance reasons. Right now, we can plug such logic on SM level.

So, at the end we would need an API and of course some implementations. But we have to be careful about implementing them, as they might be resource consuming and performance affecting code.

I think that Tigase should first and foremost be compatible with specification (and rather strict about it, it's always possible to extend XMPP with custom XMLNS, having IQ type different than above really doesn't make much sense).

I think software should first and foremost be useful. Specification is a secondary objective and should be treated as a tool to make software useful not as a goal itself.

At any rate - having it configurable makes more sense.

Absolutely.

Do we need this for 7.2.0 version?

No, I assigned it because it's required with the intention of "Request for discussion". I think we could handle such in "Candidates for next major version" or better yet have "RFC" version.

Please assign version accordingly.

Assigned for next major version. Will review later.

After reconsidering, I think we should implement the strict IQ type checking with an option to disable it.