OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


David:

One reason why the AckRequested element MUST be in the message is that it
may be targeted for the next MSH, if intermediate Acks rather than
end-to-end Acks are desired. Even though the from party and to party may be
aware of the CPA parameters, intermediaries are not privy to that
information.

For consistency reason, the QualityOfServiceInfo element with the
duplicateElimination attribute set to true should also be present in the
message header to trigger duplicate elimination behavior on the part of the
receiver.

Regards,
-Arvola

-----Original Message-----
From: Christopher Ferris <chris.ferris@sun.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 7:34 AM
Subject: Re: [ebxml-msg] Minutes 12/03/01 - Voting Meeting


>No, the AckRequested element (SOAP block) MUST be in the
>message for RM to function. The indicator in the CPA is for
>the sending node to determine whether or not to include the
>AckRequested element, not for the receiving end to determine
>whether RM is in vogue or not.
>
>Cheers,
>
>Chris
>
>David Fischer wrote:
>
>> 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*.
>>
>> 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*.
>>
>> 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).
>>
>> 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>
>>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC