Re: [ebxml-cppa] AckRequested and DeliveryReceiptRequested

[Tony Weida <rweida@hotmail.com>]

I also agree with Arvola's proposal to separate BPCharacteristics from
MSGCharacteristics.

Marty's suggestion to locate the syncReplyMode attribute within
MSGCharacteristics makes sense too, since syncReplyMode certainly describes
messaging behavior.

On the other hand, while syncReplyMode does't override a corresponding
attribute in the BPSS XML document, it does appear to allow an override of
the BPSS 1.01 specification itself -- Sections 6.6.2.1 (ControlException)
and 6.6.2.2 (Business Protocol Exceptions) both state categorically that
"This business signal is asynchronously returned to the initiating role that
originated the request."  I'm not subscribed to the BPSS list, so perhaps
Brian can take this up as an interlock issue?

Thanks,
Tony

----- Original Message -----
From: "Martin W Sachs" <mwsachs@us.ibm.com>
To: "Arvola Chan" <arvola@tibco.com>
Cc: <ebxml-cppa@lists.oasis-open.org>
Sent: Wednesday, November 07, 2001 8:48 PM
Subject: Re: [ebxml-cppa] AckRequested and DeliveryReceiptRequested


>
> Arvola,
>
> I agree with your proposal to replace the Characteristics element by
> BPCharacteristics and MSGCharacteristics.
>
> The Characteristics element currently includes a syncReplyMode attribute.
> I think that this attribute is really MSG-related and suggest moving it to
> MSGCharacteristics.
>
> 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 08:00:14 PM
>
> To:    ebxml-cppa@lists.oasis-open.org
> cc:
> Subject:    [ebxml-cppa] AckRequested and DeliveryReceiptRequested
>
>
>
> The MSG spec defines these elements as follows:
>
>  <element name="AckRequested">
>   <complexType>
>    <attribute ref="tns:id"/>
>    <attribute ref="tns:version" use="required"/>
>    <attribute ref="soap:mustUnderstand" use="required"/>
>    <attribute ref="soap:actor"
> default="urn:oasis:names:tc:ebxml-msg:service:toPartyMSH"/>
>    <attribute name="signed" type="boolean"/>
>   </complexType>
>  </element>
>
>  <element name="DeliveryReceiptRequested">
>   <complexType>
>    <attribute ref="tns:id"/>
>    <attribute ref="tns:version" use="required"/>
>    <attribute ref="soap:mustUnderstand" use="required"/>
>    <attribute name="signed" type="boolean"/>
>   </complexType>
>  </element>
>
> These elements determines whether the receiving MSH should return a
(signed
> or unsigned) Acknowledgment / DeliveryReceipt. I think we should add
> corresponding AckRequested and DeliveryReceiptRequested elements (minus
the
> tns:id, tns:version, soap:mustUnderstand attributes) under DeliveryChannel
> to guide the construction of the above elements during the packaging of an
> ebXML message. In other words, I don't think that the decision to ask for
a
> signed Acknowledgment or DeliveryReceipt should be derived from the
> NonRepudiation element (under DocExchange). Instead, it should be based on
> the corresponding AckRequested and DeliveryReceiptRequested elements in
the
> CPA.
>
> Marty has previously indicated that the Characteristics element provides
> for
> overriding of BPSS attributes only. Perhaps we can replace Characteristics
> with BPCharacteristics and MSGCharacteristics, and keep the AckRequested
> and
> DeliveryReceiptRequested elements under MSGCharacteristics. In addition,
> MSGCharacteristics should carry a duplicateElimination attribute to guide
> the construction of the QualityOfServiceInfo element within MessageHeader
> which also has a duplicateElimination attribute.
>
> -Arvola
>
>
>
> ----------------------------------------------------------------
> 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>
>