Marty, I'm o.k. with requiring the attribute to be in the message header and also happy with throwing an error if it is not. However, I think it is also ok for the attribute to be absent *if* there is an *agreed on* default. Even if we require the attribute's presence, there is the case where the sending MSH has no indication from its app as to what value the attribute should have. In that case, what value should it use? I don't think we can assume that the business application will always know what value to use. Do you? (If we can assume the business app always knows, then yes -- there is no need for a default.) Setting up a default value in the CPA eliminates the need for the sending MSH to second-guess the two parties. Basically, the CPA is saying: To the sender MSH: if you do not know what to set this perMessage attribute to, use 'x' because that is what we (the two parties) have agreed on as a default . This notion of a perMessage default is Arvola's embellishment on perMessage semantics. I think it is a good and necessary one (based on the assumption that the business app does not always know about this parameter or how to set it). Admittedly, allowing a default value is not something that we have formally agreed on as a group, that I know of. That said, I think it logically follows the decisions that we have made. Bruce ============================================ Bruce Pedretti Hewlett-Packard Company Software Developer 6000 Irwin Road (856) 638-6060 Mt. Laurel, NJ 08054
http://www.hp.com/ ============================================