RE: Minor Issue: SyncReply and acknowledgments

["Burdett, David" <david.burdett@commerceone.com>]

Chris

My interpretation of the current specification is different from yours. My
response below is quite lengthy, as I wanted to point out the parts of the
spec that I believe cause the problem ...

The issue I have is that it is quite possible in the current spec for BOTH
deliveryReceiptRequested AND ackRequested (the RM Ack) to be set to TRUE in
the message header. It is also quite possible (and I know you disagree with
this Chris) for a MSH to use the values in the header to determine its
behavior.

Now if deliveryReceiptRequested is set to true then the spec says (lines
516-7) ...

>>The deliveryReceiptRequested attribute is used by a From Party to indicate
whether a message received by the To Party should result in the To Party
returning an acknowledgment message containing an Acknowledgment element
with a type of deliveryReceipt.<<

... and if ackRequested is set to true then the spec says (lines 1390-2) ...

>>The AckRequested value is used by the sending MSH to request that the
receiving MSH returns an acknowledgment message with an Acknowledgment
element with a type of Acknowledgment.<<

So if deliveryReceiptRequested and ackRequested are BOTH set to true, and
the recipient of the message is the To Party, then the To Party, according
to the spec, needs to return an Acknowledgment element with type of
DeliveryReceipt AS WELL AS an acknowledgement element with a type of
Acknowldgement.

Now the definition of syncReply says (lines 803-5) ...

>>If the syncReply attribute is present with a value of true, the MSH must
get data from the application or business process and return it in the
payload of the synchronous response.<<

My interpretation of this is that both Acknowledgement elements (one with
type=DeliveryReceipt and one with type=Acknowledgement) would need to be
returned in the same message. However this is currently IMPOSSIBLE since
there is only ONE Acknowledgment element in the header. 

My suggestion is that we have separate elements called "DeliveryReceipt" for
the DeliveryReceipt and "Acknowledgement" and the RM Acknowledgement in the
header so that both can be sent back in the same message. The other
alternative would be to add rules in the spec that say if you should return
both a DeliveryReceipt as well as a RM Ack then you don't send the RM Ack.
Either way the spec needs to change, otherwise we will be left with a spec
that will be impossible to build to in this area.

Secondly Chris you suggested that the "RM ack should always be returned on
the same session". If we want to do this (which I think is a good idea) then
we need to say so in the spec as my interpreation of the current definition
of SyncReply in the spec does not support this. If we do want to do this
then we should replace the sentence above (lines 803-5) with something like
the following ...

>>If the syncReply attribute is present with a value of true, the MSH must
return in the synchronous response:
* an Acknowledgment element if a Reliable Messaging acknowldgment is
required,
* a DeliveryReceipt element if the MSH is operated by the To Party and a
delivery receipt is required, and
* the application or business process response in the payload that has been
obtained from the application.<<

Best wishes.

David.

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, March 15, 2001 8:06 AM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: Re: Minor Issue: SyncReply and acknowledgments


David,

Please see below.

Cheers,

Chris

"Burdett, David" wrote:
> 
> I suppose I did not explain it very well.
> 
> Right now we have everything, MSH Ack, business response, etc coming back
on
> the same session if syncReply is true and nothing if it is false.

Not true at all. We concluded that the CPA or the BP would be the
source of "what" is returned aynchronously, that the MSH would only
flag the exchange as sync or not.

> 
> I think a frequent case will be for the MSH ack for reliable messaing
> purposes to come back on the same session but the business response or
other
> signal on a separate session. We **could** say that for syncrhonous
> responses, the MSH ack always comes back synchronously.

I also believe that for the HTTP binding specifically that the RM
ack should always be returned on the same session. In fact, in my 
explorations of a SOAP processor, it seems that at least for now,
a synchronous response is implicit in the architecture of the code.

> 
> David
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Saturday, March 10, 2001 8:35 AM
> To: Burdett, David
> Cc: ebXML Transport (E-mail)
> Subject: Re: Minor Issue: SyncReply and acknowledgments
> 
> David,
> 
> How do you interpret that paragraph as requiring the
> acknowledgment to be sent back on a separate connection?
> 
> You have lost me.
> 
> Chris
> 
> "Burdett, David" wrote:
> >
> > Currently this spec says the following ...
> >
> > "When the syncReplyMode parameter in the ebXML Header is set to "true",
> the
> > response message(s) MUST be returned on the same HTTP connection as the
> > inbound request," (Lines 2449-53)
> >
> > My reading of this is that a message that is a just an acknowledgement
> must
> > also come back on a separate connection. Is this what we want? I would
> have
> > thought that the acknowledgment should always come back on the same
> > connection.
> >
> > Thoughts?
> >
> > David
> >
> > Solution Strategy, Commerce One
> > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704; Pager: +1 (888)
936
> > 9599
> > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org