Marty:
I agree with you that if the CPA template is missing communication
endpoint information, then the missing information may have to be
filled in by the parties through other configuration means before B2B
exchange can take place. The sender must know the receiver's URL
in order to send a message. The receiver, on the other hand, may
not necessarily have to know the sender's return URL ahead of
time. An implementation may want to provide this level of flexibility
to improve scalability. For example, the ebXML registry grants
read access to all clients. Why is it important for it to know a priori
the communication URL of every client?
The existing Messaging Service spec allows for supplementing
endpoint information that is missing from the CPA. Consider the
Sender element (under TraceHeader) described in section 8.5.2.1
(line 990):
8.5.2.1.2 Location element 1001
This element contains the URL of the Sender�s Message Service Handler.
Unless there is another URL 1002
identified within the CPA or in MessageHeader (section 8.4.2), the recipient
of the message uses the 1003
URL to send a message, when required that: 1004
� responds to an earlier message 1005
� acknowledges an earlier message 1006
� reports an error in an earlier message. 1007
This element seems usable by the sender to inform the receiver of its
return URL, when the CPA installed at the receiver does not spell
out the sender's communication URL.
I am not advocating adding new elements to the message header at
this point solely to enable a CPA template to be substituted for a
complete CPA. However, I don't think we should remove
mechanisms that are already in place in the message header (either
in the PartyID under the From element, or in the Location under Sender
in the TraceHeader element) to supplement information that may
be missing from the CPA.
Regards,
-Arvola
