RE: [ebxml-cppa] CPAId; negotiation

[Martin W Sachs <mwsachs@us.ibm.com>]

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>