RE: Ack Message Payload??

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

I think "No payload" means there "ebXML Payload Container" i.e. no MIME part
that holds the payload. You will know this from looking at the manifest
which will be empty. We do not need any fuller definition from the TRP point
of view.

If I go back to the original definition of the header from the overview and
requirements spec it is defined as ...

"A Message Header is an XML construct that contains the additional data that
needs to be associated with the Documents in a message so that they can be
sent to and successfully processed by a Party."

I think that is sufficient and we should use this definition to guide what
goes in (or stays out of) the header.

We are awfully fond of scope creep to my mind. Let's keep TRP simple.

David
-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, October 31, 2000 11:36 AM
To: Patil, Sanjay
Cc: 'David RR Webber'; Christopher Ferris; ebxml transport;
ebxml-tp@lists.ebxml.org
Subject: RE: Ack Message Payload??



What does "no payload" mean?

I would like to postulate that a business process will require a business
process header, which contains control information specific to that
business process.  The business-process header is the header of the payload
of the Message-service message and is separate from the messaging-service
header.

If this postulate is accepted, then I suggest that an event could be
represented by a business-process header with no business-process payload.
From the viewpoint of the messaging service, there would formally be a
payload.  I suggest further that any header information needed to support
an event belongs in the business-process header, not the messaging service
header.  This is consistent with good layering design and keeps the
messaging service out of the business of having special functions for
particular kinds of business process messages.

Regards,
Marty

****************************************************************************
*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



"Patil, Sanjay" <Spatil@netfish.com> on 10/31/2000 02:22:14 PM

To:   "'David RR Webber'" <Gnosis_@compuserve.com>, Christopher Ferris
      <chris.ferris@east.sun.com>, ebxml transport
      <ebXML-Transport@lists.ebxml.org>
cc:
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.