[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] CPAId; negotiation
First of all, I errred when I said that we don't have a CPAId attribute in the CPA. We do. I was looking in the CPP chapter instead of the CPA chapter :-( However, I do recommend that we strengthen the text. Since the CPAId must be agreed to, I propose saying that the value of the CPAId attribute SHALL be used as the value of the CPAId in the message header. My other comments in the prior posting are still applicable. As to David's comments/questions, see below, prefixed by MWS: Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* David Fischer <david@drummondgroup.com> on 10/22/2001 09:20:26 AM To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-cppa@lists.oasis-open.org cc: Subject: RE: [ebxml-cppa] CPAId; negotiation Is there any recommendation about CPAId? MWS: CPAId is defined in the MS specification along with some specific recommendations for creating its value. My prior posting was a recommedation that the CPA team codify this by making a normative statement that the value be codified in the CPA. This is an area of some confusion for many implementers. Perhaps this should be a concatenation, in alphabetical order, of the Trading Partner IDs? MWS: The CPAId may be anything that the two trading partners agree to that is unique among all CPA identifiers that they may be dealing with at the same time. No one should use the PartyIds since two Parties may have more than one active CPA between them at the same time. They can get away with it for the first CPA but they will be burned if they later establish another CPA between them. Why does it have to be the same in both directions? MWS: Having the CPA be a URI or some other globally unique value is an artifact of the earlier discussions of intermediaries when it was believed that an intermediary might have to understand CPAIds of CPAs between the endpoints. If this is no longer true, the MSG team could consider removing that restriction. However the restriction in my response directly above is the important one. Furthermore, each Party must know the value to specify in its outgoing messages. That value is the value that the To party recognizes as pointing to the configuration information for the particular business relationship. Changing the definition to permit the two parties to simply exchange values rather than agreeing on a common value would necessitate change in the CPA (we would need a CPAId under each PartyInfo element along with suitable text). I thought about adding this to my previous posting but decided that that might be overkill. Some implementers are trying to leave this blank and use the From/PartyID instead (they are headed for trouble when they find that the MS schema specifies this as a non-empty-string). MWS: Again, they will be burned as soon as they decide they need more than one CPA active between them at the same time. MWS: The bottom line is that the CPAId must identify the set of configuration information related to the business relationship between them and must identify it among all possible business relationships that could be active at the same time. This is true whether there is an actual CPA, per the ebXML CPP-CPA specification, or whether the configuration information is written on a sheepskin scroll. Regards, David. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Sunday, October 21, 2001 5:45 PM To: ebxml-cppa@lists.oasis-open.org Subject: [ebxml-cppa] CPAId; negotiation The To and From parties must each understand what value of CPAId will be understood by the From party. As defined in the MS specification, the CPAId is a single value that must be understood by both parties. I suggest that: The CPAId must be an item of negotiation since the two parties must agree on a value that both understand. At least for convenience, we should add to the top-level element of the CPA a child element or an attribute that will be filled with the CPAId. Please note that the CPAId as sent in the message header is independent of any identifier metadata associated with storing a CPA or CPA template in a registry. The CPAId element is not needed in the CPP. However for convenience in the CPA composition process, it might be helpful to have a CPAId element or attribute in the CPP with a dummy value. There was previously (Vienna or earlier) discussion about the need for a CPP identifier in the CPP. At that time it was (I think) agreed that a CPP Id is an item of registry metadata and can only be assigned when the CPP is placed in the registry. Since the CPP may be signed by the creater, the CPP Id cannot be placed in the CPP after it is signed. Therefore, there is no CPPId element in the CPP. Regards, Marty ******************************************************************************** ***** Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ******************************************************************************** ***** ---------------------------------------------------------------- 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