Re: T2: ackRequested attribute in Via element

[christopher ferris <chris.ferris@east.sun.com>]

Arvola, 

Please see below.

Cheers,

Chris

Arvola Chan wrote:
<snip/>
> 
> I disagree (whew! ;-) There is adequate information in the message header
> as well as in the CPA without abusing the Via element which is used
> exclusively
> for multi-hop message paths.
> 
> <arvola>
> Are you suggesting that the ackRequested and syncReply attributes in the Via
> element should only be used in the multi-hop case? The 1.0 spec requires you
> to use the Via element even for a single-hop situation if there is a need to
> set either one of the above two attributes.
> </arvola>

Where does the spec say anything about use of Via in cases other than multi-hop?

> 
> >
> > The concept of an Acknowledgement message to  support reliable messaging
> > seems muddled with the concept of the  Acknowledgement element which is
> > primarily used to provide non-repudiation  of receipt. My colleagues at
> 
> The Acknowledgment element is used EXCLUSIVELY for RM. The DeliveryReceipt
> is what has been provided for NR and other related business signals.
> 
> <arvola>
> If the Acknowledgement element is used exclusively for reliable messaging
> and not for non repudiation, then I don't see why it should include a
> ds:Reference element.

I think it might still be useful.

> 
> Also, if the Acknowledgement element is always included in an
> Acknowledgement message used to support reliable messaging, then it would be
> redundant to use the ackRequested attribute. Shouldn't deliverySemantics of
> OnceAndOnlyOnce already imply that the message must be acknowledged?

When deliverySemantics=OnceAndOnlyOnce in the header, and no Via element is present,
then yes, an Acknowledgment is required to be sent by the ultimate receiver
to the sending MSH (which is the prior node in the message path).

> 
> I have always wanted to ask you about the relationship between the
> DeliveryReceipt element and the notion of business signals used in the BPSS
> spec. The latter defines the payload structure of the business level signal
> messages but make no reference to the DeliveryReceipt element in the MSG
> spec. Is the application supposed to send the business signal messages and
> request the MSH to tag on a DeliveryReceipt element to the business signal
> messages? The ReceiptAcknowledgement DTD defined in section 9.1.1 in the
> BPSS spec already carries an originalMessageDigest element. Would that be
> redundant if the DeliveryReceipt element already carries a ds:Reference
> element?
> </arvola>

We had some last minute discussions with the BP team on this, but
it was too late to have them remove it from their spec.

<snip/>
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard