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

[christopher ferris <chris.ferris@Sun.COM>]

Arvola,

A couple of comments.

Cheers,

Chris

Arvola Chan wrote:
<snip/>
> ===========================================================
> 
> 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

It isn't a requirement that the same transport protocol be used on either side
of a forwarding intermediary, IMO. e.g. the sending node might use
HTTP between itself and the intermediary and then between the intermediary
and the recipient, the protocol might be SMTP. What may be necessary
is that between the Intermediary and the MSH to which it forwards messages
there be a separate CPA, one that possibly deals only with transport
details (as David B has suggested). Thus, the intermediary might introduce
a Via element to account for that. This isn't completely clear.

I certainly agree that for forwarding, there is no explicit need (for the
first hop) of a Via element.

As for security, things start to get a little crazier. I think that the
same level of security needs to be applied, whether it is necessarily the same
set of certificates, etc is less clear.

> 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.
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>