[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Minutes 12/03/01 - Voting Meeting
Marty, if AckRequested must always appear, then how do I send a message which DOES NOT request an Acknowledgment? David. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, December 04, 2001 7:50 AM To: David Fischer Cc: Arvola Chan; ebXML Msg 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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC