Intermediary support in the 1.1 version of the MSG and CPP/A specs

[Arvola Chan <arvola@tibco.com>]

The following is an excerpt from the Messaging section of the minutes for
last week's CPP/A conference call (taken by Tony Weida).

http://lists.oasis-open.org/archives/ebxml-cppa/200109/msg00054.html

The CPP/A team seems prepared to address the use case of forwarding
intermediaries only. Does that meet expectations from members of the MSG
team? If the MSG spec covers intermediary use cases that are not dealt with
by the CPP/A spec, I would strongly recommend that it be clearly stated in
the MSG spec.  Otherwise, it will be very confusing to readers of the
revised specs who are not privy to all the technical committee discussions.

I think intermediary support should be a high priority item for the joint
meeting on 10/3.

-Arvola

===========================================================

Messaging

Arvola reported a fair amount of list traffic on RM and whether end-to-end
retransmission should be specified.  He asked if version 1.1 will we deal
with forwarding intermediaries appropriately.  Dale distinguished between
two cases: forwarding intermediaries, where a CPA isn’t needed, and
multiparty cases, which is in the scope of version 2.0.  He opined that the
approach taken in the proof-of-concept demo is probably sufficient for
forwarding intermediaries (the intermediary is only involved in the CPA as a
transport endpoint).  Arvola questioned whether that made the Via
(messaging) element unnecessary.   Dale responded that it wasn’t necessary
for the forwarding case, and would be used at the discretion of the
originating MSH.  Our commitment is to support the endpoint mechanism, and
exactly what else is needed is unclear.  We may recommend that CPA software
check the coherence of values given for timeouts, retries, etc.  According
to Tim, that assumes the same security and transport on both sides of the
intermediary.   Dale said we’re assuming that the intermediary doesn’t alter
packaging and security – to the extent that the Via element or the
TraceHeaderList impacts such things, it will be reflected in an agreement.
Marty asked if the intermediary can pass through transport level security
info, and if not, he suspects we’re into a multiparty situation.  Jamie
questioned whether the Via element could potentially thwart the policy
intentions of a party if it resulted in changed messaging settings.  Dale
recalled “case 1.5” of a forwarding intermediary that restructures or
re-encapsulates the message/payload in some manner – a CPA may be needed
then.  Tim proposed acknowledging that such cases exist but are not
supported for 1.1.  David stated that the Messaging committee considers
intermediaries out of scope for their version 1.1.  Jamie asked if an
intermediary is considered to be a pure forwarder bound to respect the CPA
between two end parties; we then discussed advantages of keeping CPA content
technical in nature from the standpoint of expediting agreement and
implementation.  Tim asked about how non-repudiation and error propagation
happen with intermediaries.  We discussed that some errors may come from the
endpoint and others from an intermediary, and David (?) thought that in any
case they’re just ebXML messages.  Arvola asked if an intermediary would
have to identify itself as the end party if it’s not explicitly identified
in the CPA.