Sounds good to me… except XEP-0045 still uses „MUST NOT“ for groupchat-type in private occupant-to-occupant messages. Might be inconsistent wording across the two specs.
Furthermore I can understand the issue raised in your linked post [1]: In software an empty String and a null reference (here: with regards to <body>) are often treated similarly (C# even has String.IsNullOrEmpty()), leading to the issue described (displaying acks wrongly as empty chat messages). Such an issue can’t be prevented by „not making assumptions about the type“, when dealing with receipts. Having that in mind, are there any benefits to send acks as chat-messages (or to explicitly allow them to be sent by the specification)? [1]: https://community.igniterealtime.org/message/247333#247333 Am 13.04.2015 um 22:02 schrieb Florian Schmaus <f...@geekplace.eu>: > On 11.04.2015 19:39, Florian Schmaus wrote: >> * Variant 1 >> >> The message type of an ack message MUST match the type of the message >> with the related receipt request, if it's of type 'groupchat'. It SHOULD >> match the type otherwise. A receiving entity MUST NOT make any >> assumptions about the message type of an ack message. > > Georg and Christian provided some valid points. So Variant 1 becomes now > > > The message type of an ack message SHOULD NOT be 'groupchat'. It is > RECOMMENDED to use 'normal' for the ack message type, or alternatively > it MAY matches the type of the message requesting the delivery receipt. > A receiving entity MUST NOT make any assumptions about the message type > of an ack message. > > > What matters to me most is the last sentence. And Georg had some good > arguments for 'normal'. > > - Florian >
