[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Question about OPTIONAL
David: I misunderstood your intent of section 2.2.9. I was under the impression it applies to every top-level ebXML extension to the SOAP header. If this interpretation is not correct, I think section 2.2.9 should be clarified. Of course, the schema must also be updated to correspond to the spec. You seem to be suggesting that when party A sends a message to party B that it wants to be delivered reliably, it can set SOAP:mustUnderstand to 1 or 0. If there is a CPA governing the message exchange between the two parties and it calls for the use of Reliable Messaging, I think SOAP:mustUnderstand should always be set to 1. Otherwise, I guess it is OK to ask for reliable delivery but settle for best-effort delivery as a fall back position. If a sender wants to construct an AckRequested element, it needs to know whether it should ask for a signed or unsigned Acknowledgment. It must look to the CPA for guidance if a CPA is in use. I don't see what's wrong with having an AckRequested element under a DeliveryChannel's Characteristics. Regarding "adding MSHsignals to syncReplyMode", please see http://lists.oasis-open.org/archives/ebxml-msg/200110/msg00174.html. The minutes taken by Ian for the 10/22/2001 conference call indicate: "Sync Reply Issue 9 - CPPA team will be asked to include a mshSignalsOnly sync reply mode." I believe you left early during that call. I suppose this issue is best revisited at the F2F meeting. If there are multiple intermediaries in a message path, it is not clear if you always want the sending MSH to always hold the connection open waiting for the MSH signal. The last time issue 9 was discussed, most who were present felt that adding a mshSignalsOnly mode to the CPA would be more flexible. Regards, -Arvola > -----Original Message----- > From: David Fischer <david@drummondgroup.com> > To: Martin W Sachs <mwsachs@us.ibm.com> > Cc: Christopher Ferris <chris.ferris@sun.com>; Dan Weinreb > <dlw@exceloncorp.com>; arvola@tibco.com <arvola@tibco.com>; > ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> > Date: Saturday, November 10, 2001 10:06 AM > Subject: RE: [ebxml-msg] Question about OPTIONAL > > > >No, I am only saying that IMO an unrecognized AckRequested is not a reason > to > >stop a message. This is the expected behavior if mustUnderstand="0". > > > >We should send back an Error/Warning/NotSupported if not understood. This > is > >going to happen every time a v1.1 system sends an AckRequested to a v1.0 > system. > >There is nothing wrong with the message itself. > > > >I see that Arvola went through the schema and added mustUnderstand to > >everything. Why? Did we vote on this? This is not how SOAP works. The > >mustUnderstand attribute is optional and default "0". Why are we now > requiring > >it? If we say some options are optional then let's leave them optional. > Some > >elements, like MessageOrder have to be mustUnderstand="1" but not > everything. > > > >Why does everything have to go in the CPA? Please leave AckRequested out > of the > >CPA. Putting it in the CPA make things more complicated. > > > >BTW, why are we adding MSHsignals to syncReplyMode? It doesn't need to be > >there. This again makes things more complicated. MessageHeader syncReply > >should be default "true". In HTTP this means all MSHsignals come back > sync. In > >SMTP we ignore the syncReply flag. The only time the syncReply flag would > ever > >be used would be to downgrade from sync to async (not very often). > > > >Regards, > > > >David Fischer. > > > >-----Original Message----- > >From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > >Sent: Friday, November 09, 2001 9:35 PM > >To: David Fischer > >Cc: Christopher Ferris; Dan Weinreb; arvola@tibco.com; > >ebxml-msg@lists.oasis-open.org > >Subject: RE: [ebxml-msg] Question about OPTIONAL > > > > > > > >There is nothing explicit in the CPA about ability to return an ACK. The > >ebXML TP team assumed that there is nothing optional about returning an ACK > >and therefore nothing has to be said about it in the CPA. This statement > >is true for both BestEffort and OnceAndOnlyOnce semantics. If the MSG team > >is proposing to make an ACK optional, I guess the CPA will have to be > >extended for that. > > > >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 > >*************************************************************************** > ***** > >***** > > > > > > > >David Fischer <david@drummondgroup.com> on 11/09/2001 10:16:13 AM > > > >To: Christopher Ferris <chris.ferris@sun.com>, Martin W > > Sachs/Watson/IBM@IBMUS > >cc: Dan Weinreb <dlw@exceloncorp.com>, arvola@tibco.com, > > ebxml-msg@lists.oasis-open.org > >Subject: RE: [ebxml-msg] Question about OPTIONAL > > > > > > > >Is the ability to return an Ack in the CPA? > > > >Internet philosophy is to be as stringent as possible when sending and as > >forgiving as possible when receiving. > > > >David. > > > >-----Original Message----- > >From: Christopher Ferris [mailto:chris.ferris@sun.com] > >Sent: Friday, November 09, 2001 8:53 AM > >To: Martin W Sachs > >Cc: David Fischer; Dan Weinreb; arvola@tibco.com; > >ebxml-msg@lists.oasis-open.org > >Subject: Re: [ebxml-msg] Question about OPTIONAL > > > > > >+1 > > > >Martin W Sachs wrote: > > > >> Yes, this is the real world and businesses that don't follow the spec are > >> creating a serious interoperability exposure for themselves. > >Nonetheless, > >> if a message violates the intent of the creaters of the CPA (or > >equivalent) > >> one or the other has made a serious error and processing of the message > >> should not continue. > >> > >> 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 > >> > >*************************************************************************** > ***** > > > >***** > >> > >> > >> > >> David Fischer <david@drummondgroup.com> on 11/08/2001 10:19:07 PM > >> > >> To: Dan Weinreb <dlw@exceloncorp.com>, arvola@tibco.com > >> cc: Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org > >> Subject: RE: [ebxml-msg] Question about OPTIONAL > >> > >> > >> > >> I find myself outnumbered so I will acquiesce -- with one final comment. > >> > >> Businesses in the real world don't like strict rules. I think this will > >> fail, > >> or more likely implementors will not follow the spec. > >> > >> - David > >> > >> -----Original Message----- > >> From: Dan Weinreb [mailto:dlw@exceloncorp.com] > >> Sent: Thursday, November 08, 2001 9:07 PM > >> To: arvola@tibco.com > >> Cc: mwsachs@us.ibm.com; david@drummondgroup.com; > >> ebxml-msg@lists.oasis-open.org > >> Subject: Re: [ebxml-msg] Question about OPTIONAL > >> > >> > >> Date: Thu, 08 Nov 2001 11:07:47 -0800 > >> From: Arvola Chan <arvola@tibco.com> > >> > >> I vote for option 1: Stop processing and send back an Error -- > >> NotSupported/Error. > >> > >> I agree, and with the rest of what you said. > >> > >> ---------------------------------------------------------------- > >> To subscribe or unsubscribe from this elist use the subscription > >> manager: <http://lists.oasis-open.org/ob/adm.pl> > >> > >> > >> > >> > >> > >> ---------------------------------------------------------------- > >> To subscribe or unsubscribe from this elist use the subscription > >> manager: <http://lists.oasis-open.org/ob/adm.pl> > >> > > > > > > > > > > > > > > > >---------------------------------------------------------------- > >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