RE: [ebxml-msg] Addition to Gateway Conformance Profile

Hamid writes:

I perfectly understand the issue Dale is pointing to and would like to resolve. However I don’t think the resolution is the correct one. We cannot require the gateway profile to support version 2. This would be equivalent in saying the ebMS-3 is a super-set of version 2. This is because the gateway profile is directly related to the core spec and represents the normal implementation of it. Other conformance profiles are “exotic” (in a sense) or derivative. Creating a new conformance profile in which version 2 must be supported as well is fine, but to put this directly in the main conformance profile (gateway) is the same thing as putting this in the core spec itself, and this is not a good approach.

Hamid, I do not share your assumptions about the purpose of our profiles. Our profiles are not like WS-I restrictive profiles on specifications. Instead our profiles specify a more or less complete MSH role that an aggregate of software components can fulfill, much in the way a class can implement an interface. A gateway MSH can be required to do some functionality described in XMLDsig, some in WS-RX, some in WSS, some in ebMS 3 core, and for market sanity, some in ebMS 2. So your argument that ebMS 2 would have to be a part of ebMS 3 specification is to me off-base. There are many things that are called “profiles” and I simply reject the assertion that a gateway profile has to be restricted to profiling the ebMS 3 core spec. A profile is a good place to specify the required behavior of a MSH playing the gateway role; nothing requires that there be a single software component associated with that role. In fact, the component level design is left to the implementer, as it should be IMO.

ebxml-msg message