RE: T2 The answer isn't always "you need a CPA" was RE: T2 PLEASE READ -Suggested Change - add "From" Service and Ac tionto the header

[Dale Moberg <dmoberg@cyclonecommerce.com>]

In response to David Burdett msg:

>From: Burdett, David [mailto:david.burdett@commerceone.com]
>Sent: Tuesday, September 11, 2001 10:09 PM
>To: 'Martin W Sachs'; Ian. C. Jones (E-mail)
>Cc: 'William J. Kammerer'; ebXML Messaging (E-mail)
>Subject: T2 The answer isn't always "you need a CPA" was RE: T2 PLEASE
>REA D -Suggested Change - add "From" Service and Ac tionto the header
>
>Marty (and also Ian Jones)
>
>You said ...
>
>>>The solution of piling additional information into the message header
to
>make up for the lack of a CPA should not be considered acceptable.<<<>
>
>The ebXML messaging group has **agreed** that we want to separate the
ebXML
>Messaging and CPPA specs so that they can be implemented independently
or
>together (Ian, please correct me if I am wrong). 


David B,

All the groups are aiming for modularity, 
which means each spec can work with
the other Oasis specs 
as well as with other approaches. 

What is puzzling is why you think
this principle justifies bloating
the ebXML message header. 

The MSH has been architected under the
assumption that it has in its 
possession information that
enables it to do "(send or receive)transport,
(un-)packaging, and (application layer)
routing" for a given sender/receiver
pair and to do those operationss down 
to a granularity of a
specific BP (currently identified
by a service and action value).

While a CPAid _could_ allow a MSH
to look up sender, receiver, service,
action etc. in principle, it has been
agreed so far to put these specific items
into the header. Other items, like the
messageId and RefToMessageId, are clearly
per message values, not "per channel"
values, and so cleanly belong in
the header. ConversationId is another
one of these more "dynamic" values
of the message. Same for the dateTime.
Etc.

However, it has never been agreed, to my
knowledge, that if a use case
shows that a given item of information
would be useful configuration information
for a MSH, it should go in the header.
Yet you seem to be assuming this.

You offer up a "use case" where an 
application could make use of some information
to find out what application had submitted
an initial request payload to it, as a part
of processing a response. The point is that
the reftomessageid, along with the conversation id, 
are already available to support 
this correlation of response to request. 
The MSH, in an implementation
specific way, is to then make the payload 
available to the right service. It may make use
of service and action values, even cpaid,
in figuring out how to handle the response.
But the specific way it makes use of those 
values has so far been left as an implementation
detail.

I can understand how leaving the semantics
of the use of these values open to MSH
interpretation might be regarded as a
weakness. But that weakness is not something
that adding yet more uninterpreted fields
to the header will cure. 

So I must agree with Marty and several others
on this list, that your proposed change
to service and action, neither fixes a bug nor provides
needed clarification. 

Dale Moberg