Dale,
"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.)"
As I am writing
for the third time now, I am just asking for the success of the "enqueue"
operation to be checked. This does not require any new coordination
protocols, it just imposes some ordering in the structure of your
application code. Instead of something like
....
acknowledge(message)
....
deliver(message)
You would write
something like
.... if deliver(message)
== Success:
.... .... acknowledge(message)
.... else:
.... .... errormessage(message,'Delivery
Failure')
In at
least one Axway product, ebMS 2.0 acknowledgments seem to be triggered by
delivery. I know this because if a system administrator manually
re-delivers a message from this product (which is an option that is useful
in some exceptional situations), an acknowledgment is sent to the trading
partner). So assuming the AS4 implementation will follow
this pattern, your company's product already does what I'm asking
for.
Pim
From: Moberg Dale [mailto:]
Sent: 30 January 2012 22:49
To: Pim van der Eijk;
Subject: RE: [ebxml-msg] Semantics of
AS4 Receipt
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. ([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’]
From: Pim van der Eijk
[mailto:]
Sent: Monday, January 30, 2012 1:36
PM
To: Moberg Dale;
Subject:
RE: [ebxml-msg] Semantics of AS4 Receipt
Thanks
for the response and background information. The proposal I made was
quite modest: to link the sending of an AS4 receipt to the ebMS 3.0 concept of
"MSH-Delivery". If ebMS 3.0 and WS-Reliability optionally support
this concept, it would be inconsistent for AS4 to commit to less.
AS2 (http://www.ietf.org/rfc/rfc4130.txt),
section 7.1, relates an MDN to delivery (my emphasis):
"The
signed MDN, when received by the sender of the EDI Interchange, can be used
by the sender [... as] an acknowledgement that the EDI Interchange sent
was delivered and
acknowledged by the receiving trading partner [..]".
MSH-Delivery
seems in fact to correspond exactly to what you call successful transfer
to the first "receiving
agent" that
is indeed often "just the first step
of a pipeline".
The defining requirement is that the message has been transferred
successfully out of the AS4 MSH. This is the case for all
the examples in my message. The increase in latency is minimal, the
impact on implementations limited, and fewer false receipts are produced.
The functionality better matches the expectations of end-users and is
supported in commonly used B2B gateway products for other
protocols.
Pim
From:
[mailto:] On
Behalf Of Moberg Dale
Sent: 30 January 2012 17:53
To:
Pim van der Eijk;
Subject: RE:
[ebxml-msg] Semantics of AS4 Receipt
The
first observation is that the requirements internet-draft was never published as
an informational RFC.
If
it had been, some of the tradeoffs involved in being an “applicability
statement” and in seeking to make AS1, AS2 and
AS3
as much alike as possible would have necessitated some revisions to the original
draft. The original draft also included several ideas that were not
implemented.
Going
back over all the tradeoffs would be tedious. I think the main one relevant here
is that the MDN was reused as the message type for
receipts.
In
an email context, a MDN is more associated with what the a UA does upon seeing
what the final MTA has come up with. So POP3 and IMAP based UA access can also
generate MDNs. EDIINT, however, only makes use of a success code from the MDNs
of “Processed”. Here is where the semantics that got implemented got
defined.
RFC
2298 was I think in scope when the EDIINT work started, but I don’t think all
the subsequent “obsoleting or updating” RFCs in this area change the
situation.
"processed"
The message has been processed in some manner (i.e., by some sort of rules or
server) without being displayed to the user. The user may or may not see
the message later, or there may not even be a human user associated with the
mailbox.
The
“processed” code then indicates the semantics of any kind of
receipt/delivery/disposition on the receiver side. So the overly ambitious
requirement of the draft were aligned with the constraints of reuse, and what
already existed. The reasons for the tradeoff were many and varied. Mainly
however they all reflected the unpredictable latencies between
MTA/MSH/WebServer/FTPserver reading of data and the acquisition by the next
processing step(s). Would it be a POP3 UA or was there an automated pipeline
pushing to a UA feeding a translator,JMS, MFT, ESB, or any of the integration
technologies in use? Or for HTTP, would a servlet, appserver, CGI push to the
next app, and would a success from that app be relevant to count as
“disposition”. The ultimate “backend application” is only in simple
middleware cases just one hop from reception; the receiving agent is just the
first step of a pipeline (where there can be branching or forking process
flows). How is all that to be summed up in one code?
In
general the A2A visibility problem remains unsolved for general deployment
situations by any current standard. It will take some significant effort and
cost to make A2A visibility commonplace. AS4 will not be doing it IMO. The
backflow of status notifications down the integration pipeline is just too
varied to smooth over, without considerable thought given to lightweight
notification technologies, with built in subscription, expiration, digest, and
other capabilities.
Hello,
I was working on an
AS4-related topic over the weekend and have some questions on AS4 non
repudiation receipts.
The AS4 profile is
presented as designed to meet EDIINT requirements.
According to section
3.7 of http://tools.ietf.org/id/draft-ietf-ediint-req-09.txt EDIINT
defines the requirements for non repudiation
as:
"Receipt by the
sender of a signed receipt, is an implicit
acknowledgment of
successful mailbox delivery. It is also an
explicit
acknowledgment that the Interchange was retrieved from
the
mailbox - pick-up notification. By having the receiver sign
the
receipt, it authenticates that the intended receiver picked up
the EDI Interchange -- mailbox authentication -- and that the
intended receiver verified the integrity of the EDI Interchange,
and the identity of the sender. By returning the original
message
id and the one-way hash value of the received contents
back in the
signed receipt, the sender can reconcile the
acknowledged EDI
Interchange with what was
sent."
According to section
8 of http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.odt the
ebMS 3.0 Core Specification distinguishes between RM-Delivery and
MSH-Delivery.
Case 2: The acknowledgment is "on MSH-delivery"
(supported in WS-Reliability). In that case, notification option 1 can be
supported as well as option 2. In order for option 1 to be supported, an RMP
must implement RM-Deliver operation so that it is only considered successful
(worthy of sending an acknowledgment) if the Deliver operation from MSH to
Consumer also succeeds. It is RECOMMENDED that an implementation support this
acknowledgment semantics.
In http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/44888/AS4-profile-v1.0-wd22.odt
section 3.4, the following is stated about AS4:
"The Receiving MSH is
taking responsibility for processing this user message. However, no guarantee
can be made that this user message will be ultimately delivered to its Consumer
application (this responsibility lays however now on the Receiver
side)."
Now this seems to be
more like the RM-Delivery (only option supported in WS-ReliableMessaging) than
MSH-Delivery ?
The EDIINT definition
of "non repudiation of receipt" seems to require MSH-Delivery rather
than RM-Delivery. If we're claiming that AS4 meets EDIINT requirements, is
this enough ?
I'm not saying that
AS4 products should support a VAN mailbox interface based on pickup of a
message, and should delay sending a receipt until such a pick-up happened
(possibly hours or days later). Drawbacks of this have been
discussed in the past when we looked at multi-hop reliability models.
But in the AS4
context, it could be defined as: the MSH successfully passed
responsibility for delivering the message to some third entity (system, program,
user).
Examples of succesful
or unsuccessful delivery could depend on
implementation:
-
Delivery to a mailbox:
Succes: message was added to mailbox.
Failure: quota exceeded, mailbox full.
(No guarantee that any user or system actually processes the
message)
-
Delivery to a file system:
Success: the MSH successfully created, wrote data to, and closed
a file representation of the message metadata and contents.
Failure: Permission denied, I/O errors
(There is no guarantee that any user or program actually processes the created
file)
-
Delivery to a message queing system
Success: successful enqueue()
Failure: enqueuing failed
(There is no guarentee that any other application dequeue the
item)
-
Delivery to another B2B messaging system:
Success: the Submit() operation was invoked
successfully
Failure: Submit() operation failed
(No dependency on any downstream receipts)
In the case of
failure, which the AS4 MSH can detect immediately after receiving a
message, I would prefer the AS4 to not send a Receipt but to send an Error
instead.
An alternative idea
is discussed in section 8.2.4 of the ebMS 3.0 Core Specification, which has
a discussion on false delivery failures:
"False DF - which can
never be completely eliminated - can always be detected outside the reliable
messaging (RM) layer, in a tractable and less urgent way - e.g. the sending
party may synchronize on a daily basis by communicating its list of assumed
delivery failures, for confirmation by receiver. The Status Request feature
(which may be described in a forthcoming Part 2 of the ebMS specification) could
facilitate this function."
Pim
