OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-msg] Issue for your review


Hi Doug,

I agree with you about the spec describes about the HTTP response code.
IMHO it is enough to emphasize on the handle HTTP response by the MSHs.

Thanks,
Venkat

-----Original Message-----
From: Doug Bunting [mailto:db134722@iplanet.com]
Sent: Monday, October 21, 2002 2:13 PM
To: Dave Elliot
Cc: Danda, Venkata; mwang@tibco.com; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Issue for your review


Well put.

The existing specification was relatively clear on this point simply by
describing the HTTP response codes as recommendations for the message
receiver (bundling almost) rather than something the sender should act
upon.  Do we need to make this more explicit?

thanx,
    doug

Dave Elliot wrote:

> On Mon, 2002-10-21 at 10:19, Danda, Venkata wrote:
> > Hi Michael,
> >
> > You are right. In case of the receiving side application fails
> > to persist the message or some thing goes wrong in the server side
> > it will raise server side http error code to the MSH. Receiver side
> > MSH should communicate this to the Sender. As you mentioned the data
> > will exchanged between the MSHs but not to the applications properly.
>
> Here's the thing...  The Receiver side does not need to propogate
> internal errors to the Sender MSH using transport protocols.  If the
> Receiver MSH experiences a failure that prevents it from taking
> responsibility for the inbound message then it indicates this implicitly
> by _not_ returning an ebXML Ack or explicitly by sending an ebXML
> Error.  In either case transport protocol response codes are not
> involved...
>
> If the Receiver MSH even _attempts_ to return an ebXML Ack then it has
> already taken contractual responsibility for delivering the message to a
> bound ToParty or to a NextMSH.  This is regardless of whether or not the
> ebXML Ack transmits ok.
>
> One last point that you and Mike have raised is that failure to leverage
> transport protocol response codes can mean that an MSH will hold on to
> ebXML data without delivering it.  I have thought about this and cannot
> bring to mind a legal situation where an MSH could be in a position of
> blocking an ebXML message without delivering it to a bound ToParty or
> forwarding to a NextMSH....?
>
> Cheers,
>
> Dave Elliot
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC