Difference between revisions of "XEP-Remarks/XEP-0184: Message Delivery Receipts"
Line 8: | Line 8: | ||
* http://mail.jabber.org/pipermail/standards/2014-January/028479.html | * http://mail.jabber.org/pipermail/standards/2014-January/028479.html | ||
* https://community.igniterealtime.org/thread/55160 | * https://community.igniterealtime.org/thread/55160 | ||
== Suggestion == | |||
Use the message type of the request, because 1. as Kurt points out, if the type is groupchat it must match and 2. then the receipt can be easily embedded in the response message containing also a 'body' element. Using a fixed type would break the semantic of a conversation, e.g. message with request of type 'chat', reply with body and receipt of type 'normal'. | |||
Add to XEP-184 5.4.: | |||
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. |
Revision as of 08:58, 10 April 2015
Message 'type' of the receipt
It's underspecified in xep184 what the type of the message with the received extension should be. Consensus seems to be that it must (should?) match the type of the message with the receipt request.
See
- 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
Suggestion
Use the message type of the request, because 1. as Kurt points out, if the type is groupchat it must match and 2. then the receipt can be easily embedded in the response message containing also a 'body' element. Using a fixed type would break the semantic of a conversation, e.g. message with request of type 'chat', reply with body and receipt of type 'normal'.
Add to XEP-184 5.4.:
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.