[Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
christian.schudt at gmx.de
Sat Apr 11 19:36:14 UTC 2015
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:
—> The message type SHOULD be "chat" and MUST NOT (!!!) be „groupchat“, but MAY be left unspecified (i.e., a normal message).
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.
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“
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)
Am 11.04.2015 um 19:39 schrieb Florian Schmaus <flo at geekplace.eu>:
> Dear authors for XEP-184,
> It has become obvious that XEP-184 is underspecified when it comes to
> the message type of ack messages:
> - http://mail.jabber.org/pipermail/standards/2015-February/029647.html
> - http://mail.jabber.org/pipermail/standards/2014-January/028479.html
> - https://community.igniterealtime.org/thread/55160
> As far as I can tell, the following variants would remedy the situation.
> Add to XEP-184 5.4.:
> * 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.
> * Variant 2
> The message type of an ack message SHOULD be 'normal'. A receiving
> entity MUST NOT make any assumptions about the message type of an ack
> * Variant 3
> A receiving entity MUST NOT make any assumptions about the message type
> of an ack message.
> * Variant 4
> The message type of an ack message MUST be 'normal'.
> Personally, I don't have a strong opinion towards any of the Variants
> 1-3. But I think Variant 4 should not be considered, as it imposes to
> many restrictions. As short term solution, please implement Variant 3
> now. Further additions could still be added later on.
More information about the Standards