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

[christopher ferris <chris.ferris@east.sun.com>]

I recall it being discussed in London and agreed by those present.

Let's not dwell on issues which have no import. The element is still
in the message, just relocated to a (possibly) more appropriate spot, 
'nuff said.

As to having to return the whole message, I could see that
requirement being eliminated. Of course, if there were RM involved,
then the sender might not have kept the original message...

However, for the sake of expediency and simplicity, let's remove this 
constraint/requirement from the error message in keeping with the KISS
principle.

Cheers,

Chris

"Burdett, David" wrote:
> 
> So how did this get in there? When was it discussed? In what F2F meeting, or
> when on the list?
> 
> David
> 
> -----Original Message-----
> From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
> Sent: Monday, February 26, 2001 6: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
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard