Re: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments

[Arvola Chan <arvola@tibco.com>]

Dale:

It may be unnecessary complexity to allow a channel
to be specified for each of the following MSH level messages:

- standalone Ack
    service=uri:www.oasis-open.org/messageService
    action=Acknowledgment

- standalone DeliveryReceipt
    service=uri:www.oasis-open.org/messageService
    action=DeliveryReceipt

- standalone Error
    service=uri:www.oasis-open.org/messageService
    action=MessageError

- StatusRequest
    service=uri:www.oasis-open.org/messageService
    action=StatusRequest

- StatusResponse
    service=uri:www.oasis-open.org/messageService
    action=StatusResponse

- Ping
    service=uri:www.oasis-open.org/messageService
    action=Ping

- Pong
    service=uri:www.oasis-open.org/messageService
    action=Pong

Because the MSG spec specifies the use of
uri:www.oasis-open.org/messageService, the above
actions technically do not belong under the ServiceBinding
associated with the BPSS instance that is being referenced,
as Marty has pointed out. Therefore, I prefer Marty's
suggestion of designating one channel to carry all standalone
MSH level messages, by adding an appropriate child
element under PartyInfo. We should also stipulate that
reliable messaging not be used for this channel.

Regards,
-Arvola

-----Original Message-----
From: Dale Moberg <dmoberg@cyclonecommerce.com>
To: Martin W Sachs <mwsachs@us.ibm.com>; Arvola Chan <arvola@tibco.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Wednesday, November 07, 2001 9:57 AM
Subject: RE: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments


If possible, I would like to take this
collectin of issues
up tomorrow again on the call. It relates
to a major proposed version 1.1 addition
that we so far have found useful.

The Arvola ActionBinding element
could possibly replace Override, but that is
a separate issue. As I understand these
ActionBinding elements (under ServiceBinding), they allow
introduction of 'actions' outside the specific service
in the ServiceBinding.

In particular,ActionBinding might be used for those special
actions such as MSH to MSH ones (these MSH to MSH
have service & actions values supplied by the Messaging spec,
but they do not have BPSS documents defining them--
they are not at the BP level).
And also, of course, Business signals, that are perhaps not part
of a particular BPSS defined collaboration, but can
be intermixed with any(?) collaboration.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, November 07, 2001 10:18 AM
To: Arvola Chan
Cc: David Fischer; ebXML Msg; ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments



Arvola,

The Override element is a child element of the ServiceBinding element.
The
v 1.0 CPP-CPA text for the ServiceBinding element states that it
identifies
a default delivery channel for all of the message traffice that is to be
sent to the party within the context of the identified
process-specification document.  For the override element, it states
that
it provides a party with the ability to map or bind a different delivery
channel to messages of a selected business transaction that is
associated
with the parent service binding element.

Given these words, we can't simply add an override element for MSH to
MSH
messages. I suppose we could concoct a BPSS description of MSH to MSH
messaging and add a ProcessSpecification subtree for this purpose.  I
also
thought about designating that delivery channel under ebXMLBinding but
since ebXMLBinding is part of a delivery channel, that's at least
circular
if not worst. See next paragraph for a better idea.

The simplest approach is to add an additional child element to PartyInfo
that designates a delivery channel for MSH to MSH messages.
Alternatively,
we could add an attribute to the DeliveryChannel element that permits a
particular delivery channel to be used for MSH to MSH messages.  I think
I
prefer adding a child element to PartyInfo because that would allow us
to
prescribe that only one such delivery channel be so designated (if
that's
what we want to do).  Either way, we need to pay some attention to the
wording because that element or attribute has to be described as usable
for
any messaging agent, not just the ebXML MSH, since that element or
attribute is in an area that is independent of messaging protocol.

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



Arvola Chan <arvola@tibco.com> on 11/07/2001 11:08:05 AM

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    David Fischer <david@drummondgroup.com>, ebXML Msg
       <ebxml-msg@lists.oasis-open.org>, ebxml-cppa@lists.oasis-open.org
Subject:    Re: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments



Marty:

Lines 1426 and 1427 in the 1.07 version of the spec (with
change bars turned on) state:

· The Service element MUST be set to:
uri:www.oasis-open.org/messageService/
· The Action element MUST be set to MessageError.

These values are to be used when an Error message is
sent on its own. Therefore, it is possible to have an Override
element in the CPA to designate the delivery channel to be
used for such messages.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Arvola Chan <arvola@tibco.com>
Cc: David Fischer <david@drummondgroup.com>; ebXML Msg
<ebxml-msg@lists.oasis-open.org>; ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, November 06, 2001 8:26 PM
Subject: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments


>
>Arvola,
>
>At the moment, the CPPA specification does not provide a means of
>designating delivery channels specifically for error messages. Delivery
>channels can only be designated per action or for the entire set of
>actions.  You are proposing a new issue for the CPPA-MSG interlock
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
>
************************************************************************
***
**********
>
>
>
>Arvola Chan <arvola@tibco.com> on 11/06/2001 08:19:41 PM
>
>To:    David Fischer <david@drummondgroup.com>
>cc:    ebXML Msg <ebxml-msg@lists.oasis-open.org>,
>       ebxml-cppa@lists.oasis-open.org
>Subject:    Re: [ebxml-msg] Comments on your Comments
>
>
>
>David:
>
>I have no problem with stipulating that Errors are never sent
>reliably. We just have to make it clear in the 1.1 spec.
>
>The CPP/A spec should indicate that any delivery channel
>designated for carrying Error messages (i.e., for the action
>MessageError) must not specify the use of Reliable Messaging.
>
>Regards,
>-Arvola
>
>-----Original Message-----
>From: David Fischer <david@drummondgroup.com>
>To: Arvola Chan <arvola@tibco.com>
>Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
>Date: Tuesday, November 06, 2001 7:19 AM
>Subject: [ebxml-msg] Comments on your Comments
>
>
>Arvola,
>
>One of your comments was on the restriction about not having Acks on
>Errors.
>We
>can have Acks on Errors if we stipulate no Errors on Acks.  If we want
>Errors on
>Acks then we must stipulate no Acks on Errors.  If we have both, then
we
>have
>the potential for endless loops.
>
>I question the need for Errors to be sent reliably.  I see some
significant
>benefit for having Errors returned on bad Acks.
>
>Regards,
>
>David Fischer
>Drummond Group.
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


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




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