RE: Ack Message Payload??

[Dick Brooks <dick@8760.com>]

David/Sanjay/John,

> 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?

I  believe the type of acknowledgement depends on the "processing behavior"
of the associated request message/service. For example, suppose I offer a
stock quote service, my "partners" (a.k.a. customers) send stock quote
requests (identified with MessageType="Normal"), my response message
(identified with "MessageType=Acknowledgement") contains the current stock
price in the ebXML message payload (like an RPC). On the other hand, an
order processing service, upon receiving a message containing a purchase
order, might respond by issuing a "delivery acknowledgement" with a "null
payload". This may be followed up later by one or more "business level
messages", in "response" to the original PO (e.g. X12 855 PO ACK or XML
equivalent) or something else (e.g. X12 856 - ASN's) sent in messages
identified with MessageType="Normal".

At least that's how I see ACK's being used in RPC and full messaging modes.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Friday, October 27, 2000 7:42 PM
> To: 'NEVE John'; Patil, Sanjay
> Cc: Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
> Subject: RE: Ack Message Payload??
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> 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.
>