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] Messaging Spec v1.092


Title: RE: [ebxml-msg] Messaging Spec v1.092

David, you said ...

>>>Now, someone else please take the SOAP box.<<<

So I suppose it's my turn ...

Firstly, I totally agree with what you said in your email.

As I have said many times before I am in favor of a method by which two parties can exchange data that records how they have agreed to exchange messages or perhaps do business together.

However, by requiring that there is a pre-existing agreement in place between the two parties that defines the parameters that configure how each MSH works (whether virtual or a CPA document is irrelevant), we severely limit the applicability of the ebXML Messaging spec in situations where a lightweight protocol is required. In fact without a negotiation protocol, you **cannot** use the existing ebXML spec for spontaneous exchange of messages.

This lack of spontaneity will, in my opinion, lead to the lack of adoption of the reliablility and security aspects of the ebMS spec by the wider W3C/SOAP/XML Protocol/Web Services community - which will be a shame. There is a need for an open standard for secure, reliable messaging between applications within an enterprise, to meet the requirements of Web Services. The current ebMS spec does not meet this need and is really only a B2B spec.

To fix this problem, the next version of the ebMS spec needs a protocol for secure reliable messaging that requires NO prior negotiation. You should be able to just send one message securely and reliably and expect a response in the same form.

If two parties have agreed that they want to constrain their interaction to working in a particular way, then using a CPA to record their "agreement" and then referencing that agreement in the message through a CPAId makes sense.

With this approach I think you would get the separation of ebMS and CPP/CPA that both David and I think we need.

However, unlike David, I will vote for the current spec since it does meet a useful need within its niche.

Regards

David


-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Sunday, January 06, 2002 2:24 PM
To: Martin W Sachs; Jacques Durand
Cc: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092


I disagree.  If the specs were truly loosely coupled then we would not have
discussions concerning discrepancies between the header fields and the CPA.
Errors concerning such discrepancies would be implementation dependant.  We
would not worry about aligning Messaging and CPA.  We would not have continual
problems with having to remove fields from the Messaging headers because they
are already specified in the CPA (in fact, many fields would exist both places).

We even voted at the last F2F that there MUST be an agreement in place -- no
allowance for spontaneous eCommerce.  There has been constant discussion that
there MUST be either a CPA or a "virtual CPA", which simply means a database
containing all the CPA fields and structures even though there may not be an
actual XML document anywhere.  Quotes from the spec to the contrary are simply
my lack of diligence in removing them since the last F2F.

If we could move back to a time when we did allow non-agreement (with or without
CPA) type eCommerce, then that would remove my objection -- but I don't think
that is where we are now.  Our original charter was to focus on the SME needs in
eCommerce.  I would argue the SME's need something more akin to B2C rather than
traditional B2B (I don't mean Web based but I do mean spontaneous).  My
objection is that our (very good) system is largely a rehash of what has gone
before (and maybe somewhat of an improvement) but it does NOT adequately address
the needs of SME's.

Now, someone else please take the SOAP box  ;-).

Regards,

David Fischer
Drummond Group.



-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, January 04, 2002 10:39 PM
To: Jacques Durand
Cc: 'David Fischer'; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092



Jacques,

I agree with you that the MSG spec is NOT tightly coupled to the CPA. The
words you quote are exactly the words that eliminate dependence on the CPA.
However, information that can be encoded in the CPA is still needed to
enable to partners to exchange messages.  Without a CPA,  that information
is entered separately into each partner's system via a GUI tool.  That's as
loosely coupled as you can ask for.

********************************************************************************
*****

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



Jacques Durand <JDurand@fs.fujitsu.com> on 01/04/2002 07:21:24 PM

To:    "'David Fischer'" <david@drummondgroup.com>, Arvola Chan
       <arvola@tibco.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>,
       "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com>
cc:
Subject:    RE: [ebxml-msg] Messaging Spec v1.092




David:

No  problem with V2.0, agree that "1.1" is misleading with regard to
backward  compatibility.

The adoption of an (early) incompatible new version can still be helped if
the  upgrade is such that it
allows for an upgraded  MSH implementation to handle in parallel the two
"incompatible" versions

during  a transition period, (in case running two different MSH  instances
on same site is problematic).

That  is quite possible using version # in header, if the incompatibility
is  mostly in the packaging format,
with  no conflicting MSH behavior . This would permit a smooth transition,
not  needing
all  trading partners to upgrade at same time.

"Tightly" integrated with CPA? Just reading V1.092  I did  not have this
impression:

"...However, the method used by a specific  implementation of the MSH does
not mandate the existence of a discrete instance  of a CPA.
... This specification does not  prescribe how the CPA information is
derived, stored, or used:
it  only states specific information items must be available for the MSH to
achieve  successful operations."

My understanding is that some (actually small) subset  of CPA needs be
available in some form.
That still sounds like loose coupling to  me...

Regards,

jacques Durand
-----Original Message-----
From: David Fischer  [mailto:david@drummondgroup.com]
Sent: Thursday, January 03, 2002  5:48 PM
To: Arvola Chan; ebXML Msg; Ian. C. Jones  (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec  v1.092


Comments inline.

Ian,
We still have a couple of unresolved issues -- most notably the  signature
problem Sanjay pointed out.  There is also the issue (item 6  below) that
SyncReply does not work with Intermediate Acknowledgments.   We are
supposed to start voting tomorrow.  What shall we do?  If you  would like,
I can go ahead and post as version 1.093?

I want to thank everyone for all the help on editing/reviewing the
specification.  I think this is a much better spec than v1.0.  That  said,
I will also say I plan to vote *no* on this spec for two reasons:   1) Our
charter was to create a v1.1 spec with "fixes and clarifications only"
which we have failed to do (if we could name this spec v2.0, as the  RegRep
team did, then this objection would go away),  and  2) Our  original
charter was to create a set of "orthogonal ebXML specifications"  which we
have failed to do (we have tightly coupled Messaging with  CPPA).  I would
like to urge everyone to consider a version number of  v2.0 since v1.1 has
the connotation of backward compatibility which we  certainly have not
achieved.  Our next version could then be  v3.0?

Please let me know what you want to do.

David.
-----Original Message-----
From: Arvola Chan  [mailto:arvola@tibco.com]
Sent: Wednesday, January 02, 2002 2:34  PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg]  Messaging Spec v1.092


David:

Here are some belated editorial comments. I  hope they can be fixed without
too much trouble:

   Line 18: Don't  we have to wait for a calendar quarter boundary before
   the spec can be  presented to the OASIS membership for consideration as
   an OASIS  specification?
   <df>Fixed --  this means we will submit on April Fools Day   ;-)
         We still don't have anything  under the *This Version*
   heading</df>
   Line 311: The reference to [ebREQ] cannot be  found among the
   Non-Normative References (see line  2761).
   <df>Added  Reference</df>
   LIne 896: The permissible values for  duplicateElimination in the CPA
   are perMessage, never, and always.  Therefore, replace "set to false"
   with "set to never" on line 897. Note:  this is with respect to the 1.1
   CPP/A spec. Do we need to add a reference  to the forthcoming 1.1 CPP/A
   spec?
   <df>done</df>
   Line 1384: The schema says that this is a  REQUIRED attribute. It must
   be set to the value "http://schemas.xmlsoap.org/soap/actor/next".  It is
   somewhat different from being declared as a FIXED attribute in the
   schema. Line 1384 seems to suggest the latter. Excerpts from the SOAP
   1.1  spec: "The SOAP actor global attribute can be used to indicate the
   recipient of a header element. The value of the SOAP actor attribute is
   a  URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next"
   indicates that the header element is intended for the very first SOAP
   application that processes the message. This is similar to the
   hop-by-hop  scope model represented by the Connection header field in
   HTTP. Omitting  the SOAP actor attribute indicates that the recipient is
   the ultimate  destination of the SOAP message. This attribute MUST
   appear in the SOAP  message instance in order to be effective (see
   section 3 and 4.2.1)."
   <df>Changed "fixed" to  "REQUIRED"</df>
   Line 1389: CPP/A attribute names start with a  lower case. SyncReplyMode
   should be globally repaced with  syncReplyMode.
   <df>done</df>
   Line 1412: I like to point out that a  SyncReply element is not
   compatible with an AckRequested element that is  targeted at the next
   MSH.
   <df>No  resolution yet.</df>
   Line 1491: I think an errorCode of  Inconsistent should be accompanied
   by a severity of Error rather than  warning. Didn't we decide that
   inconsistency between the CPA and the  message header must always result
   in an error being  returned?
   <df>This might  not be an inconsistency with the CPA (perMessage).  If
   we say this  must be an Error then we must also say the To Party MSH
   MUST NOT deliver  to the Application.  IMO This needs to be a
   Warning.</df>
   1502: The statement "An Error Message MUST NOT  contain an AckRequested
   element" is not correct and should be struck out.  Please see
   http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html
   (Resolution  of issues in the issues database), IssueId 73, and/or
   http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc,
   Issue 73.
   <df>We have gone  back and forth on this several times.  I think the
   latest was to  change to *no Ack on Error*.  If we go back to *no Error
   on Ack* then  I need to go back through the spec and make several
   changes.  See  *[ebxml-msg] Ack on Error, or Error on Ack* thread
   starting  12/10/01.</df>
   Line 1557: I think it is inconsistent to ask  for a signed
   Acknowledgment if the original message is not  signed.
   <df>Why?  I  agree it sounds strange but I can't think of any reason it
   would be  inconsistent.  Someone might want NRR but there is no reason
   to  sign.</df>
   Line 1579: It will be useful to point out that  parameters that are not
   found in the message header are to be obtained  from the CPA.
   <df>??? It  already says this?</df>
   Line 1584: Replace "value of  duplicateElimination in the CPA is false"
   with "value of  duplicateElimination in the CPA is never".
   <df>done</df>
   Line 1591: I think it may be problematical for  the recipient to do
   duplicate elimination when no DuplicateElimination  element is present.
   What happens if SyncReply is present and AckRequested  is not present.
   If the incoming message is not passed on to the  application, should any
   reply be returned to the sender?
   <df>Resolved between Arvola and  Doug</df>
   Line 1602: It will be useful to point  out that the Retries parameter
   comes from the CPA.
   <df>done</df>
   Line 1605: It will be useful to point out that  the RetryInterval
   parameter comes from the CPA.
   <df> done </df>
   Line 1616: It will be useful to point out that  the PersistDuration
   parameter comes from the CPA.
   <df> done </df>
   Line 1625: As mentioned earlier, SyncReplyMode  should be spelt as
   syncReplyMode. Also, I just noticed the following  statement in the 1.0
   CPP/A spec. "If the delivery channel identifies a  transport protocol
   that has no synchronous capabilities (such as SMTP) and  the
   Characteristics element  has a syncReplyMode attribute  with a value
   other than "none", a response SHALL contain the same content  as if the
   transport protocol did support synchronous responses." which
   contradicts the statement on line 1625: "The SyncReplyMode parameter
   from  the CPA is used only if the data communications protocol is
   synchronous  (e.g. HTTP)."
   <df> Resolved </df>
   Line 1646: The sentence is missing a closing  period.
   <df> done </df>
   Line 1678: This seems to contradict the  statement on line 1589.
   <df> deleted </df>
   Line 1684: There is an invalid reference to  section 0.
   <df>   deleted </df>
   Line 1733 and line 1738: These  two bullet points assume that
   syncReplyMode in the CPA is not used with an  asynchronous communication
   channel. This is in conflict with the 1.0  CPP/A spec statement quoted
   in item 15 above. I think this is a minor  technical issue that may
   require some discussion.
   <df>  Resolved  </df>
   Line 1772: Since one MSH is not allowed to  place more than one
   AckRequested element in the SOAP Header (according to  line 1469), this
   matrix represents what an intermediary MSH or the To  Party MSH may
   receive, not what the From Party MSH may send.
   <df> Does this mean 1468/9 is wrong?    It already says *SHOULD* so
   maybe no change is  needed.</df>
   Line 2098: I think the statement "The  Receiving MSH MUST NOT send an
   Acknowledgment Message until the message  has been delivered to the Next
   MSH" is not correct.  This does not  correspond to store and forward
   behavior (see line 2043). The Receiving  MSH cannot know for sure that
   the message has been delivered to the Next  MSH until it receives an
   Acknowledgment from the latter. The prescribed  behavior defeats the
   purpose of intermediate Acknowledgments.
   <df> What would be more correct?  Should it  say *The Receiving MSH MUST
   NOT send an Acknowledgment Message until the  message has
   been persisted?*  Actually, I don't see a problem as  it is.  What
   should I do? </df>
   Line 2619: This comment seems  unnecessary. Would it constitute an
   unrecognized MIME header?
   <df> Yes, this is unnecessary.  No this is  not illegal.  Everything
   between the first blank line and the first  boundary is ignored.  It is
   common for vendors to put  advertising info in this space -- identify
   the product or vendor software  producing this  message. </df>

Regards,
-Arvola

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "ebXML Msg" <ebxml-msg@lists.oasis-open.org>
Sent: Thursday, December 20, 2001 7:25  PM
Subject: [ebxml-msg] Messaging Spec  v1.092


> This is the spec as it stands now.  I think everyone's  comments are
included
> (I'm mad at Doug for sending pages and pages  of very good comments AT
THE LAST
> MINUTE  ;-)
>
>  Please get any last minute comments to me quickly.  Please no large
changes at
> this point.
>
> Ian, I still need to resolve  the copyright issue.  Also, we need to
decide on
> the problem  Sanjay described (I added the change as hidden text if
anyone wants
>  to look at it).
>
> If anyone needs this in PDF, please let me  know.
>
> Regards,
>
> David Fischer
>  Drummond Group
> ebXML-MS Editor.
>




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