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