Re: Ack Message Payload??

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

Sorry, just back to work and reading the tons of messages.
Fully agree with you.  We need to keep focus on which party is handling what part of the message.  Access to payload should be
allowed/required only for end-receiver.  Message Services should have (just) enough and easily accessible info in the payload.  We
will all agree not to impose a payload for the sake of it.

John

"Patil, Sanjay" wrote:

> If ebXMLHeader is not enough to identify the message
> completely and requires some dummy payload, we need
> to work more on the ebXMLHeader.
>
> Relying on dummy payloads for unambiguity would lead to
> ambiguous specs of the TRP, not a good idea.
>
> I am for not having payload when none is required.
> Business Processes should handle events (no payload)
> as well as normal business documents.
>
> thanks,
> Sanjay Patil
> ----------------------------------------------------------------------------
> ------------------------------
> Work Phone: 408 350 9619
> http://www.netfish.com
>
> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Tuesday, October 31, 2000 6:46 AM
> To: Christopher Ferris; ebxml transport
> Subject: Re: Ack Message Payload??
>
> Message text written by Christopher Ferris
> >
> Regardless, I think that a BP-level ACK *should* have
> a payload, even if it is a minimal one like:
>         <status>OK</status>
>
> It SHALL have a MessageType="Normal" and it SHALL have
> a ServiceInterface and Action appropriate to its purpose
> at least for the current state of affairs.
> <<<<<<<<<<<<<<<
>
> Chris,
>
> Agreed.   Getting back an empty transaction is too ambiguous.
>
> DW.

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