Mark:

I would say no since the ebXML messaging team, CPP/A team and existing architecture all reflect the ability to constrain/run processes as per the ebXML requirements. It is not added since this paragraph exists at line 981 in the existing ebXML TA version 1.04:

"The ebXML Messaging Service Layer enforces the "rules of engagement" as defined by two Trading Partners in a Collaboration Protocol Agreement (including, but not limited to security and Business Process functions related to Message delivery). The Collaboration Protocol Agreement defines the acceptable behavior by which each Trading Partner agrees to abide. The definition of these ground rules can take many forms including formal Collaboration Protocol Agreements, interactive agreements established at the time a business transaction occurs (e.g. buying a book online), or other forms of agreement. There are Messaging Service Layer functions that enforce these ground rules. Any violation of the ground rules result in an error condition, which is reported using the appropriate means."

To me, this is the most desirable architecture. ebXML kicks out unwanted electronic signals at the front gate. This could help alleviate DoS type attacks since a system could implement a feature to stop parsing incoming messages as soon as the CPA ID is detected as invalid (Stream style parses can be interrupted based on events).

Also - there is no consensus yet on a requirement for the architecture to be KISS as of now. We need to discuss the scope in New Orleans to decide this. I am against adding unnecessary complexity however if our primary audience is system implementors, then a level of detail sufficient to aid them will be required.

Let's discuss Face to face in NO.

Duane

Mark Yader wrote: