RE: [ebxml-msg] proposal for ebbpsig:NonRepudiationInformation

["Dale Moberg" <dmoberg@us.axway.com>]

Sorry to miss discussions because of travel and meetings.

 

The mid: and cid: schemes for URIs are not associated with completely well defined retrieval techniques in terms of what server to contact, what port to use, what communications protocol to use, etc. So they have been observed to be more like URNs than URLs in these respects.

 

I take it that Pete was wondering how cid: information can be combined with some other information to find the right message. I think that the ebMS SOAP header in the receipt message should have a RefToMessageId field. It is presumed that an implementation handles archiving and retrieval of the messages it has sent in some fashion, although the specification does not mention it. Hence the RefToMessageId value, combined with the implementation specific ways of locating that message, and the cid: URIs yield a way to find a message and an identifier for the message part. ds:Reference information then characterizes the plaintext and the hash method sufficiently to support a further check that the message that the MSH implementation had sent is the “same as” the message the receipt is asserting to have been received.

 

I will take a look more this weekend when I have a bit more time to study the thread on this. Logically identifying the message by information is what the NRR process needs. The implementation needs sufficient information to track down the message but if NRR process is to be supported, certain presumptions are made on record keeping and archiving. The implementation needs to retain the messages it has sent in order to check that the message that someone claims to have received is in fact the message that it had sent. Something logically based on Message-Id would then be sufficient for the retrieval task posed by the NRR checking process.