|
|
| Line 1: |
Line 1: |
| = Message 'type' of the receipt = | | = Uses -store and -storage = |
|
| |
|
| 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.
| | "he additionally adds the <no-store/> hint:" |
|
| |
|
| See
| | vs |
|
| |
|
| * http://mail.jabber.org/pipermail/standards/2015-February/029647.html
| | "A message containing a <no-storage/> hint" |
| * http://mail.jabber.org/pipermail/standards/2014-January/028479.html
| |
| * https://community.igniterealtime.org/thread/55160
| |
| | |
| == Suggestion ==
| |
| | |
| === Variant 1 ===
| |
| | |
| 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.
| |
| | |
| === Variant 2 ===
| |
| | |
| Add to XEP-184 5.4.:
| |
| | |
| 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 message.
| |
| | |
| === Variant 3 ===
| |
| | |
| Add to XEP-184 5.4.:
| |
| | |
| The message type of an ack message MUST be 'normal'.
| |
Revision as of 09:20, 10 August 2015
Uses -store and -storage
"he additionally adds the <no-store/> hint:"
vs
"A message containing a <no-storage/> hint"