RE: Ack Message Payload??

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

John - I like your definitions. However, as far as TRP is concerned only the
first "Delivery Acknowledgement" is within scope since the Message Service
Handler cannot check the payload and so can't state that the message will be
processed and similarly it does not know that the end application has
successfully processed it. This doesn't mean however that it is not a good
idea to define "standard" messages for these purposes. The question is does
it belong to TRP or BP to define - thoughts?

On a second thread, we also discussed a number of other issues around
"implicit acknowledgements". See the message at
http://lists.ebxml.org/archives/ebxml-transport/200009/msg00325.html

One of the ideas that came out of this was that a message could have
multiple "message types" or more perhaps more accurately "message roles".
For example you could have one message that was:
* a Normal Message, in that it contained a business document, and also
* an Acknowledgement Message, in that is was, for Reliable Messaging
purposes, the acknowledgement to an earlier message, as well as
* an Error Message, in that there was a "non-fatal" Warning associated with
the earlier message that had been received.

This means that instead of a single MessageType, you might have something
that looked like ...

<MessageType>
  <NormalMessage />
  <AcknowledgementMessage />
  <ErrorMessage />
</MessageType>

... where each of the elements within the Message Type were optional. The
other alternative would be to send back three separate messages. Either way,
one party or the other has to sync up the responses.

This is something to discuss for the F2F I think.

David
PS I'm not on the POC list so can you please forward this message to that
list.

-----Original Message-----
From: NEVE John [mailto:john.neve@swift.com]
Sent: Friday, October 27, 2000 7:58 AM
To: Patil, Sanjay
Cc: Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
Subject: Re: Ack Message Payload??


A few thoughts on ACKs (in brief):
1. I supposing in this scope we can forget about delivery notification and
non-delivery notification delivered by Internet.
2. A first 'end-receiver' ACK/NAK is called here and there 'Delivery
Acknowledgment'. On X.400 compliant systems, it is a message
generated by the Message Store or the User Application when the end-receiver
pre-processing (possibly not directly connected to
Internet) fetches or receives the message.
3. 2nd ACK in the sequence is a pre-processing ACK/NAK indicating that the
message is of sufficient quality to be queued for
processing.
4. 3rd ACK in the sequence is a processing ACK indicating that the message
has been successfully processed.

All ACK/NAKs should ideally be made non-repudiatable through signature of
its content+original message.
NAKS should preferably contain standard enumeration of reason for failure,
textual explanation on top where helpful, help on how the
problem could be fixed (e.g. which missing parameter), a pointer to a URL
for further help, and next expected further action by
original sender.

Hope this helps,
John

"Patil, Sanjay" wrote:

> Stumbled upon an old issue with Acknowledgment message payload,
> which we had left unresolved in San Jose ...Please ignore this message
> if the issue has already been thought and resolved (of course, let me
know)
>
> What should be the payload of Acknowledgement message?
> What is the scope of these Ack messages?
> If the scope is limited to TRP layer only, then
> a> Should the Ack payload generated by ebXML TRP layer be based on
>      ebXML Header of the original message only?
> b> Are we going to use the Ack messages for NonRepudiation,
>      in which case digest of the original message comes in picture
> If the scope is Business Process, then
> a> Do we have any specification for processing the incoming
>      payload, or it is pretty much left to the Business Process.
>      If it is up to the Business Process, then I would consider it
>      as a business document which  happens to be Ack.
>
> When I went through the payload docs for the POC, it is apparent
> that the Ack Message and the Acceptance messages have ditto
> same payload. This just emphasizes the need of clearer definition
> of the Ack message type, usage, etc. I had several Email
> communications before the last POC on this topic and had to finally
> agree with using RosettaNet Ack payload for demo purpose only.
>
> For the Tokyo POC, can we not have any payload for the Ack messages
> (which is anyway same as the Acceptance message ex. ItemCreateAck.xml
> and ItemAlign.xml have same content. Same with OrderCreateAck.xml
> and OrderAcceptance.xml) and leave it to TRP WG to decide.
>
> thanks,
> Sanjay Patil
>
----------------------------------------------------------------------------
> ------------------------------
> Work Phone: 408 350 9619
> http://www.netfish.com

--
This e-mail and any attachments thereto may contain information that is
confidential and/or proprietary and is intended for the sole
use of the recipient(s) named above.  It is not intended to create or affect
any contractual arrangements between the parties.  If
you have received this e-mail by mistake, please notify the sender and
delete it immediately. Thank you for your co-operation.