Our current implementation sends a receipt (currently only for receipt
awareness) only after the "next step" is taken i.e. placed in a queue.
The only guarantee is that the next step taken was successful. What
happens after that is not.
~Makesh
-----Original Message-----
From:
[mailto:] On Behalf Of Theo Kramer
Sent: Monday, January 30, 2012 10:53 PM
To:
Subject: Re: [ebxml-msg] Semantics of AS4 Receipt
Agreed with Dale. I kind of see the AS4 MSH as DCE (data communications
equipment) transparent to associated business processes.
On 30 Jan 2012, at 11:48 PM, Moberg Dale wrote:
> I think that AS4 NRR is now roughly the same as AS1-3 NRR. My concern
was that we not proceed beyond secured, acknowledgement of receipt (and,
when security features are OK, an indication that the next processing
step was engaged). I am uncertain about "successful transfer" - the MSH
did its step in "processing," but whether the next processing step was
successful is not assured. (For example, the payload might be placed on
a queue, but whether the payload was taken off the queue is an open
question as far as the signal is concerned.)
>
> [Many requests from "end user communities" have emerged over time to
add on various assurances about further processing. I don't think we
should go there with data exchange protocols. That does not prevent
embedding data exchange protocols in richer coordination protocols that
might add on various notification services. But I would not want to get
into these additions within AS4. I think the additional protocols should
be developed as applications of existing IETF protocols, maybe as an
EDIINT-NG or B2B-NG interest group. I don't think it should be an OASIS
effort. Just my opinion (or using the new catch phrase), just sayin']
--
Regards
Theo
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
