RE: T2 Reliable Messaging w/o CPA or VIA...

mshTimeAccuracy
>>>This is the accuracy to which a recipient of a message claims to keep their internal system clocks. This should probably be part of a CPP and not vary from message to message therefore it does not need to be in the MessageHeader
[David Fischer] Agreed, but what if there is no CPP? I'm not sure why this is necessary.

reliableMessagingMethod
>>>This needs to be in the Via since it can vary on each hop of a multi-hop message. I suppose though that, if you are not doing multi-hop then it forces use of the Via element. I think we could either:
1. Put reliableMessagingMethod in the main MessageHeader with the copy in the Via element over-riding it, or
2. Change the definition of the Via element to suggest that it to be used when there is no intermediary
Thoughts?
[David Fischer] Option 1. Let's not muddle the Via. What if the MessageHeader reliability is higher (I assume "ebXML" is higher than "Transport"). Should an intermediate hop have a lower reliability than the end-to-end? Or do we care since it is a "black box"? Methods "ebXML" and "Transport" do not seem to be defined.

ackRequested
>>>This is in Via for the same reason as for reliableMessagingMethod - it can vary from hop-to-hop
[David Fischer] How do we accomplish single-hop Reliable Messaging? We need to be able to request an Acknowledgement without the Via. We could say that a DeliveryReceipt is equivalent. This means the receiver will have to process DeliveryReceipt as an Acknowledgement (set the Acknowledgement flag in the message database when a DeliveryReceipt is received and do all the other Reliable Messaging tasks equivalently--sequencing, persistent store etc.) which would be OK. Acknowledgement would then NEVER be used except in conjunction with VIA. This would uncomplicate Reliable Messaging but chapter 10 would have to be significantly re-written (replace/combine Acknowledgement with DeliveryReceipt in lots of places). What about 10.3.3 which specifies that an Acknowledgement MUST be sent. How is the receiving MSH to know if this is single-hop or multi-hop (whether to send Acknowledgement or DeliveryReceipt) by the presence of a VIA element? I don't think the Via actually get passed to the end-point since SOAP-Actor=next gets consumed in-route. How does the last hop/end know to send an Acknowledgement w/o the VIA?

retries & retryInterval
>>>These are both parameters that apply to the sender of a message and over which the receiver of message can have no effective control. There is therefore no need for them to be in the header. They should however be in the CPP for the sender
[David Fischer] What if there is no CPP? Is there never a need for the receiver to know how often and how many times the message will be resent? Maybe not. In my experience, the receiver usually ends up calling the sender on the phone for this info. This is not needed very often -- only to troubleshoot problems. I have seen many cases of "why did you send that message to me three times?" when the answer was related to retries. Agreed.

persistDuration
>>>PersistDuration only applies to the recipient of a message as it specifies the minimum time the recipient will keep a message. The sender cannot (should not?) control this, therefore there is no need for it to go in the header.
[David Fischer] Agreed. How is the sender to know? Should this be in the DeliveryReceipt? While this should be agreed to in the CPA, we cannot assume the existence of a CPA. I am still on the fence about whether there will be more implementations with or without a CPP/CPA. Could go either way depending upon the number of SME implementations vs. LE.

I'd appreciate your thoughts.

David

ebxml-msg message