[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Intermediary support in the 1.1 version of the MSG and CPP/A specs
I may repeat myself once more. I think that there are two fundamentally different situations. - the first is when the Intermediate node is used just as a technical convenience. Someone wants to say that the message between two parties "transits" at an intermediate node for not better specified reasons. The intermediate node has no requirements nor changes the "contract" between From and To (referring to Chris's previous mail, the intermediate node probably cannot change the HTTP to SMTP also, unless in some way this is taken care by the CPA between From and To) In this case I see only a CPA between From and To. We need probably to accomodate some tag to allow to specify the Intermediate node. We would also, probably, need to specify a very normative behaviour for the intermediate node in terms of security and in terms of acks that are sent back and forth. The intermeidate has no freedom because it is simply a "hop", a "slave". The fact that it may actually read parts of the message and perform some "accounting" on them is an accident - the second is when the Intermediate plays a role in the process. Whenever the Intermediate is an Actor, then there are TWO CPAs and, logically, a multiparty process (which could be normalized probably in a couple of bi-party processes). In reading the threads on this topic, I guess that this is the case which is most referenced because in some way or in another each one "adds" a little bit of intelligence and of behaviour to the intermediate node. If we need to model the behaviour/intelligence of the intermediate I would prefer to see it as an ACTOR and, thus, having separate CPAs. Sorry if this is something which has already been said. Best regards /stefano » -----Original Message----- » From: Arvola Chan [mailto:arvola@tibco.com] » Sent: 25 September 2001 21:45 » To: christopher ferris » Cc: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org » Subject: Re: Intermediary support in the 1.1 version of the MSG and » CPP/A specs » » » Chris: » » I agree with you that there will be use cases where a forwarding » intermediary may need to use different transport protocols for inbound and » outbound messages. I believe Dale is assuming that a common CPA » will be used » by the From Party, the To Party, and the » intermediary/intermediaries. Maybe » that assumption is too restrictive. Even with such an assumption, » it is not » clear to me how it can be made to work. Consider the one » intermediary case, » if the intermediary's endpoints are transparently used by the » From Party and » the To Party as their own endpoints in the CPA (i.e., the transport » endpoints in the CPA all contain addresses associated with the » intermediary), then where does the intermediary find the real forwarding » addresses for the From Party and To Party? Clearly, there is extra » configuration information needed by the intermediary that is missing from » the CPA. I also tend to agree with Marty that once you take into » consideration transport level security or if there are multiple » intermediaries, it will be unwieldy to capture all the relevant » configuration information in one CPA. » » Has anyone worked out simple examples where a separate CPA is used between » each adjacent pair of MSH nodes? What kind of business processes » have to be » used to represent the message forwarding activities? What Service » and Action » elements will be appropriate under the Via element? Is the existing CPP/A » element structure sufficient for this purpose? » » Regards, » -Arvola » » -----Original Message----- » From: christopher ferris <chris.ferris@Sun.COM> » To: Arvola Chan <arvola@tibco.com> » Cc: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>; » ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org> » Date: Tuesday, September 25, 2001 11:14 AM » Subject: Re: Intermediary support in the 1.1 version of the MSG and CPP/A » specs » » » >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> » » » ---------------------------------------------------------------- » To subscribe or unsubscribe from this elist use the subscription » manager: <http://lists.oasis-open.org/ob/adm.pl> »
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC