OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-negot message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ebxml-cppa-negot] [UMM] 10/16/2002: [UMM] Chapter 8-9 R10

In the CPPA-Negotiation team, we have been discussing that an
ReceiptAcknowledgement and an AcceptanceAcknowledgment may be required
on a Response during CPA Negotiation (for Final CPPA Response Document).

In looking at Chapter 8 and specifically Chapter 9, I do not see that
any pattern provides the capability to have an AcceptanceAcknowledgment
on the Response (ReceiptAcknowledgement included).

See some brief email attachments for the case herein.

Should any of the CPPA-Negotiation team wish to expand the discussion,
feel free to do so.

Can we log this as an item against UMM R10.

Thank you.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946
--- Begin Message --- 




I have reviewed the new BPSS instance and am incorporating it into the
draft specification.

There are some loose ends that we need to consider before we are
finished
with the specification:

There are no condition tests for rejection conditions in the exchange of
the final CPAs. Reasons can include:
- the final CPA does not agree with the recipient's understanding of
what
should be in it (some kind of state-tracking mismatch).
- The signature on the final CPA cannot be validated.
- The second signature on the double-signed CPA cannot be validated.
- An acknowledgment was received when a double-signed CPA was expected.

Two of the the business document names contain the characters "DOC"
while
the other contain "Doc".  This is not necessarily a problem but if
comparisons of text strings are case-sensitive, it could cause some
confusion or programming errors.

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>
--- End Message ---
--- Begin Message --- 




After sending my comments on the new BPSS earlier this afternoon, I
noticed
the posting below.  I am not sure that I understand "First document
envelope supports "a" & "b". I believe that the statement means the "CPA
Final Response DOC" document is used for both acceptance and reject. I
agree that this can be done.  However, except for this case, a message
receipient can determine success or failure from the business document
name
in the message.  For the approach below, we will have to define a
separate
success/failure indicator in the message and that indicator will have to
be
checked whenever the message is "CPA Final Response DOC". Is there a
technical reason why we have to special-case this message?

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
************************************************************************
*************
----- Forwarded by Martin W Sachs/Watson/IBM on 10/15/2002 04:14 PM
-----

 

                      himagiri@sybase.c

                      om                       To:
"ebxml-cppa-negot@lists.oasis-open.org"

 
<ebxml-cppa-negot@lists.oasis-open.org>

                      10/14/2002 01:48         cc:

                      AM                       Subject:
[ebxml-cppa-negot] latest ebxml-cppa-negot.zip

                      Please respond to

                      himagiri

 

 





 All

Attaching the latest bpss and cpa.

Bpss has the following changes.

1) Added a new document evelope for responding business activity
for final transaction. This is different to what we talked.
This way the response to the request in the final transaction
(Signed or unsigned final CPA) could be three logical choices.
a) Message indicating acceptance b) Message indicating reject
c) Message including double signed CPA.

First document envelope supports "a" & "b" and Second document envlope
supports "c".

What do you guys think of this approach in contrast to having a new
Business Transaction just for sending the final double signed CPA?

I've added support in the CPA for the new transaction.

-hima


**** Attachment ebxml-cppa-negot.zip has been removed from this note on
15
October 2002 by Martin W Sachs ****


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
--- End Message ---
--- Begin Message --- 
I just sent BPSS which is different compared to the suggestion made.
As BPSS supports multiple responses, why not send the
double signed CPA as response if the final CPA sent 
was signed. This makes the BPSS simpler.

-hima

Martin W Sachs wrote:
> 
> This is to clarify one of my replies below, regarding return of the
CPA
> with the second signature.
> 
> If it is not feasible to include a test for the presence of the first
> signature in the BPSS instance, then I suggest the following:
> 
> 1.  Responding Business Activity "Final_CPA_BT_RespBA" sends one of
two
> response messages:
> - "CPA Final Response Doc" if the received CPA was not signed
> - "Signed CPA Response Doc" if the received CPA was signed.
> 
> 2.  The normative text in the specification states the above rule.
> 
> 3. If the received CPA was not signed, the choreography ends
(success).
> 
> 4. If the received CPA was signed, a transition takes place to a new
> business transaction in which the recipient of the signed CPA returns
the
> double-signed CPA to the other Party (requesting businss transaction).
> 
> 5. The responding business transaction in (4) indicates success ("CPA
Final
> Response Doc") or failure ("CPA Reject Doc").  I'm not sure what
reject
> conditions would be possible in (4) but I think it's a good idea to
include
> that possiblity.
> 
> 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
>
************************************************************************
*************
> ----- Forwarded by Martin W Sachs/Watson/IBM on 10/07/2002 03:08 PM
-----
> 
>                       Martin W Sachs
>                                                To:
"Himagiri(Hima) Mukkamala" <himagiri@sybase.com>
>                       10/07/2002 02:37         cc:
ebxml-cppa-negot@lists.oasis-open.org
>                       PM                       From:    Martin W
Sachs/Watson/IBM@IBMUS
>                                                Subject: Re:
[ebxml-cppa-negot] BPSS comments(Document link: Martin W. Sachs)
> 
> 
> 
> 
> 
> 
> 
> Hima,
> 
> Here are my replies  (MWS:).
> 
> Can we use CPA Reject doc for this reject case. Depending on what we
agree
> on, I can change the BPSS and add success and failure conditions for
> CPA_Final_BT
> 
> MWS:  I believe that we can used CPA Reject Doc for this case
(rejection of
> the final CPA).
> 
> Can we capture this in the document or should we add this in the
process
> definition. IEUR(tm)m comfortable with adding it in the document
where we can
> essentially say EURoeIf the NDD has a field of singed set and the CPA
itself
> sent in the CPA FINAL DOC has a signature, CPA Response Doc should
have a 2
> second signature if the CPA is acceptableEUR
> 
> MWS:  If you would prefer, we can define the test for the presence of
the
> first signture as normative text in the document but I believe that
the
> actual return of the CPA with two signatures should be captured as a
BPSS
> transaction that follows from the receipt of the CPA with the first
> signature.
> 
> These conditions identify the fact that success from
EURoefromBusinessStateEUR
> indicates the success of the collaboration. Same for failure. No
condition
> expressions indicate that any response would leave it the
> BusinessTransaction in a state of success.
> 
> MWS:  OK.  I will capture this point in the explanatory text.
> 
> Going back to your comment (1.1) We may need to add a condition
expression
> that indicates the fact that success in only when a EURoeCPA Final
Response
> DocEUR is sent but not when EURoeCPA Final Reject DocEUR is sent.
> 
> MWS:  Yes, we need the above.
> 
> I assume we use different terminology just for explicit
differentiation.
> They all might refer to same standard CPA location.
> 
> MWS:  My comment may not have been understood. We have been discussing
> allowing for either attaching the actual document (CPA template, NDD,
final
> CPA) to the message or including its URL in the message.  Is it
practical
> to allow both options?  If so, does anything have to be explicitly
included
> either in the BPSS instance or in the NCPA?
> 
> I think when reference to ID is made, itEUR(tm)s explicitly named as
> EURoe<element>idEUR or EURoe<element>idRefEUR in the BPSS spec.
Any specific places
> where itEUR(tm)s not explicit? Let me know and I can send a comment
on BPSS spec
> to WG.
> 
> MWS:  I agree that the BPSS distinguishes use of name attribute from
use of
> ID attribute.  I was only asking whether there is a specific reason
for
> using one or the other.
> 
> 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
>
************************************************************************
*************
> 
> 
>                       "Himagiri(Hima)
>                       Mukkamala"               To:       Martin W
Sachs/Watson/IBM@IBMUS
>                       <himagiri@sybase.        cc:
ebxml-cppa-negot@lists.oasis-open.org
>                       com>                     Subject:  Re:
[ebxml-cppa-negot] BPSS comments
> 
>                       10/07/2002 12:14
>                       PM
> 
> 
> 
> Marty,
> 
> Attaching document with my comments highlighted..
> 
> thanks
> hima
> 
> Martin W Sachs wrote:
> 
> > My comments on the 9/16 BPSS instance are attached.
> >
> > Regards,
> > Marty
> >
> > (See attached file: BPSS.comments.30Sept02.doc)
> >
> >
>
************************************************************************
*************
> 
> >
> > 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
> >
>
************************************************************************
*************
> 
> >
> >
>
------------------------------------------------------------------------
> >                                  Name: BPSS.comments.30Sept02.doc
> >    BPSS.comments.30Sept02.doc    Type: WINWORD File
(application/msword)
> >                              Encoding: BASE64
> 
> #### BPSS.comments.30Sept02.doc has been removed from this note on
October
> 07 2002 by Martin W Sachs

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
--- End Message ---

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC