RE: delivery failure

[Martin W Sachs <mwsachs@us.ibm.com>]

David,

Absolutely - perception is a key to success.

The CPA team will also be publishing a maintenance release.  We may need to
synchronize on these.  The clarification of delivery notification delivery
is a key item - and it should make that delivery failure notification
normative.

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
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 07/19/2001 04:20:06 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "'HUGHES,JIM (HP-Cupertino,ex1)'" <jim_hughes@hp.com>,
      ebxml-msg@lists.oasis-open.org
Subject:  RE: delivery failure



Marty

You make a very good point ... perception is important. One of the results
of the F2F held earlier this week was that we plan to publish a "1.1"
version of the ebXML messaging spec that will cover "clarifications,
removal
of ambiguities and bug fixes", i.e. no new functionality. We should
consider
your suggestion as a clarification ...

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, July 19, 2001 1:16 PM
To: Burdett, David
Cc: 'HUGHES,JIM (HP-Cupertino,ex1)'; ebxml-msg@lists.oasis-open.org
Subject: RE: delivery failure



Yes, the service interface spec is essential but:

The problem here is that the SHOULD is causing people to complain that
ebXML reliable messaging is fundamentally flawed. Changing SHOULD to SHALL
requires implementers of ebXML messaging to provide the mechanism for
delivery-failure notification. If the sending application doesn't care if
the message was delivered, it also does not need the overhead of using
reliable messaging.

Yes, this behavior may be hard to verify but that only means that
verification will take place in the field when some disaster occurs that
reliable messaging is supposed to prevent.

Alternatively, without the SHALL, people who understand what reliable
messaging is supposed to accomplish will simply choose an alternative
messaging service.  Anyone who doesn't understand that there is at least
one alternative should look at the HTTP-R proposal at
http://www.ibm.com/developerworks/webservices . There is an introduction
document that lays out the principles of reliable messaging and has a link
to the proposed specification.

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
****************************************************************************

*********



"Burdett, David" <david.burdett@commerceone.com> on 07/19/2001 03:36:02 PM

To:   "'HUGHES,JIM (HP-Cupertino,ex1)'" <jim_hughes@hp.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:   ebxml-msg@lists.oasis-open.org
Subject:  RE: delivery failure



I agree with Jim, the MSH would notify the calling application of the
failed
message delivery using the Service Interface spec which is not yet
developed. I think the word SHOULD was used rather than MUST since:
1. the sending application may have no mechanism by which it can be
notified
of failed delivery, or
2. the sending application may not care if the message was delivered

Basically this section is describing recommended behavior of the MSH which
cannot ever be independently verified.

David

-----Original Message-----
From: HUGHES,JIM (HP-Cupertino,ex1) [mailto:jim_hughes@hp.com]
Sent: Thursday, July 19, 2001 9:09 AM
To: Martin W Sachs
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: delivery failure



Marty -

This is one of the general topics discussed in the OASIS TC meeting this
week -- the Service Interface between the sending/receiving application and
its MSH. No conclusions reached other than this is a major piece of work
needed for the next version of the spec... and required for portability if
we expect applications to move between different MSH implementations.

Jim


> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, July 19, 2001 7:41 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: delivery failure
>
>
> How is a sending application informed of a delivery failure
> in the reliable
> messaging function?  Is it one of the SOAP faults?
>
> 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
> **************************************************************
> ***********************
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>

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