3. Business rules 3.1. Message IDs Sender generates an Origin ID to track message delivery to Server. It is a client-side identifier that is kept by a client to track delivery receipts and error messages. It MUST NOT be used for any other purposes. Sender MUST guarantee that the Origin ID is unique for all messages of all jid clients. The absence of such guarantee may result in incorrect work of the protocol. It is RECOMMENDED to use UUID for Origin ID. It is RECOMMENDED for the Sender to use the Origin ID value for ‘id‘ attribute of . For each stored message, Server generates a Stanza ID, which MUST be unique within the server. Each message within the server is identified by unique Stanza ID. Sender SHOULD use for message tracking. 3.2. Delivery receipts Delivery receipt MUST have type ‘headline’ and MUST NOT be stored in message archive. Delivery receipt MUST be sent to the Sender. Server SHOULD NOT confirm delivery of messages that are not intended to be stored in Message Archive. This includes: ‘error’ type messages ‘headline’ type messages Messages with an empty body. When searching for possible message duplicates, Server MUST search only within the messages of the Sender’s jid. Example 1. Sender send message with Origin ID: Hi! Server replies by sending delivery receipt to the Sender:

3.3. Message archiving Server MUST ensure that the value of attribute ‘stamp‘ of tag added to the message under the current protocol is equal to the value of attribute ‘stamp‘ of tag added by Message Archive. This is necessary for the compatibility with the existing protocols. Server MUST send generated back to Sender. This is necessary to track message delivery. This requirement conflicts with clause 3.5 of XEP-0313: Message Archive Management, that servers MUST NOT include the element in messages addressed to JIDs that do not have permissions to access the archive. However, in XEP-0359: Unique and Stable Stanza IDs there are no restrictions on relaying to clients. Clause 5 of XEP-0359 states that value SHOULD NOT be secret. Consequently, this protocol does not observe this requirement of clause 3.5 of XEP-0313. Use of receipts MUST NOT clutter message history. Therefore, delivery receipts MUST NOT be stored in the message history. 3.4. Resending By message re-sending Sender MUST include tag to the message and send it with original Origin ID to the Server. Server MUST check if the message was stored in the Message Archive. If the message is found Server MUST stop processing the message and send a receipt to the Sender. Example 2. Sender try to re-send message: Sender try to re-send a message: Hi! Server searches for this message in the Message Archive. If Server found message he MUST send delivery receipt: