[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Ack Message Payload??
Hi all, Can we also consider adding a <controlMessage/> as well, which could be used for message level control stuff like reset sequence numbers et al ? This would enable the messaging systems to exchange TRP level controls - including dynamic security reconfiguration, reliable messaging reconfiguration et al. cheers -----Original Message----- From: Burdett, David [mailto:firstname.lastname@example.org] Sent: Friday, October 27, 2000 5:42 PM To: 'NEVE John'; Patil, Sanjay Cc: Ebxml-Poc (E-mail); Ebxml-Transport (E-mail) Subject: RE: Ack Message Payload?? 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:email@example.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.
Powered by eList eXpress LLC