Re: Ack Message Payload??

[NEVE John <john.neve@swift.com>]

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.

begin:vcard 
n:Neve;John N.
tel;fax:+32 2 655 30 05
tel;work:+32 2 655 30 87
x-mozilla-html:TRUE
url:www.swift.com
org:S.W.I.F.T. s.c.;Marketing- Standards
adr:;;avenue Adele 1;La Hulpe;;B1310;Belgium
version:2.1
email;internet:john.neve@swift.com
title:Systems architect
fn:John N. Neve
end:vcard