3.1.7.3.1 Sending a Commitment Receipt

If the <commitmentReceiptRequest> element is present in a user message, the protocol MUST send a commitment receipt (see section 3.1.1.3.4) message to the original sender when the message is removed from the destination queue. If the <positiveOnly/> element is present, a positive commitment receipt MUST be sent if the message is received by the receiving application. If the <negativeOnly/> element is present, a negative commitment receipt MUST be sent if the message expires or is purged from the destination queue before reaching the receiving application. If neither element is present, commitment receipts MUST NOT be sent.

The <id> element in the <commitmentReceipt> element MUST be set to the <id> element of the <path> element of the original message requesting the receipt.

The <decidedAt> element MUST be set to the CURRENT_TIME at which the outcome was recorded, and the <decision> element MUST be set to "positive" for a positive receipt or to "negative" for a negative receipt.

If iReason equals AckReceive, the <decision> element MUST be set to "positive". If iReason equals NackPurged, NackQueueDeleted, NackQueuePurged, NackReceiveTimeout, or NackReceiveRejected, the <decision> element MUST be set to "negative". If iReason equals any other value, the server MUST not send a commitment receipt message.

The commitment receipt message MUST be addressed by setting the <to> element of the <path> element to the URI in the <sendTo> element of the <commitmentReceiptRequest> element.