Re: Delivery Receipt,NRR and MSG/CPPA/BPSS (mis-)alignment andthelayering mishmash (was jumbledinto: reliable messaging - hop by hop)

[Arvola Chan <arvola@tibco.com>]

David:

I am mostly arguing that the MSG, CPP/A, and BPSS specs must
be aligned with respect to the concept of non repudiation of
receipt. I think the main function of reliable messaging is to
provide once and only once delivery semantics, rather than
to provide non repudiation of receipt.

In the BPSS specification, a business process may require non
repudiation of receipt without isGuaranteedDeliveryRequired
being set to true. NRR is satisfied by the sending of a business
level signal (a ReceiptAcknowledgement) message.

"The property isIntelligibleCheckRequired allows partners to agree
that a message should be confirmed by a Receipt acknowledgement
only if it also is legible." (lines 725 to 727)

"The way to specify that a receiptAcknowledgement is required is to
set the parameter timeToAcknowledgeReceipt to any proper time
duration other than zero. If this parameter has been set to a
proper nonzero time duration, optionally either or both of the
isIntelligibleCheckRequired and  isNonrepudiationOfReceiptRequired
parameters may also be set  to ‘Yes’."  (lines 1229 to 1234)

The DeliveryReceipt used in reliable messaging does not satisfy
the NRR requirement specified by BPSS because the MSH does
not deal with payload validation.

The BPSS spec includes a DTD for the ReceiptAcknowledgement
message. An original message digest is included. This is carried
in the message payload and can be used in conjunction with the
RefToMessageId in the message header to provide non repudiation
of receipt.

Cheers,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; Burdett David
<david.burdett@commerceone.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>; ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>; ebtwg@lists.ebtwg.org
<ebtwg@lists.ebtwg.org>
Date: Monday, September 03, 2001 4:24 PM
Subject: RE: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
andthelayering mishmash (was jumbled into: reliable messaging - hop by hop)


>Arvola,
>
>The main function of RM is to provide a receipt to the sender, either the
>previous hop or the original sender.  If I send using NRR isn't that by
>definition RM since there is a receipt (end-to-end RM)?  I don't understand
how
>we can have NRR and NOT RM?  Seems like NRR is automatically RM (yes I know
RM
>can also mean idempotence...).  If you mean we can have end-to-end NRR/RM
>without hop-to-hop RM then I agree with you.
>
>It seems to me that basic security requires NRR.  If we don't do NRR, how
can
>the sender be assured that the receipt is for the original message?  Just
having
>RefToMessageId in the Delivery Receipt message does not assure that the
message
>arrived without change or that the receipt isn't mistakenly for another
message
>but with the wrong RefToMessageId.  With NRR there is an absolute tie
between
>the Receipt and the original message and there is assurance of who sent the
>DR -- you have to have both.  What good is a DR without NRR, there would be
no
>legal standing.  Even with NRR there can be argument (Dale's wiggle room)
but we
>do the best we can.
>
>Regards,
>
>David Fischer
>Drummond Group.
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Friday, August 31, 2001 8:01 PM
>To: Burdett David; ebxml-msg@lists.oasis-open.org;
>ebxml-cppa@lists.oasis-open.org; ebtwg@lists.ebtwg.org
>Subject: Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
>andthelayering mishmash (was jumbled into: reliable messaging - hop by
>hop)
>
>
>David:
>
>I agree in general with your statements of fact and your proposed
>course of actions. Some minor comments are enclosed.
>
>Regards,
>-Arvola
>
>-----Original Message-----
>From: Burdett, David <david.burdett@commerceone.com>
>To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>;
>ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>;
>ebtwg@lists.ebtwg.org <ebtwg@lists.ebtwg.org>
>Date: Friday, August 31, 2001 4:57 PM
>Subject: RE: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
>andthelayering mishmash (was jumbled into: reliable messaging - hop by hop)
>
>
>>Chris/Dale/Arvola/Scott
>>
>>I agree with just about everything that was said in your recent emails on
>>this topic
>>
>>I also think we are getting close to a consensus and so perhaps we can
take
>>the next step and come to a resolution.
>>
>>So below I have attempted to state the current consensus as a "statement
of
>>fact" - i.e. there should be no disgareements on this ;)
>>
>>I then propose a course of action designed to achieve resolution of the
>>issue.
>>
>>Can everyone please:
>>1. Review the statement of fact and indicate any corrections or omissions.
>>2. Review the proposed set of actions and indicate whether they think they
>>are appropriate ... again please indicate any improvements
>>
>>Once we agree then we can carry out the actions and ... Bingo! ... the
>>decision is made.
>>
>>Regards
>>
>>David
>>====================
>>BACKGROUND
>>Firstly, I think we haved recognized that there are two types of receipt:
>>1. Messaging Infrastructure Receipts (i.e. generated by the MSH)
>>2. Application Level Receipts (i.e. generated by the application or
process
>>that will process the payload in a message)
>>
>>The receipts generated by the messaging infrastructure also fall into two
>>categories:
>>1. Point-to-point receipts - i.e. a MSH acknowledges receipt of a message
>>back to the sending MSH when there are no other MSHs inbetween (these are
>>Acknowledgment Messages in the current spec)
>>2. End-to-end receipts - i.e. a MSH at the To Party sends a message back
to
>>the From Party to indicate that the message has been received (these are
>>Delivery Receipts in the current spec)
>>
>>There has also been a lot of our debate around:
>>1. Whether any (or all) of these receipts could/should/must be used for
>>non-repudiation in ebXML
>>2. How receipts such as these overlap with receipts specified in the ebXML
>>MSG, BPSS and CPPA specs.
>>3. The extent to which these receipts can/should/might/must? be
substitutes
>>for similar messages that exist in other protocols, e.g. RosettaNet.
>>
>>STATEMENT OF FACT
>>So here's my take on the consensus we have reached presented a series of
>>statements of fact:
>>1. There is agreement on the need for Point-to-point receipts
>>(Acknowledgment Messages) in the ebMS spec
>
><ac>
>It is not entirely clear if the Acknowledgement message is needed
>in the single-hop case (just having the DeliveryReceipt may be
>sufficient).
>
>The 1.0 spec says that a minimal Acknowledgement message does
>not need to carry an Acknowledgement element. The truth or falsity
>of that statement needs to be clarified.
></ac>
>
>>2. There is some support for keeping End-to-end receipts in the current
>ebMS
>>spec, the main dissenter being Chris F
>>3. There is some support for removing End-to-end receipts from the current
>>ebMS spec - the main proposer being Chris F
>>4. There is agreement that Application Level Receipts are not part of the
>>ebMS spec
>>5. There is consensus that we need to consider NRR as part of the ebMS
>spec.
>>6. There is consensus that:
>>   6a) A signed End-to-End receipt "can" (see note 1) be used to provide
>>some measure of non-repudiation
>
><ac>
>I still think that support for non repudiation of receipt should be
>independent
>of the use of reliable messaging. The To Party (application) should be
>allowed to direct the To Party MSH to generate a signed DeliveryReceipt
>in case reliable messaging is not being used but non repudiation of
>receipt is desired.
></ac>
>
>>   6b) Complete Non Repudiation will in some circumstances require signed
>>Application Level Receipts
>
><ac>
>I also like to get a clarification on the meaning of using signed
>intermediate
>Acknowledgements. Does it mean that intermediaries are required
>to archive messages for non repudiation purposes? If not, is there
>any point in asking for signed intermediate Acknowledgements?
></ac>
>
>>7. There is consensus that there is overlap between the various types of
>>"ebXML Receipts" (in the MS, CPP/A & BPSS specs) that needs to be resolved
>>8. There is agreement that there is overlap between the "ebXML Receipts"
>and
>>similar receipts in other specs, for example RosettaNet.
>>9. Other standards groups, e.g. RosettaNet, OAG, have stated that they
want
>>to adopt the ebXML messaging spec
>>
>
><ac>
>RosettaNet is planning to adopt the BPSS scheme for describing PIPs.
>It has already publicly endorsed the messaging spec. Given the tight
>relationship between the MSG and CPP/A specs, I think there is good
>likelihood
>that the CPP/A spec will also be adopted to support automated configuration
>of trading partners. Alignment between the MSG/CPPA/BPSS specs is
>important to RosettaNet.
></ac>
>
>>Note 1. I use the word "can" in 6a) above because all the security related
>>aspects of signing message have to be used in an appropriate way, e.g.
>trust
>>hierarchies, privacy of keys, etc before an End-to-End receipt could be
>used
>>for non-repudiation
>>
>>PROPOSED ACTIONS
>>Given the above "Statement of Fact" I propose that we do the following:
>>1. Hold a vote on whether or not End-to-End Receipts (signed Delivery
>>Receipts) stay in the ebMS spec, and if the result is positive ...
>>2. Include a section in the spec on Non Repudiation explaining the
benefits
>>and limitations of using a signed Delivery Receipt for this purpose - this
>>should reflect the recent discussions on this list and needs be separately
>>agreed
>>3. Set up a joint sub-team between MSG, CPP/A and BPSS project teams to
>>create a common approach towards the specification and use of "receipts".
>>This team should seek input from RosettaNet and OAG (only?) to make sure
>>that the methods identified meet the needs of these standards groups.
>>4. Revise the ebMS specification taking the results of the previous three
>>steps into account
>>4. Let other standards groups, such as RosettaNet and OAG build on the
ebMS
>>spec as they see fit.
>>
>>Thoughts?
>>
>>David
>>
>>
>>Arvola ...
>>>>>One thing I like to see clarified in the MSG spec is that signed
>>DeliveryReceipts are not intended to satisfy the NRR requirement for
>>business signals in the UMM model that underlies the BPSS spec.<<<
>>
>>Define what it is but remember trust.
>>
>>Arvola ...
>>>>>Yes, ReceiptAcknowledgements are generated by the
>>RosettaNet middleware. It may not be entirely feasible for the
>>the middleware to automatically generate the
>>AcceptanceAcknowledgement because the validation of
>>business rules is withint the domain of the private processes.
>>However, this issue is kind of moot because no PIP uses
>>the AcceptanceAcknowledgement signal.<<<
>>
>>Scott H ...
>>>>>I would hope that Rosettanet would throw away OASIS Messaging would
do -
>>but all of this said without detail involvement with the Rosettanet
>>mapping.<<<
>>
>>Scott H ...
>>>>>I agree. Further, I suggest it [the Delivery Receipt] be renamed to
>>"MessageReceipt".<<<
>>
>>-----Original Message-----
>>From: Arvola Chan [mailto:arvola@tibco.com]
>>Sent: Friday, August 31, 2001 1:06 PM
>>To: christopher ferris; ebxml-cppa@lists.oasis-open.org;
>>ebxml-msg@lists.oasis-open.org
>>Cc: ebtwg@lists.ebtwg.org
>>Subject: Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
>>andthelayering mishmash (was jumbled into: reliable messaging - hop by
>>hop)
>>
>>
>>Dale and Chris:
>>
>>My comments are bracketed by <ac> and </ac>.
>>
>>Cheers,
>>-Arvola
>>
>>-----Original Message-----
>>From: christopher ferris <chris.ferris@east.sun.com>
>>To: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>;
>>ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
>>Date: Friday, August 31, 2001 11:28 AM
>>Subject: Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
>>andthelayering mishmash (was jumbled into: reliable messaging - hop by
hop)
>>
>>
>>Dlae,
>>
>>Some comments below.
>>
>>Cheers,
>>
>>Chris
>>
>>Dale Moberg wrote:
>>>
>>> David,
>>>
>>> I read one of your recent notes in which
>>> you present some interesting alternatives,
>>> and I would like to comment on these in the
>>> hopes of aligning BPSS, MSG, and CPPA on
>>> the NRR issues.
>>>
>>> David Burdett says, almost as an aside:
>>> "The other alternative would be to provide
>>> two variations of the Delivery
>>> Receipt, one which indicated that the
>>> To Party MSH had received and the
>>> second that the To Party Application
>>> had been notified of the message, but I
>>> don't really want to go there as it
>>> is definitely additional functionality."
>>>
>>> Despite your disclaimer, I think this is
>>> an area we should discuss so that we
>>> can align BPSS CPPA and MSG on NRR.
>>> (Maybe pretty soon I can write a
>>> sentence consisting entirely of
>>> acronyms.)
>>>
>>> I think that there _could_ be one DeliveryReceipt
>>> with an extension mechanism
>>> that could be used for all the additional
>>> conditions that tend to get
>>> tacked on to the DeliveryReceipt:
>>> One condition would be that the To Party
>>> Application was notified, another would be
>>> that the syntax had been checked,
>>> a third, that the syntax had been checked
>>> and the data typing had been
>>> checked and the values were in
>>> allowed ranges, and so on. We would in CPPA
>>> need an enumeration for the main
>>> different extensions, and a general
>>> "namespace supported" element to gesture at
>>> yet unthought of extensions (or whatever
>>> is the extension mechanism du jour).
>>
>>This is what the BPSS signals (which are derived
>>directly from RNIF) are supposed to handle. There
>>are a set of predefined patterns for these signals.
>>A business transaction (I think that's the right
>>term) adopts one of the selected patterns as defined
>>by the identified attributes on that Business Transaction.
>>
>><ac>
>>I believe the BPSS signals are directly derived from the
>>UN/CEFACT Modeling Methodology (UMM). I don't know
>>the exact relationship between RosettaNet and the UMM.
>>Let me forward this message to the ebtwg alias to see if
>>someone can shed light on the history.
>></ac>
>>
>>>
>>> But strictly speaking,
>>> the functionality in these NRR
>>> extensions is beyond what
>>> a MSH needs to carry out its main
>>> jobs, even when that job includes
>>> supporting NRR. Let me briefly
>>> expand on this.
>>
>>Agreed, because the business signals (one of which
>>is the ReceiptAcknowledgment which contains an
>>element for NonRepudiationInformation) necessarily
>>involve application level processing such as
>>verifying that the message is processable (e.g.
>>it can be parsed/processed).
>>
>><ac>
>>I have always interpreted application level to mean any
>>software that is above the Message Service Interface.
>>In this sense, I agree with the BPSS spec that signals
>>are application level messages. The RosettaNet
>>Implementation Framework distinguishes public
>>processes from private processes. Public processes
>>implement the RosettaNet PIP specifications to
>>exchange standard business documents over the
>>Internet. They interface with private processes that
>>are internal to the enterprise. Private processes are
>>responsible for orchestrating the activities within
>>back-end business systems.  The RosettaNet public
>>processes are responsible for generating signals.
>>Logically, they are implemented in the middleware
>>that sits between the MSH and the private processes.
>></ac>
>>
>>>
>>> NRR is something that
>>> rarely ends up getting uniquely
>>> characterized in terms of what needs
>>> to be _implemented_. We know what we
>>> want to obtain more or less, but can rarely agree
>>> upon what will always be sufficient
>>> to attain it. Because any processing
>>> exception that occurs after the MSH
>>> finishes its work may provide the To-Party
>>> a legal "way out," NRR always seems to be falling
>>> short of removing all wiggle room.
>>
>>Agreed.
>>
>>>
>>> I seriously doubt that we will remove
>>> all the wiggle room, and that there will always
>>> be some exceptional condition after receipt
>>> and after sending a DeliveryReceipt, that
>>> would result in a processing failure on
>>> the ReceivingParty side (bad syntax,
>>> semantics, and so on). To try to rule out
>>> each of these conditions by checking each of them
>>> before sending a DeliveryReceipt, leads to
>>> endlessly bloating DeliveryReceipt functionality, and
>>> finally a need to be in the position of being able
>>> to produce the Business Response before issuing
>>> a DeliveryReceipt. Clearly this drift leads to a layering
>>> mish-mash.
>>
>>Precisely, this is a layering problem.
>>
>>>
>>> In EDIINT we had very similar requirement
>>> flux. Eventually we just left an open extension
>>> mechanism for receipts, in terms of what
>>> can be added by industry groups. RosettaNet
>>> went through similar struggles in working
>>> out its private/public division.
>>>
>>> I personally think it would
>>> be good just to draw a line and say that
>>> "Receipt is obtained when the MSH has persisted the
>>> message payload off the wire," and let the MSH
>>> handle sending the DeliveryReceipt, signed
>>> and including an appropriate hash for the
>>> original message. Nevertheless, adding on an
>>
>>Whether this signed DeliveryReceipt can be used for
>>NRR is questionable. I have no problem with this base
>>level functionality remaining in the MSH for use
>>in cases where the BPSS isn't used. However,
>>the likes of RosettaNet, when mapping to ebXML,
>>would not make use of this feature since the
>>business process (PIP) defines the business signals
>>that must be exchanged. It would be redundant to
>>have a DeliveryReceipt and a ReceiptAcknowledgment.
>>
>><ac>
>>I agree. In particular, it is not clear if (a) all RosettaNet PIPs
>>should make use of the reliable messaging quality of
>>service, or (b) none of them should use RM, or (c) they
>>should selectively use RM on a PIP by PIP basis. It must
>>be possible to do NRR without using RM.
>>
>>If a RosettaNet PIP requires the use of reliable messaging,
>>then the use of an end-to-end DeliveryReceipt is unavoidable.
>>In that case, I don't think the DeliveryReceipt needs to be
>>signed, nor does it need to carry a ds:Reference element.
>>The subsequent ReceiptAcknowledgement generated by
>>the RosettaNet middleware will provide the signed receipt
>>for NRR purposes.
>>
>>In the sync reply case, it is already possible to bundle the
>>DeliveryReceipt element and the ReceiptAcknowledgement
>>business signal into the same ebXML message. I think it
>>will be useful to extend this optimization to the async reply
>>case as well. The enumeration of syncReplyMode values in
>>the CPP/A spec should probably include the additional values
>>DeliveryReceiptOnly and DeliveryReceiptAndSignalsOnly.
>>
>>One thing I like to see clarified in the MSG spec is that
>>signed DeliveryReceipts are not intended to satisfy the
>>NRR requirement for business signals in the UMM
>>model that underlies the BPSS spec.
>></ac>
>>
>>> extension mechanism may appease others (especially
>>> in the BPSS side of things) enough
>>> that we can get all three main groups
>>> (BPSS, CPPA, and MSG) to agree that NRR has been
>>> implemented OK. The problem then will be
>>> in documenting this extension mechanism
>>> so that we can capture publication of and
>>> agreements upon extensions within CPPs and CPAs.
>>> We can then let the CPA adjudicate just how
>>> much "creep" into the application realm occurs
>>> (syntax check on payload, etc).
>>
>>None of the creep cited should be a function of
>>the MSH which should be concerned with sending, receiving
>>and dispatching of messages securely and reliably.
>>It should not be in the business of parsing payload,
>>verifying schema validity or checking whether value
>>ranges are within limits, etc. This functionality
>>is clearly out of scope for the MSH.
>>
>><ac>
>>I agree.
>></ac>
>>
>>>
>>> So, David B's compromise might be a good way
>>> to proceed if the MSH is to provide
>>> NRR functionality.
>>
>>I'm not so certain.
>>
>>>
>>> An alternative would
>>> be to follow Chris Ferris general preference
>>> to push all NRR all the way back up to the application.
>>
>>Woo hoo!
>>
>>> (At least I hope I am not misrepresenting Chris here.)
>>
>>Not at all. Just to clarify the term "application" by which
>>I mean only "not the MSH". An implementation of an MSH
>>may choose to bundle with it software that performs
>>functionality that is not specified for the MSH (e.g. some
>>manner of application adapter) is free to do so.
>>
>>> I think, though, that would make the MSH far less
>>> interesting as a middleware component module.
>>
>>See above. Our goal was not to specify a B2B middleware
>>server. It was to define a protocol and required
>>behaviour so as to enable interoperable, secure and reliable
>>transport, routing and packaging of messages.
>>
>>> Pragmatically, NRR is not something that anything
>>> but new applications would be able to provide and even
>>> then, it might be difficult to ensure access to the
>>> data elements needed to compute the hash to indicate
>>> being in posession of the original message/payload/whatever.
>>
>>Regardless, none of the same "applications" can speak
>>to an ebXML MSH either without modification. Some degree of
>>middleware/glue/adapter is almost certainly needed in all
>>cases. I consider this stuff to be in the "application" layer.
>>
>>>
>>> Moving on, David B. later says:
>>>
>>> "I actually think that the second one
>>> [involving an application notification assurance]
>>> is really an application level acknowledgement."
>>
>>I agree. I think that this is covered by the business
>>signals. Not our space.
>>
>>>
>>> I think we need to wonder why the application
>>> layer needs an acknowledgement, or why
>>> it needs to get involved in NRR issues.
>>
>>Again, maybe "application layer" is too loaded a
>>term. More importantly, NRR is a business concern,
>>not a technical/protocol concern. It involves archival of messages
>>or message artifacts, legal agreements and more.
>>When an NRR receipt can be generated depends upon
>>what the parties have agreed/specified. The BPSS spec,
>>and I'm certain anyone who was involved in RNIF can tell
>>you that one-size does not fit all.
>>
>><ac>
>>RNIF 1.1 is more closely aligned with UMM.
>>AcceptanceAcknowledgement signals are used in
>>RNIF 1.1 but not RNIF 2.0 because the feature has so
>>far not been exploited in any PIP. NRR is not applied
>>uniformly to all PIPs. A PIP can specify whether NRR
>>is to be applied to the request message, to the response
>>message, to both, or not at all.
>>
>>Currently, the NRR requirement for an individual PIP
>>is completely specified by RosettaNet. However, I believe
>>trading partners may want the ability to override.
>></ac>
>>
>>>
>>> What is an application level acknowledgement
>>> as opposed to the application
>>> level response? Why should an application
>>> need to get involved in producing a
>>> receipt instead of its defined application level response?
>>
>>According to the BPSS and RNIF, the response patterns
>>and timing are all part of the business process.
>>The "application" (e.g. the ERP system) might not be
>>directly involved in producing the business signals
>>(receiptAcknowledgment or acceptanceAcknowledgment).
>>Rather, some middleware (a business process orchestration
>>component) might assume this responsibility, never
>>involving the ERP system.
>>
>><ac>
>>Yes, ReceiptAcknowledgements are generated by the
>>RosettaNet middleware. It may not be entirely feasible for the
>>the middleware to automatically generate the
>>AcceptanceAcknowledgement because the validation of
>>business rules is withint the domain of the private processes.
>>However, this issue is kind of moot because no PIP uses
>>the AcceptanceAcknowledgement signal.
>></ac>
>>
>>My point is that MSH != BPS however, a BPS may indeed
>>have as a component an MSH node. However, not all MSH
>>nodes necessarily need to provide full BPS functionality
>>which would include NRR, choreography, preparsing, transformation
>>and all manner of bells and whistles.
>>
>>> This seems to be forcing applications to get involved
>>> in detailed delivery related issues, when an application
>>> may only know only about its tasks to be performed
>>> and what do with its results (regardless of how the task got
>>> queued up to it...).
>>
>>Again, see above.
>>
>>>
>>> I think that the BPSS group needs to explain
>>> why business applications should at all be in the
>>> business of worrying about generating acknowledgements
>>> or receipts. This is a source of layering conflict that is
>>> causing both CPPA and MSG difficulties in understanding
>>> how to finish their own tasks. If there is a
>>> BPSS requirement for NRR, does that mean that
>>> the lower layers are to provide an implementation
>>> supporting NRR? Or is it an indication that the design
>>> of the business data structures in Requests and
>>> Responses support NRR functionality? Or is something
>>> else meant? CPPA has, I think, mainly been thinking
>>> that a BPSS requirement of NRR was a request that
>>> the underlying layers provide an implementation for
>>> NRR (an implementation that can be a basic or
>>> a more enriched implementation).
>>
>>I think that security should also be party to this
>>discussion since NRR of necessity involves signing.
>>
>><ac>
>>I agree.
>></ac>
>>
>>>
>>> Is an application level acknowledgement
>>> an application response in addition to the real
>>> application business response or perhaps instead of a
>>> business response? I think that if a business
>>
>>It may depend. A process that can generate a response
>>quickly (mseconds) may not need any signals. Typically,
>>the signals are provided for long-running transactions
>>(such as a request that is processed in batch-mode
>>only once per day, etc.) so that the sender can have
>>some assurance that the business transaction wasn't
>>simply "lost in the sauce".
>>
>>As we get to a more message-driven, realtime processing
>>of business transactions, these artifacts will likely
>>have their importance and use diminished. IMO, there's
>>no reason why an NRR couldn't be piggy-backed with the
>>business-level response. Of course, once the business-level
>>response is received, an NRR may be totally meaningless
>>because there's nothing to repudiate!
>>
>><ac>
>>I am interested in seeing a flag in the CPP/A which
>>indicates whether DeliveryReceipt for RM can be piggybacked
>>with business level ReceiptAcknowledgement signals.
>></ac>
>>
>>> layer process thinks it needs such an
>>> acknowledgement for its own purposes,
>>> then that function should be built into BPSS
>>> specifications as requirements concerning the
>>> detailed algorithms, hashes, etc in the structured data
>>> exchanged in requests and responses. In this
>>> case, NRR will be opaque to the MSH layer,
>>> and there will need to be no agreement on how
>>> NRR is to be achieved/implemented (so DeliveryChannel
>>> characteristics do not need to be assessed
>>> to see whether NRR is supported on a channel.)
>>> This may be consistent with the Chris Ferris option
>>> discussed above; I personally would like to see
>>> a POC demonstrating this approach working interoperably
>>> before allowing it in an approved spec.
>>>
>>> Dale Moberg
>>>
>>> ----------------------------------------------------------------
>>> 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>
>