Re: [ebxml-msg] Messaging Spec v1.092 / CPA dependency

[Christopher Ferris <chris.ferris@sun.com>]

Jacques,

Please see below.

Jacques Durand wrote:

> 
> I believe the notion of "independence" should remain "formal": means
> an MSH instance is not required to imperatively access an ebXML CPA 
> server somewhere,
> or is not forced to literally parse a CPA document.


This is precisely the case presently. The ebXML Message Specification
says nothing about required use of the CPA document at runtime
nor has it ever done so to my knowledge. In addition, there
isn't described anywhere a notion of a CPA server. How an implementation
chooses to store/access the information that is defined in this
specification as coming "from the CPA" is completely up to the
whim of the implementor.


> I think it satisfies the spirit of the charter, the ultimate purpose of 
> which is
> I believe that any MS implementation should be able to work without a 
> (formally)
> CPA-compliant implementation.


And, as previously stated, that is just what we have been saying
all along. There is nothing to my knowledge in the spec that
states otherwise.


> 
> That does not mean an MSH should not use any "CPA-data"... which should 
> be considered
> as MSH configuration data, as Martin suggested. Being able to configure 
> MSH behavior
> at conversation level, not just message level, makes it a much more 
> reliable/efficient
>  tool for business, and so it is worth the pain of sorting out the 
> semantic conflicts
> between this configuration data and header data.


agreed.


> If we don't do it, then each message will have to always carry CPA-data,
> and the burden will be on the app to provide it each time.
> Plus, in future versions, the MSH will likely be the place where to 
> enforce CPA data
> that is higher level than message: duration of a conversation, max 
> concurrent conversations...


possibly, but again, I see this not as a function of the MSH but of
some software that manages the conversation/process somewhere
between the application and the msh, which again is just an abstraction
that defines the behavior prescribed in this specification.


> 
> Maybe the apparent dependency is mostly editorial.


I don't believe so, I believe that this "dependency" is an
artifact of myth and legend based upon either misinterpretation,
misunderstanding or misrepresentation of document and/or discussion.


> we could have abstracted more the notion of CPA in MS spec:


We did, possibly not as effectively as we could have.


> Just a (late) suggestion: we could have named it "Communication Protocol 
> COnfiguration" (CPC)


What purpose would that have served other than to make things
even less clear.


> and assume it is no more than a set of attributes associated with each
> communicating pair (from/to), and write CPC anywhere we use CPA today.
> We could have then a RECOMMENDATION that the CPC content be derived from 
> a CPA...
> So applying a CPA to an MSH is a matter of configuration, in the same 
> way as applying a
> CPA to a lower transport layer is.


Again, that is all that it has ever been. Even if a CPA document
is used directly, it is likely to be transformed or translated into
something that the implementation can use more effectively than
if it were to parse the CPA each time a message is processed.

See lines 350-356 of the spec. This has been present in the spec
for quite some time now. It was first published in draft form
back in August [1], and introduced into the spec in v1.02 [2].

I also firmly believe that we have expended WAY too many cycles
on this issue. The fact is, and has been for quite some time
now, that most electronic business is conducted in the
presence of an agreement that is often a legally binding
contract between the parties that carries legal remedies
for non-compliance with that agreement/contract. The CPA
(virtual or physical) is the machine readable representation of
the technical terms of that agreement between the parties.

The TC voted at the last f2f to agree that for purposes of
this specification, that messages exchanged between parties
by their respective MSHs were governed by a CPA which represents
the technical terms of an agreement between the parties.

How the information represented in a given CPA is made known
to an MSH at runtime is, and has always been, unspecified
by the ebXML Message Service specification. This is, and has
always been, (intentionally!) completely up to the implementor
to define for themselves.

Even if an MSH implementation has hardcoded all of the CPA
parameters that the MSH spec identifies as being relevant
to its operation, as long as the parties *agree* to that (limited)
set of terms, it could be a conformant implementation of this
specification. It might not be very agreeable to many prospective
partners, but that's a completely different issue.

In conclusion, I will add this. The ebXML TR&P team began its
work, early on, with a notion of something we were calling, at that
time, the TSLA (technical service level agreement), which constituted
a set of parameters that were necessary to the runtime execution
of the MSH in the context of a given exchange of messages
between two parties. This predated IBM's generous contribution
of tpaML to the ebXML initiative. Had the IBM contribution not been
made, and a separate project team established for the purpose
of adapting tpaML to the needs of ebXML as a whole, it is
highly likely that the equivalent of what is defined in the
ebXML CPP/A spec with regards to the CPA would have been
incorporated into the ebXML Message Service specification
and this whole issue of "independence" would have been moot.

Cheers,

Chris

[1] http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00330.html

[2] http://lists.oasis-open.org/archives/ebxml-msg/200110/msg00002.html



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