Starting with Smack version 4.1.0 the message delivery receipt package contains the type attribute, e.g. type=‘chat’.
This is a change and makes new clients incompatible to older clients. We observe also problems with clients of other platforms which do not send the type attribute.
According to XEP-0184 specification this attribute is not included:
Starting with 4.1, Smack uses the type of the message with receipt request for the receipt, while it previously only used ‘normal’ for the receipt. I don’t see any particular reason not changing that back to using ‘normal’ as type. But could you elaborate what breaks if the type is not ‘normal’? I’d also like to take this to the standards@ ML before making a final decision, therefore your input is much appreciated.
After digging standards@ I found: [Standards] XEP-0184 type attribute on message which is likely what made me do Return delivery receipts with the same type as the request · igniterealtime/Smack@b813e3a · GitHub
And quick survey in jdev also yields the result that using the same type is the right thing to do™, although it’s underspecified in XEP-184. But that also means that implementations need to handle the case where the type is not ‘normal’.
It is not clearly defined in XEP specification. So it’s worth to discuss this.
I observe on other clients like iOS XMPPFramework that the type is never set. If the type is set to ‘chat’ it can happen that implementations that rely on the type evaluate this as a real chat message which is empty. I our extended protocol this is evaluated as an invalid message because all other clients used do not set the type.
I now made a workaround and added a listener which responds without type set. But changing back in Smack could avoid effects for other users. However, finally all should follow the standard if there is any.
If the type is set to ‘chat’ it can happen that implementations that rely on the type evaluate this as a real chat message which is empty. I our extended protocol this is evaluated as an invalid message because all other clients used do not set the type.
That approach seems wrong and is obviously causing problems: You don’t need to care about the type of the message containing a ‘received’. Also, the assumption that those messages are “empty chat” messages is also wrong. Messages with an empty body element can be considered as empty chat messages. Messages without a body (or html) extension, are very common in XMPP, as it’s primarily a data exchange protocol that just often used for (human-to-human) chat.
For example Smack simply filters all messages with the receipt extension, regardless of the type, and invokes the receipt received listeners.