On 13.04.2015 22:35, Christian Schudt wrote: > 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.
An empty string is not a "null" String. Similar, it's a difference if a message stanzas contains a body element containing the empty String, or no body at all. This must simply be treated differently. And I guess it's possible to do so in most (any?) programming languages out there. Therefore I don't see why such "issue(s) can't be prevented". It's very common in XMPP to send messages without a 'body' element. And if your software behaves like this is a message with a body element containing the empty string, then I consider this a bug in the your code. > 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)? This is mostly motivated by not restricting things without a need. - Florian
signature.asc
Description: OpenPGP digital signature
