RE: Returning the whole message on Message Expiry Delivery Failur es

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

SOAP 1.1 Section 4.4 Soap Fault, under SOAP Fault element 'detail' states:

"The detail elemetn is intended for carrying application specific error
information related to the Body element.  It must be presetn if the contents
of the Body element could not be successfully processed.  It MUST NOT be
used to carry infromation about error information belonging to header
entries.  Detailed error information belonging to header entries MUST be
carried within the header entries."

IMO, the ebXML "Delivery Failure" element must be located within the
SOAP-ENV:Header area, not in the SOAP-ENV:Body area.  I don't have the
latest ebXML specification to look at just now, but I suspect MessageData is
something that was placed in the SOAP-ENV:Body.

Cheers,
        Bob

-----Original Message-----
From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
Sent: Monday, February 26, 2001 8:00 AM
To: Rik Drummond; ebXML Transport (E-mail)
Subject: RE: Returning the whole message on Message Expiry Delivery
Failures


No.  Time to live was moved to the MessageData element as a chiild
element, it was not deleted.  In previous versions it was an attribute
of the QualityOfServiceInfo element.  The group agreed to move it and
make it an element.  I agree with David, I cannot find a good reason for
returning the 'dead message.'

Ralph Berwanger

-----Original Message-----
From: Rik Drummond [mailto:rvd2@worldnet.att.net]
Sent: Monday, February 26, 2001 5:39 AM
To: ebXML Transport (E-mail)
Subject: RE: Returning the whole message on Message Expiry Delivery
Failures


david time to live interacted strangely with repeat transmit times. i
had
ralph kill it in the paper... i hope... rik

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Sunday, February 25, 2001 9:42 PM
To: ebXML Transport (E-mail)
Subject: Returning the whole message on Message Expiry Delivery Failures


Folks

Section 10.2.3 (TimeToLive) says that if TimeToLive is expired, then the
"DeliveryFailure" error message should return a payload of the ebXML
message
that has expired. I disagree with this in that this is the only error
that
requires the return of the message in error and also, the message could
be
huge (many 100s of Mb) when requiring the sending of all of it would not
make sense. I propose that this requirement is removed. The
RefToMessageId,
alone should be sufficient.

Thoughts?

David

Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704; Pager: +1 (888)
936
9599
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org