RE: Ack Message Payload??

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

I agree with you Sanjay. We should make absolutely no mandatory requirements
on the payload. If the service and action are sufficient for a remote system
to determine the intention of sending a message, then nothing more is or
should be required.

David

-----Original Message-----
From: Patil, Sanjay [mailto:Spatil@netfish.com]
Sent: Tuesday, October 31, 2000 11:22 AM
To: 'David RR Webber'; Christopher Ferris; ebxml transport
Subject: RE: Ack Message Payload??



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.