I don't mean to say there cannot be another business process which provides a Business Delivery Receipt and signs it. However, that has nothing to do with NRR. NRR is only a receipt that the message was delivered intact. This is a requirement we cannot lose track of. The idea of a Business Process Receipt stating that the application got the message and is processing (or something of that nature) is a different requirement and is outside the scope of TRP. That would be another message with another MessageId which also could be sent with a DR request and NRR. The legal ramification of a NRR is the same as Registered Mail. If the IRS says I didn't send my tax form and they are going to charge me a late fee, then I hand my signed receipt to a Judge and say Oh yes I did and here's the proof -- I win. That has nothing at all to do with whether my tax form is filled out correctly or even looked at it. All it proves it that they got it on time. NRR has nothing to do with the business process. This is not signing a legal document. NRR is non-repudiation OF RECEIPT. I looked in RFC2459 and I didn't see Non-Repudiation of Receipt at all. I did see Non-Repudiation and the action it refers to is in this case *receipt of the message*. NRR belongs in the MSH. Time sensitive documents need NRR even more. The Receiver can say *you never sent me the contract* and the Sender can say *Oh yes I did, you just didn't process it in time* which in a law suit is precisely what the Sender needs. How else would the Sender prove they had taken the required action? Without NRR, the Receiver has all the power since he can just ignore anything he doesn't like and later say they never received the document. This is precisely why NRR at the MSH level is critical. The idea of the MSH not having access to a key is not worth discussing. Secretaries sign for FedEx packages every day. Systems receive EDI payloads and sign receipts every day without ever looking at the payload itself. Let's stay on topic. Regards, David Fischer Drummond Group.