Re: [ebxml-msg] Minutes 12/03/01 - Voting Meeting

[Arvola Chan <arvola@tibco.com>]

Marty:

My assumption has been that all of the attributes under the proposed
MessagingCharacteristics element in the CPA have essentially "per message"
semantics. The corresponding attribute/element must be set in the SOAP
message in order to elicit the expected behavior. The receiver is required
to verify that the behavior(s) requested in the incoming message is/are
consistent with agreements documented in the CPA.

When intermediaries that are not aware of the CPA are involved, the only way
to get them to participate in the reliable messaging behavior is to have an
AckRequested element in the SOAP envelope to request that behavior.
Specifically, I am referring to the use of intermediate Acks, and the
retransmission on intermediate Ack timeout from the next intermediary.

This treatment is also consistent with the use of the SyncReply element,
which exists only for the benefit of intermediaries.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: David Fischer <david@drummondgroup.com>
Cc: Arvola Chan <arvola@tibco.com>; ebXML Msg
<ebxml-msg@lists.oasis-open.org>
Date: Tuesday, December 04, 2001 5:50 AM
Subject: RE: [ebxml-msg] Minutes 12/03/01 - Voting Meeting



Some comments below, MWS:

****************************************************************************
*********

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 12/03/2001 09:43:28 PM

To:    Arvola Chan <arvola@tibco.com>, ebXML Msg
       <ebxml-msg@lists.oasis-open.org>
cc:
Subject:    RE: [ebxml-msg] Minutes 12/03/01 - Voting Meeting



Arvola,

If AckRequested is *true* in the CPA, then does the AckRequested element
have to
appear?  If it MUST appear, then why have it in the CPA?  I think the
Receiving
MSH must send an Acknowledgment in this case even if AckRequested does not
appear.  Actually, I would prefer that AckRequested MUST NOT appear if the
CPA
says *true* or *false*.

MWS:  I agree with the last statement.

If AckRequested is *perMessage* in the CPA, then what happens if the
AckRequested element does not appear?  The spec says this means no
Acknowledgment.  The default then is *false* if the CPA says *perMessage*.

MWS: This is a programming error.  The MSH should do nothing except forward
an error indication upward to the middleware/software layer that cares
about it.

I think we should not have multiple rules about *perMessage*.  If a default
is
provided in one case, then it should work the same in all cases.  Since the
absence of an Acknowledgment element means *false* then the absence of
duplicateElimination should also mean *false* and the absence of a signed
attribute should mean *false* (or in all cases it means take the default).

MWS:  The MSH SHALL not guess.  There are valid defaults, such as
specifying
the value of Ackrequested in the CPA and omitting the element from the
message.
Defaults must not be used to paper over software errors.  That can cause
untold
harm at both ends.

David.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Monday, December 03, 2001 5:05 PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg] Minutes 12/03/01 - Voting Meeting


David:

I don't agree with the last sentence in the following paragraph within your
meeting minutes:

>PerMessage parameters:  Colleen, what parameters have been identified.
Arvola:  >duplicateElimination, AckRequested, AckRequested/signed.  Dale:
perMessage in >CPA means no agreement.  Colleen: what about defaults.
Dale:
OK.  Ian:  add to >document, if there is a conflict then generate error /
define error ? <<next item>>.  >Consensus is that perMessage does not
require item to appear, there may be an >MSH default.

I have been assuming that the AckRequested element must be present in a
message before the receiver will return an Acknowledgment. The Message
Service Interface may have a default to allow the application above to omit
the specification of whether an Acknowledgment is desired. The sending MSH
must include an AckRequested element in a message if it expects to receipt
an Acknowledgment for it.

Similarly, the sending MSH must specify an appropriate value for the
duplicateElimination attribute in the QualityOfServiceInfo element, one
that
does not conflict with the specification within the CPA.

Regards,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Monday, December 03, 2001 12:51 PM
Subject: [ebxml-msg] Minutes 12/03/01 - Voting Meeting


These are the minutes from Monday's voting meeting.

I thought we achieved consensus on the error code issue concerning
NotSupported/Inconsistent but talking to some members afterwards, this is
not
clear.

Does anyone object to changing the error code on Ping, Pong, MessageStatus,
duplicateElimination and AckRequested to Inconsistent?  This means the only
thing in the spec with NotSupported is MessageOrder.

Regards,

David Fischer
Drummond Group
ebXML-MS Editor.



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