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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

David,

When the CPA's AckRequested attribute has the value "perMessage," it
has been agreed that (1) whatever the sender indicates in the
message is to be honored and (2) no "Inconsistent" error check
is needed. That means that if a sender includes the Header element
requesting Acks, then the receiver is to return the Ack.
If the sender omits the indication that an Ack is desired, act 
accordingly, and don't send the Ack. 

Don't change the semantics of "perMessage" please! 

We have struggled for some time to arrive 
at a way to enforce agreed upon values (using the CPA)
and also to have an agreement that lets the Header values 
alone determine behavior. Why mess with this now?

Dale

PS:

Also, as Arvola has indicated, the other two values that
the CPA uses are now "always" and "never". For the
AckRequested attribute, the "always" value means the
receiver has agreed to always acknowledge what the
sender sent, for the governing ServiceBinding and PartyIds.
If the Header element requesting an Ack is ever
missing, for that Service and PartyId,
an error is thrown.  The receiver just does not
silently send the unrequested Ack.

The "never" value means never ack it, and if a sender
asks for an Ack, an error is thrown back; otherwise,
it sends no Ack back, just as "asked."



-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Tuesday, December 04, 2001 12:43 PM
To: Christopher Ferris
Cc: Martin W Sachs; Arvola Chan; ebXML Msg
Subject: RE: [ebxml-msg] Minutes 12/03/01 - Voting Meeting


Yes Chris, that's exactly what I said before.  The absence of
AckRequested
implies *false*.

IMO, AckRequested should only appear IF CPA says *perMessage*.
Otherwise,
AckRequested should not appear at all -- use the CPA.

David.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Tuesday, December 04, 2001 10:58 AM
To: David Fischer
Cc: Martin W Sachs; Arvola Chan; ebXML Msg
Subject: Re: [ebxml-msg] Minutes 12/03/01 - Voting Meeting


It must ALWAYS be present when you WANT an acknowledgment.
Its absense implies that you don't want one.

Cheers,

Chris

David Fischer wrote:

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