RE: [ebxml-cppa-negot] Negotiation Message Content

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Comment/question below.

-----Original Message-----
From: Jean Zheng [mailto:jzheng@vitria.com]
Sent: Tuesday, August 13, 2002 11:08 AM
To: Martin W Sachs
Cc: ebxml-cppa-negot@lists.oasis-open.org
Subject: RE: [ebxml-cppa-negot] Negotiation Message Content


Marty,
Thank you very much for your comments.
I've updated the message content based on your suggestions except the
CPA ID part.  I assume that after the initial handshake no party needs
to pass around the CPA document at its entirety.  Having the CPAID in
the message is easier for both party to look up the actual CPA document
stored in some temporary store.

Does that make sense?  Have we decided that CPA Doc will always
accompany all transactions throughout any one Negotionation dialog?

Dale>>

Jean and Marty,

I am reading Jean's draft and Marty's comments and one thing that was
not clear to me 
was why Marty did not like to use the draft CPA's id or the CPA
template's id. 

I had gotten the impression that we were allowing two modes of
operation:

1. For those whose infrastructures allowed it, the draft CPA would be
referenced by URL
and, as necessary, one would access it through HTTP GET or FTP GET or
whatever. 
2. For those unable to resolve external references and/or unable to
publish to a http or ftp
server, there would be an option to send the CPA draft as necessary.
[Perhaps only 
initially and during the signing finale.]

For mode 1, it might be nice to check the cpaid value to see that the
reference did
resolve to the intended value... Otherwise, I guess the draft CPA or
template is
whatever we get by resolving the URL. Not certain I am that 
much of a RESTifarian for this use case.







Thanks,
Jean

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, August 12, 2002 8:01 AM
To: Jean Zheng
Cc: ebxml-cppa-negot@lists.oasis-open.org
Subject: Re: [ebxml-cppa-negot] Negotiation Message Content


 

 

 



Jean,

Thank you for updating the message document.  You have made a big step
forward.

Some comments:

1.1 Message Content

I suggest avoiding the use of conversationId at the application level.
A
non-ebXML messaging service might not have a place in its headers for
conversationId.  Also, depending on system implementation, the value of
conversationId might not be available to the application.  The
identifier
of the particular negotiation dialog should be an application-level
construct.  For clarity, I suggest using a term that includes the word
"negotiation" such as negotiationDialogId or negotiationInstanceId.

1.2 CPA ID

Let's avoid the term "CPA ID", since cpaId is an attribute within the
CPA
and is defined as the ID of a completed, agreed CPA.  We should identify
the CPA under negotiation by a separate identifier that is carried in
the
messages.  We could simply identify the CPA under negotiation by the
threadId, negotiationInstanceId, negotiationDialogId, or whatever term
we
pick.  There may be some advantage for future enhancements in keeping
the
ID of the CPA under negotiation separate from the negotiation dialog Id.

1.3 Offer and Counter Offer

Paragraph 1: In Hima's BPSS instance, both Parties are sending Counter
Offer documents once the original offer has been sent from Party A to
Party
B. So, I favor your Choice 2.

Last sentence of "Choice 2": I believe that Hima's BPSS has more
function
than the one in "CPPA Simple Negotiation Model v 0.06".  For now, I
suggest
that Hima's BPSS be the baseline for our work.  We will eventually need
to
decide what material from "v 0.06" will be useful in the negotiation
specification.

Last paragraph: I agree with this paragraph but we should not encourage
this behavior since it can lead to deadlock.  I suggest that the
specification recommend human to human contact following a "CPA Offer
Rejected" message.

2. CPA Offer Expired

We can either add this as a new message in the BPSS instance or we can
make
it a reason code on the "CPA Offer Rejected" message.  I prefer to treat
"Expired" as a reason code rather than a separate message.

Scenario:  This scenario can lead to both Parties sending a message at
the
same time (Party B sends its response to the offer or counter offer "a
little late" just as Party A is sending its "expried" message). I prefer
the scenario that you describe in the last paragraph of this section.
However it still has a possible problem with Party A sending a reject to
Party B's late message.  This would probaby require adding an additional
Business Transaction for this purpose.  We will also have to specifiy
something about dealing with the case where Party B "never" responds to
the
Party A's counter offer.

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


 

                      Jean Zheng

                      <jzheng@vitria.          To:
ebxml-cppa-negot@lists.oasis-open.org                                 
                      com>                     cc:

                                               Subject:
[ebxml-cppa-negot] Negotiation Message Content                        
                      08/08/2002 07:58

                      PM

 

 





Hello Everyone,
After browsing through the CPPA Negotionation progress (Thanks Marty for
the suggested reading materials!) during the past three months+, I've
made
some minor changes to the Message Contents based on Brian Hayes
suggestions
in March, such as changing Header/Payload to Business
Information/Business
Documents.

I think this is still compatible with Hima's sample.xml.  However, since
Hima will go through his xml files with us on the next conference call,
I
will make more updates after that.

I will mapped the message content into xml schema format once we are
confident that this doc has captured 90%+ of the required elements
during
negotiation process.

 <<NegotiationMessageContent.doc>>
Cheers,
Jean


#### NegotiationMessageContent.doc has been removed from this note on
August 12 2002 by Martin W Sachs