On 4/11/15, 1:36 PM, "Christian Schudt" <[email protected]> wrote:
>Hi, > >I think Variant 1 violates XEP-0045: When receiving a „request“ message from >an occupant in a MUC room (type=groupchat), the receiver would send a receipt >to the sender directly, not to the MUC room, by simply sending it to the >„from“ attribute of the request, which is a full JID. > >It’s basically a private message to the requesting occupant: >http://xmpp.org/extensions/xep-0045.html#privatemessage Yes, that makes sense. Replies certainly shouldn't go to everyone in the room. >—> The message type SHOULD be "chat" and MUST NOT (!!!) be „groupchat“, but >MAY be left unspecified (i.e., a normal message). Yes, that also follows. >Implementors could easily violate this, if they simply reuse the message type >of the request (if it’s groupchat) and send the receipt message as private >message to the requester. There are always lots of ways to write bugs. >I like Variant 2 most, but maybe even ‚headline‘ fits more to receipts, >because its definition is: >"The message provides […] information to which no reply is expected“ Headline also has the nice property that servers doing offline SHOULD NOT hold on to headlines; that seems to fit the intent here. Probably needs some testing in the real world. >while a reply is expected to normal messages: >"The message is a standalone message that is sent outside the context of a >one-to-one conversation or groupchat, and to which it is expected that the >recipient will reply“ > >(And no reply is expected to receipt messages) You MUST NOT reply to receipts; it would be very easy to create loops that way. -- Joe Hildebrand
