Definitely no. Delivery channel assignments are static properties
indicated in the CPA (or equivalent). There is no value in indicating a
delivery channel in the message header. Aside from that, the only place to
get that delivery channel to put in the message header is from the CPA, so
why bother?
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 11/07/2001 12:43:14 PM
To: Martin W Sachs/Watson/IBM@IBMUS, Arvola Chan <arvola@tibco.com>
cc: 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
Should MSG add an optional attribute to CPAid to designate the
deliveryChannel?
David.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, November 07, 2001 11: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>