RE: CPA-CPP ver. 0.92 distributed today

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

Scott,

This is principally a TRP issue.  I have forwarded your posting to the TRP
list.

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
*************************************************************************************


Scott Hinkelman
02/27/2001 09:52 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "Moberg, Dale" <Dale_Moberg@stercomm.com>, "'christopher ferris'"
      <chris.ferris@east.sun.com>, ebxml-tp@lists.ebxml.org
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject:  RE: CPA-CPP ver. 0.92 distributed today  (Document link: Martin
      W. Sachs)

I believe it makes sense to have the CPAid optional, and load any needed
information into the header, as David B
points out. I think the CPAid should called ConfigInfo with a "type" like
Partyid and be ORed with a structure containing
the needed header data. Fundamentally, all we are talking about is
by-reference or by-value with some additional
process concerns for initial messages or bootstrap, which may not even need
to be spec'd.
The issue to me is not *if* it makes sense to have it either by-ref or
by-value, but *what* header data is needed.
That is what may not be able to be settled in time. This also is well in
line with breaking dependency between components
in ebXML.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Martin W Sachs/Watson/IBM@IBMUS on 02/27/2001 08:37:41 AM

To:   "Moberg, Dale" <Dale_Moberg@stercomm.com>
cc:   "'christopher ferris'" <chris.ferris@east.sun.com>,
      ebxml-tp@lists.ebxml.org
Subject:  RE: CPA-CPP ver. 0.92 distributed today




Dale,

In my opinion, the hangup on optionality, and its solution, is described in
the posting, below, that I just sent to the Transport list.  This problem,
as I recall, is mainly TRP's making because the consensus was that the
CPAId should be globally meaningful to both parties.  As I note below, you
can't simply make the CPAId optional in the message header because it is
the pointer to the local configuration information needed when a message
arrives.  The solution, as described below, is to replace the one CPAId by
locally meaningful pointers, one for each party.  Nothing new has to be
configured into the messaging service. In each conversation, the party
initiating the conversation places its pointer in the message header.  The
other party supplies its pointer in the response.  From then on, until the
conversation ends, both parties' pointers are in the message header and
each uses its own when a message is received.

There is one catch:  How does the party receiving the first message of the
conversation process it without a global CPAId?  I am assuming that for the
first message of a conversation, the ID of the sending party is sufficient
to enable the the receiving party to set up its end of the conversation.
If not, we are stuck with some kind of configuration identifier that both
Parties understand.  I suppose we could make the CPA optional by saying
that the Parties may agree on a value of the configuration identifier by
phone, tin cans and a string, or whatever.

I view this as mostly a TRP matter rather than a TP matter, and not one
that can conceivably be settled by Mar. 19.

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
*************************************************************************************




"Moberg, Dale" <Dale_Moberg@stercomm.com> on 02/26/2001 11:29:04 PM

To:   "'christopher ferris'" <chris.ferris@east.sun.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org
Subject:  RE: CPA-CPP ver. 0.92 distributed today



In addition to the points mentioned about ver 0.92, I hope
we can run through the issue of how to explain the
way in which a CPA is optional. I understand this to
be a corollary of modularity of WGs--the ability to use
one part of the spec without others. I have understood
that a MSH will need to have local information, but how that
is exchanged, or how it is configured into the MSH, would
be part of the unwritten MSH service api. Additionally,
I have doubts that a CpaID will, in itself, be sufficient
to identity the record needed for a MSH conversation. I would
like to discuss this issue Wednesday as well. Hope there
will be time.

Dale Moberg

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org


Martin W Sachs
02/27/2001 09:10 AM

To:   maw2@daimlerchrysler.com
cc:   "Burdett, David" <david.burdett@commerceone.com>,
      ebxml-transport@lists.ebxml.org
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  RE: CPA and overrides  (Document link: Martin W. Sachs)

The hangup on optionality is the first quoted paragraph:

   The REQUIRED CPAId element is a string that identifies the Collaboration
   Protocol Agreement (CPA) that governs the processing of the message.
   The
   identifier MUST be unique within the domain of the names chosen by the
   Parties.

As I recall, this paragraph is the TRP's doing, not the TP team's doing. I
argued for the CPAId to contain two subelements, one for each party, that
contains locally meaningful information such as a pointer to the local
configuration that may or may not be derived from a CPA.  Once the first
pair of messages have been exchanged, the message header contains both
parties' pointer and each uses the one that belongs to it when it receives
a message.  Were that the definition, the parties would be free to use a
CPA or otherwise define their configuration information.

Making CPAId optional is NOT the answer because without it, some other
message header element would have to be provided so that a receiving Party
can get to the information it needs to route and process the message.

Changes in this area will break other areas.  This needs to be very
carefully thought out before doing anything.

I suspect that this is far below the cut level for issues that MUST be
settled before Vienna (read that, Mar. 19)

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 unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org